◦ Even the most simple tasks felt like we were constantly fighting the tool ◦ We wanted one tool for code updates and base OS configuration While we were having issues with Puppet Stanford was adopting the edX platform and having similar issues with Chef. edX started using Ansible (1.3) in September, 2013
over the tools and the data • Isolate deployments, student privacy is extremely important • Operates in the cloud but strives to be cloud agnostic • Official releases of our configuration scripts with Vagrant images and public AMIs
Using Vagrant, code directories are exported from the host filesystem to the guest • Fullstack - Every service in production installed on a single server • A small number of multi-cluster redundant configurations (stage, production, loadtest)
• python virtual environments for every service • pre-built images for AWS auto-scaling • AWS virtual private clouds used for multiple edX installations • VPC layout described using cloudformation • Utilizing AWS resources where possible (RDS, ELB, S3, Elasticcache, SES)
source repo contains all of the edX roles • A private repo contains roles internal to edX • A private repo containing one yaml file per environment for variable overrides • For code version updates, vars are set on the command-line
that connects to other VPCs and runs ansible plays. • Inventory is fed directly into Jenkins via an inventory script that gathers tag information • All Ansible tasks are run from Jenkins for auditing and repeatability
easier to scale • Ansible was the perfect tool to make this work with very little additional effort • Netflix’s Asgard has proven extremely useful for managing autoscaling groups and, cut overs and rollbacks.