Skip to content

Open edX AWS Production Deployment and Upgrades

⚠️ OUT OF DATE

This documentation is out of date. We now use these Terraform scripts to deploy Open edX to AWS and are moving toward using Grove instead.

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.

Initial deployment

Similar to upgrades (see below).

How to upgrade an instance

The basics are:

  1. set up vars.yml in 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 edx-configuration
  2. create a new EC2 instance
  3. backup RDS
  4. provision the new server by running ansible-playbook:
  5. do it from director
  6. use the edx_sandbox.yml playbook but with the aws role added
  7. 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,"
  8. wait for provisioning to complete
  9. test the new service
  10. change the elastic IP or DNS record to point to the new instance
  11. 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.