Upgrading an application with canary deployment

This post describes how to configure a canary step to application deployments to provide a controlled roll-out. Canary deployments are well-understood in central environments, but looks a little different when deploying to many locations.

Deploying to many places is scary, meet our friend the canary

Rolling out applications to a large number of locations is operationally different from deploying to a single centralized cluster. More care and thought needs to make sure that the new version works as expected in live production. A common pattern is to first deploy a new version to a lab environment without production traffic, run some tests and then proceed to gradually roll out to production locations using Canary Deployments.

Configuring manual canary deployments

In the Avassa platform, canaries are configured aspects of a deployment and come in two flavours:

• Timed canary deployments that require deployments to the canary sites to be healthy for a defined amount of time before automatically being rolled-out to the rest of the sites
• Manual canary deployments require a manual step to proceed after successful deployment to the canary sites

In this example, we are going to update the version of a container in a currently deployed application using a canary deployment with manual trigger.

We have prepared by configuring a new version of an already deployed application. And we have assigned a label lab-site: true to our canary-site in Finland (Helsinki).

To trigger an upgrade, we then update the application-version in the current deployment and add a manual canary step with a label matching statement lab-site lab-site = true. We make sure that the Helsinki site is matching as the canary site.

When we click Submit updated deployment we can follow the canary deployment happening to Helsinki first, and the rest of the sites wait for the manual canary confirmation step.

When the canary step is done and we have made sure the application is healthy, we click Continue deployment to proceed to deploy the application to the rest of the sites.

Moments after that all sites have been upgraded to the new version, and our deployment can be declared successful.

We have now upgraded a running application to a new version using a canary step with manual confirmation.

Conclusion

The ability to perform canary deployments are fundamental to a structured approach to releasing new code. Depending on the operational culture, application teams may opt for timed or manually triggered canary deployments.

Read more about canary deployments in our documentation.