Background

In the last few years, there are many Continuous Delivery tools launched in the market. Today, most of the companies are looking for a deployment cycle that takes very little time in a safe and disciplined manner. The Customer needs to identify the operational needs of their application deployment process and evaluate the appropriate CD tool to achieve the best deployment strategy

CI/CD Without Spinnaker (Problem Statement)

CI tools such as Jenkins provides extensive support for Continuous Integration, but when it comes to Continuous Delivery, especially where frequent canary deployment happens in a large-scale cloud platform, it always depends on some third-party tools like Ansible/Puppet which requires complex pipeline scripts with lots of customization. Many companies are struggling to achieve the flawless canary deployment strategy due to lack of Automation skills.

**Solution **

Spinnaker is an open-source multi-cloud supported CD tool that provides phenomenal support in a very large-scale cloud deployment environment. Spinnaker can be used in Continuous Delivery and Continuous Deployment platforms. It simplifies the automation tasks, it has native support for deploying applications on Kubernetes clusters. It supports multiple cloud platforms such as AWS/GKC/Azure/Oracle Cloud Infrastructure/Cloud Foundry/Open stack/Kubernetes with a lot more attractive features.

Why Spinnaker is Different

• The best part of Spinnaker is, open-source with many attractive features such as CLI setup, CI integrations, and pipeline management.
• Spinnaker deployments are smooth and very quick compared to other CD tools. It provides ease of support for rolling deployments in a large-scale environment. Spinnaker has built-in features of Blue/Green and Canary deployment strategies which does not exist in other tools like Puppet/Chef/Ansible/Salt/CFEngine.
• Spinnaker is mainly aimed at the cloud-native, it was actually designed to support multi-cloud architectures (to avoid vendor lock-in) and has a slight advantage over any other CD tool. It was originally developed by Netflix.

**Deployment Strategies **

There are two types of deployment strategies. Spinnaker supports both red/black (also known as blue/green) strategy and canary deployment strategy. These strategies are inbuilt within the spinnaker

application. Let us deep dive into canary deployment using Spinnaker.

Canary Deployment Strategy

What is Canary Deployment?

Canary deployments are a pattern of rolling out releases to a subset of users or servers. The idea is to first deploy the change to a small subset of servers, test it, and then roll the change out to the rest of the servers. Once all the health check is passed, when there are no complaints, then the complete customers will be routed to the new version of the application and the old version will be deleted.

There are four images shown above. Consider there are two application versions (V1.0 & V1.1). Image (1) shows that 100% of traffic is routed to the older application version (V1.0) which was already deployed in production. Image 2 shows that 90% of traffic is routed to the older application version (v1.0) and 10% of traffic is routed to the new application version (v1.1). Image 3 shows that 50% of traffic is routed to the old and new app versions equally. Image 4 shows that 100% traffic is completely routed to the new application version (v1.1) whereas there is no traffic at all to the older app version (v1.0). This is called canary deployment.

Canary analysis will do the comparison between the old (v1.0) and new version (v1.1) of your application. The differences can be subtle and might take some time to appear. You might also have a lot of different metrics to examine. It needs to perform the canary analysis based on the application metrics that is configured in the tool.

Spinnaker Workflow Overview

This below workflow diagram explains CI/CD deployment model in Kubernetes using Spinnaker.

As displayed in the above image, the developer changes the code and pushes it to a Git repository. Jenkins Build detects the changes, builds the Docker image, tests the image, and pushes the image to Docker registry or any other private repository. Spinnaker detects the image by an automated trigger, initiate canary deploys, and perform functional tests of Canary deployment. After a manual approval or once the canary analysis is succeeded, Spinnaker deploys the image to production by disabling the old application version.

Spinnaker is a pure Continuous Deployment tool, we should avoid comparing with Jenkins or any other CI tool. Jenkins and Spinnaker combination gives wonder to your deployment process if it is in multi-cloud and large-scale deployment platform. The Spinnaker pipeline script can be also triggered from Jenkins through Spinnaker API calls.

Spinnaker receives the binary from Docker registry or any other private registry such as Nexus/Jfrog/Artifactory, you need to integrate the respective registry with spinnaker. These pipeline scripts can be also triggered automatically by polling the changes from one of these registries or whenever change happens on the manifest file in the GitHub.

Spinnaker is an extremely powerful open-source platform for managing software deployments. It supports many different platforms and deployment methodologies, for the purpose of this blog we are going to run it on top of a managed Kubernetes cluster in a VM. We will use Prometheus for collecting metrics.

For clarification as we are dealing with relatively advanced concepts I won’t be really going into detail about what Kubernetes and containers are, How to setup Spinnaker and its components. There is plenty of information available online about these technologies. I’ll also mention here, this is a pure how-to article, with the aim of giving you a platform to test out canary deployments on Spinnaker.

#devops #kubernetes #ci cd pipeline #spinnaker