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
- This risk can be minimized by deploying using only the
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.