Zero Downtime Deployments with Octopus Deploy

Sponsor: Using RabbitMQ or Azure Service Bus in your .NET systems? Well, you could just use their SDKs and roll your own serialization, routing, outbox, retries, and telemetry. I mean, seriously, how hard could it be?

If you’re using Octopus Deploy and AWS with their Elastic Load Balancer (v2) in front of EC2 instances that either self host or sit behind IIS, you can setup zero downtime deployments fairly easily. Although this blog post will focus on AWS ELB, the same strategy can be applied to Azure.

Rolling Deployments

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.

AWS ELB

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