What are Blue/Green Deployments?
“Blue/Green Deployments” is a software deployment methodology. A terminology to suggest two mostly equal states of potential different deployable artefacts.
Within the context of Amazon Web Services (AWS), there are a couple of ways to do this.
Let’s explore the two most common ones, then extend that theory to a third one.
Thereafter, we will touch on two more that could be looked at.
1. Route53
Update the DNS routing. With this technique, there is a duplicate stack for both the Blue and the Green environments, and Route53 is utilised to point the DNS to a specific point. It is extremely fast and simple to rollback using this method, by simply changing the DNS records back to what they were before.
It’s also to use weighted Round Robin to split a percentage of the traffic between the deployed versions. With this theory, you can just keep upping the percentage for the new deployment while you’re testing for system stability.
Pros: No downtime, fast rollback.
Cons: TTL (Time to Live) – DNS Caching?
2. Auto Scaling
Swap the Auto Scaling behind a Load Balancer. As we start to add instances to our Green environment, we can remove from our Blue environment. If this carries on looking good. We just continue until the Green environment is fully tested and at full capacity, and receiving all the traffic.
Meanwhile, we’re reducing the instances in the blue environment.
If we need to roll-back, we simply start spinning up instances in our Blue environment and removing them from our Green environment.
We can control the percentage split to each environment, by controlling the number of instances in each environment. Say that both the Blue and the Green environment each have 5 instances, then that would mean each environment is receiving a 50 percent split. As we add more instances to the Green environment and reduce the instance count in the Blue environment, this percentage split will weight towards the Green environment.
Additionally, if we don’t want to terminate the instances in the Blue environment, we can always just stop them, which will help if we needed to them roll-back quickly.
Pros: High degree of control, no TTL DNS Caching to contend with.
Cons: Higher degree of monitoring, and instance management.
3. Auto Scaling Group Launch Configurations
Update Auto Scaling Group Launch Configurations.
Caveat; can only have one Launch Configuration associated to an Auto Scaling group at any one time.
To successfully perform this, you need to replace the existing launch config (blue) with a new launch config (green). Scale the ASG to twice its original size. Then shrink the ASG back to its original size.
By default, the instances with the old launch config are removed first.
In order to perform a roll-back, just update the ASF with the old launch config. Then follow the previous steps in reverse.
Pros: A non-DNS or LB option. Somewhat automatic.
Cons: Possibly more trouble than it’s worth.
4. Elastic Beanstalk Environment Swap
Swap the Environment of an Elastic Beanstalk Application
5. Clone Stack in OpsWorks
Clone a Stack in AWS OpsWorks and switch the DNS