Although this blog post will focus on AWS ELB, the same strategy can be applied to Azure.
First is to configure your process that deploys your web application within Octopus. Octopus has the ability to perform the rolling deployments pattern:
Rolling deployments are a pattern whereby, instead of deploying a package to all servers at once, we slowly roll out the release by deploying it to each server one-by-one.
You can configure rolling deployments per individual process. Go into the individual process and configure the execution plan to be a rolling deployment.
Since you you have your web application in front of an AWS Elastic Load Balancer, you can add chid steps to the primary step above which will:
- Remove the EC2 instance from the ELB Target Group
- Perform the upgrade of your web application to the EC2 instance
- Re-register the EC2 instance with the ELB Target Group.
When the EC2 instance is removed/deregistered from the ELB Target Group, it will drain all connections. Meaning it will wait for the current connections to finish before removing it self from the Target Group.
There is an existing template task that you can use in the Octopus Deploy Library to de/reregister your EC2 instances.
Simply add install the task template. Add a child ask before which will remove and a child task after software upgrade to re-register.
Zero Downtime Deployments
How are you handling zero download deployments?
Are you using containers? Azure? I’d love to hear how in the comments or on Twitter.Follow @codeopinion