wpc
commented
9 years ago hi @mefellows:
Many thanks for the contribution. There are mostly 2 flavors of blue green implementation on AWS: switch routing on ELB (e.g. asguard) or on DNS record (e.g. our eb_deployer). Both has pros and cons. DNS switching approach is safer for on going requests and less intrusive for application's own infrastructure, but has the con that it is never theoretically safe for killing the inactive environment because of DNS caching. So what I generally do in production is letting inactive environment scale down to 1 instance using "inactive_settings" config. This both helps us cope with DNS cache, and provides us a safe-net for bad version.
Our production settings:
option_settings:
- namespace: aws:autoscaling:asg
option_name: MinSize
value: "5"
inactive_settings:
- namespace: aws:autoscaling:asg
option_name: MinSize
value: "1"Similarly if you are confident traffic to inactive will die out in a specific period of time, you can use following settings to gradually kill idle instances to 0 to save cost.
option_settings:
# providing least redundancy
- namespace: aws:autoscaling:asg
option_name: MinSize
value: "2"
# make sure cooldown is reset back to default when environment become active again
- namespace: aws:autoscaling:asg
option_name: Cooldown
value: "360"
inactive_settings:
# reduce instance count to 0 to save cost
- namespace: aws:autoscaling:asg
option_name: MinSize
value: "0"
# make sure cooldown is big enough to cope with DNS cache
- namespace: aws:autoscaling:asg
option_name: Cooldown
value: "900"The above configuration will wait at least 15 minutes (900 seconds) to kill the last instance in inactive, and in most case it is safe. Also the scale down process is off from the deployment process, so the deployment time will not increase even you have long Cooldown buffer.
You can also play with aws:autoscaling:scheduledaction options to schedule a scale down to zero action after a specific time. I haven't tried but it should be straightforward.
For this pull request I will not merge because there is already configuration to achieve the same goal. We definitely could do a better job for "inactive_setting" documentation. Sorry about that. But please keep up for contribution.
-- wpc
mefellows
betarelease
This feature introduces a new Strategy, which is really a fresh take on the Blue Green approach. In short, in many cases its ideal to remove the inactive stack post deployment - generally for keeping costs down.
This strategy follows the Blue Green approach, but will tear down a stack after a successful migration to the new 'Red' Environment, marking the old one as 'black' and terminating.
It should be noted that I considered modifying the existing Blue-Green strategy, but felt it was best to separate for the following reasons:
What are your thoughts?