====== Moodle on AWS ======
AWS (Amazon Web Services) promises high scalability, globally distributable web applications. There are some examples of Moodle installations on AWS. Here are a few resources:
* [[http://simonives.wordpress.com/2013/09/11/webinar-recording-building-a-scalable-moodle-based-lms-in-the-cloud/|Webinar recording: Building a scalable moodle-based LMS in the cloud]]
* [[http://www.mediaagility.com/2013/reference-architecture-auto-scaling-moodle-deployment-on-aws/|Reference Architecture – Auto-scaling Moodle deployment on AWS]]
* [[https://moodle.org/mod/forum/discuss.php?d=251233#p1183812|Moving course images to S3]]
* [[https://moodle.org/mod/forum/discuss.php?d=234566|Moodle architecture - AWS]]
* [[https://docs.moodle.org/28/en/Installation_Guide_for_Installing_on_Amazon_EC2|Installation Guide for Installing on Amazon EC2]]
* [[http://simonives.wordpress.com/2013/06/18/installing-moodle-2-5-in-spectrum-trainings-tsts-environment-using-amazon-web-services/|Installing Moodle 2.5 in Spectrum Training’s TSTS environment using Amazon Web Services]]
===== AWS Terminology =====
* EC2: Elastic Compute Cloud - the server where your code runs
* EBS: Elastic Block Store - persistent block storage for EC2 instances
* S3: Simple Storage Service - cloud & internet storage service (not directly linked to an EC2 instance)
* Cloudfront:CDN (Content Distribution Network) service
* Route 53: DNS services, including domain name registration
* SES: Simple Email Service - for outbound email
* VPC: Virtual Private Cloud
* Elasticache: in-memory cache service (can be used for memcached, apparently)
* AMI: Amazon Machine Image - is used to instantiate an EC2 instance
* Elastic Beanstalk - automated scaling (auto-scaling & load balancing); abstraction layer on top of all the other AWS services. Official definition: AWS Application Container.
* Region: geographical area where Amazon's datacenters are located
* Availability zone: isolated location inside a region; this is where your EC2 instance lives
* Amazon DynamoDB: NoSQL database service; can be used for session storage, apparently
===== Beanstalk Solution for Moodle =====
Moodle consists of a php codebase (all the php scripts making up the application), a database, user files and sessions. In addition, Moodle uses caching to speed up things. To provide a scalable hosting solution for Moodle using AWS, we need the following components:
* S3 and s3sf for files (use s3sf to symlink to filedir and lang directory)
* AMI with Moodle's codebase
* Elasticache for memcached caching (be careful: be default, Amazon selects one the most expensive caches for you!)
* RDS for Moodle's MySQL database
* Sessions can be handled by database
===== Custom Beanstalk AMI =====
Beanstalk offers auto-scaling & load balancing right out of the box. But the EC2 instance is based on a default Amazon-linux AMI, which does not suit my purposes very well. I want to use an Ubuntu box, so to speak.
To use your own AMI, you first need to create one, in the EC2 part of the AWS Dashboard. Then, back in the Beanstalk part of the Dashboard, you can put in the id of your AMI.
- Select your region (note: Frankfurt currently does not support Elasticache, so choose Ireland if you're in Europe - we're gonna need Elasticache for session storage)
- In the EC2 dashboard, pick a hvm type of virtual server (see Amazon's [[http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/virtualization_types.html|Virtualization Types]], which explains this provides better performance).
- Create and launch the instance
Apparently, it's next to impossible to use an AMI that was not created with Beanstalk. The only option is to customize an existing Beanstalk AMI, by launching it as a new EC2 instance...
Anyway, Amazon's Beanstalk AMIs are pretty well configured. I found that all prerequisites for Moodle were met from the very start.
===== Deploy Moodle Codebase: Remove composer.json =====
If you are deploying your application to AWS Elastic Beanstalk, and you have a composer.json file in the root of your package, then Elastic Beanstalk will automatically perform a Composer install when you deploy your application. So, remove or rename the composer.json file before you upload your Moodle codebase to Beanstalk.
To properly use composer.json, consult this article: [[http://stanlemon.net/2013/03/21/composer-on-elastic-beanstalk/|Composer on Elastic Beanstalk]]
===== Install Fuse s3fs =====
Excellent tutorial: [[http://www.yiannakasgeorge.com/blog/web-technology/how-to-mount-an-amazon-s3-bucket-on-an-amazon-ec2-instance-by-using-fuse-and-s3fs-as-a-moodle-data-directory.html|How to mount an Amazon S3 Bucket on an Amazon EC2 Instance by using FUSE and S3fs]] (as a Moodle data directory)
See also: [[https://code.google.com/p/s3fs/wiki/InstallationNotes|InstallationNotes]]
On a running EC3 instance:
- sudo yum install libstdc++-devel
- sudo yum install fuse
- sudo yum install fuse-devel
- cd /src
- wget https://github.com/s3fs-fuse/s3fs-fuse/archive/master.zip
- unzip master.zip
- cd s3fs-fuse-master
- ./autogen.sh
- ./configure --prefix=/usr
- make
- sudo make install
Then specify your Security Credentials (Access Key ID & Secret Access Key) in ''/etc/passwd-s3fs'', using accessKeyId:secretAccessKey. Apparently, you also need to do: ''sudo chmod 640 /etc/passwd-s3fs''.
Now mount the s3 bucket:
mkdir -p /mnt/s3
s3fs mybucket /mnt/s3 -o allow_other
Finally, symlink your moodledata directory to S3:
cd /mnt/s3-drive
sudo mkdir moodledata
cd /var/www/html
sudo ln -s /mnt/s3-drive/moodledata .
sudo chmod 777 -R moodledata
OPEN QUESTION: How do you make sure that the configuration changes are applied to all EC instances? Is there a way to create a new AMI out of the modified EC instance and use that to spawn new EC instances?
==== Unmount ====
sudo fusermount -u /mnt/s3-drive
**Attention**: the directory will still be there, so don't get confused if you still see ''s3-drive'' in your directory listing.
===== Add A Superuser =====
* ''sudo useradd yoursuperuser''
* ''sudo usermod -a -G sudo yoursuperuser''
* ''sudo passwd yoursuperuser''