With Sitecore announcing that they will no longer support Azure App Service from version 10.2, more and more Sitecore customers will need to start to think about and plan the inevitable upgrade from their current application development and hosting environment to the ways of containers and Kubernetes.
As I’ve helped more and more Sitecore solutions moving to the Kubernetes platform, I see common requests where they want to maintain the Blue/Green deployment as part of the quality assurance process.
I’d like to share with you the process of implementing Blue/Green deployment on Kubernetes and it doesn’t matter whether you’re using Azure Kubernetes Service (AKS), Amazon Elastic Kubernetes Service (EKS), or Google Kubernetes Service (GKS). You can apply the same principle to any of the Kubernetes managed service that you have.
Kubernetes Rolling-Forward deployment
The default Kubernetes deployment model is a rolling forward deployment model. In which, the new version of applications that you deployed will live side-by-side with the old versions for a short amount of time until they are ready to be swapped over and receive live traffic. This entire process is automated and when done correctly supports zero downtime.
An ilustration of the rolling forward deployment model
Let’s describe what happens in the example above:
1. Version 1 of the application are running on Kubernetes and serving live traffic.
2. A new version was deployed and the deployment instruction defined 2 replicas of version 2 to be deployed. At this point, one CD pod have been created.
3. The deployed version 2 then gets initialized, running, passed the health checks and ready to receive live traffic. Kubernetes then start to redirect live traffic to the pod. Another new version 2 pod has been created.
4. The latest version 2 pod now ready to receive traffic and Kubernetes starts to redirect live traffic to that pod. Now all live traffic are hitting version 2 pods.
As you can see above, the switch for version 2 to be made publicly available is done automatically, and some customers might have a different requirement where they want version 2 to be tested by their internal tester before giving the go-ahead for going live as part of their quality assurance process.
Kubernetes Blue/Green Deployment
Now let’s take a look at how we can implement Blue/Green deployment.
Here’s a quick ilustration.
Essentially the main difference here is the fact that we have a separate Kubernetes service for version 1 and version 2, labelled as CD-Blue and CD-Green.
Once version 2 is fully deployed, we’ll update Kubernetes Ingress which is responsible for routing the live traffic request to a service (either CD-Blue and CD-green)
An example of Kubernetes Ingress manifest pointing live traffic to cd-blue
apiVersion: extensions/v1beta1 kind: Ingress metadata: name: cd-ingress annotations: nginx.ingress.kubernetes.io/proxy-buffer-size: "32k" nginx.ingress.kubernetes.io/affinity: "cookie" nginx.ingress.kubernetes.io/rewrite-target: / spec: rules: - host: www.habitat-demo.com.au http: paths: - path: / backend: serviceName: cd-blue servicePort: 80 - host: uat.habitat-demo.com.au http: paths: - path: / backend: serviceName: cd-green servicePort: 80
And that’s it. Without going into too many details that’s how you would implement a Blue/Green deployment with your Sitecore solution on Kubernetes.
Hope this helps.