13 June 2014
We grouped our infrastructure resources into two categories:
We designed our application to run on replaceable resources.
And keep our data in permanent resources.
For permanent resources, we picked AWS CloudFormation.
AWS Elastic Beanstalk is a web application platform service.
It supports switching URLs between 2 Elastic Beanstalk environments.
DNS switch is the best tool to switch web traffic.
Therefore we deploy replaceable resources to 2 Elastic Beanstalk environments.
One active, one inactive.
Point domain URL to active environment URL.
Deploy new application version to inactive environment.
Run smoke tests on inactive environment.
Switch environment URLs of active and inactive environments.
Traffic is now routed to the new application version.
Our blue-green deployed environment = 1 CloudFormation stack + 2 EB environments.
The environment needs to be maintained and replicated.
No existing tool does it.
Built on top of Elastic Beanstalk and CloudFormation.
The configuration is a YAML file.
It is also an ERB template for substituting OS environment variables.
The application name matches Elastic Beanstalk application name.
“common” section is for all environments.
“environments” section defines environments specifics.
“strategy” = “blue-green” by default.
“resources” section defines permanent resources provisioned by CloudFormation.
“option_settings” will be converted to Elastic Beanstalk options, no magic.
“resources” – “outputs” are also converted to Elastic Beanstalk options.
“smoke_test” is a ruby script run before web traffic is switched.
“strategy” = “blue-green” maybe too complex for development environments.
“strategy” = “inplace-update” is a viable alternative.
“version_label” indicates how we generate new application package version.
One package version can be deployed to multiple environments.
Ignore eb_deployer environment component if your were new to eb_deployer.
An example here.