Deployment - HeliumEdu/deploy GitHub Wiki

The Ansible scripts in this repository can be used to deploy to any environment, from production to a local Vagrant. For convenience, helium-cli, which is compatible with this project and provides a useful set of tools for maintaining, building, and deploying the code, is also installed when certain make commands are run. Using this tool, executing helium-cli deploy-build 0.1.0 qa will deploy the 0.1.0 build to the QA environment, provisioning the nodes as necessary with configuration settings in this repository. For more details on how to make these these builds, see the helium-cli documentation. A versioned build can be deployed, but Git branches can also be deployed, for example helium-cli deploy-build feature-27-branch devbox.

Remote deployments will not work without a permissioned SSH key at ~/.ssh/id_rsa, an inventory file for the given environment in ansible/group_vars, and the necessary private configuration files (for instance, SSL certificates) in ansible/private.

Environments

Making a New Environment Configuration

Environment's are groups of hosts (or just one, if the environment is a small, all-in-one host) and their associated inventory files. For example, the deploy command in the section above helium-cli deploy-build 0.1.0 qa will only work if a qa group has been defined under the ansible folder with the necessary hosts and inventory files.

Making a New Group Configuration

To create a new group, create a new .yml file in this folder and define what it deploys to what hosts. Each host referenced in the new group .yml should also be defined in the hosts file. Each group/host combination should have a corresponding .yml file under group_vars.

Note that devbox.yml sets clone_code=False. This is because in the Vagrant environment, project code is mounted using shared folders. In all other environments, this flag should be omitted (which will default it to True).

Creating a new inventory file in is documented here.

Current Risks

These deployment configurations currently have two accepted risks:

  • Deployments are done onto live nodes (chance of downtime)
    • This risk can be minimized by deploying using only the --code flag whenever possible

Zero Downtime Releases

Even if the --code flag is used to avoid interrupted live sessions during a deploy, there is a small chance of interrupted or odd behavior during a deployment. There are a few possible solutions to this. One is to implement a rigid blue/green deployment infrastructure. Another solution would probably be to utilize deployable AMIs and roll an ELB to a new AMI once deployment is completed.

The current blocker is cost constraints for engineering resources, infrastructure, and the financial cost that is incurred by these options. It is not prioritized at this stage of the project.