Open edX AWS Production Deployment and Upgrades
Deploying to an AWS instance isn't totally automated. You'll need to log in to the AWS panel, prepare servers, and then SSH to the instance.
The longest part of the deployment process is waiting for an
ansible playbook which does all the provisioning.
Some of the components we use in Amazon are: - We always create two instances: the one to be provisioned, and a proxy one, called director, that we use as proxy to connect to the final one. - We store the data in an RDS instance, that we create and backup separately - At the end of the deployment process, we switch something to point to the final instance; instances without a load balancer would change a DNS register to point to the IP, while instances with load balancer would switch what Amazon calls Elastic IP to point to the new server IP
This article is about deploying LMS/CMS. See also how to setup Analytics in AWS.
Similar to upgrades (see below).
How to upgrade an instance
The basics are:
- set up
vars.ymlin some directory or repository. Review the variables inside
vars.yml(including private information like users/passwords). These variables will override the default variables found in
- create a new EC2 instance
- backup RDS
- provision the new server by running
- do it from director
- use the edx_sandbox.yml playbook but with the
- for example:
ansible-playbook -vvv --user=ubuntu --private-key=../../edu-private/edxapp.pem --extra-vars=@"../../edu-private/vars.yml" edx_sandbox.yml -i "172.31.72.3,"
- wait for provisioning to complete
- test the new service
- change the elastic IP or DNS record to point to the new instance
- stop the old instance
Note that we don't modify the old instance, or stop any service running there. The deployment happens in a new instance and later we switch to it. For a short time, both instances could be accessing the same databases, but it's usually safe.
More difficult upgrades might require two phases, e.g. from Ficus.3 to Ficus.4 and then from Ficus.4 to Ginkgo.1.