With the adoption of microservices and containers, software teams try to deploy their software into production safely. Many teams use deployment strategies like canary, blue/green, and A/B testing based on their business requirements. Previously we discussed how to deploy software using a canary deployment strategy using Argo Rollouts and Istio. In this article, we will discuss deploying software into the Kubernetes cluster using a blue/green strategy with Argo Rollouts and the NGINX ingress controller.
Brief about blue/green deployment
In software delivery, a blue-green deployment is a technique for releasing new software versions by maintaining two separate yet identical environments, called the blue and the green. The existing production environment is called the blue environment, whereas the new software version is deployed to the green environment. Upon a thorough test and validation, the green environment is switched to the production environment by routing traffic to the green environment. This makes the green environment the new blue environment. The former blue can be taken down once the new Blue environment becomes stable.
If you want to know more about it, please read about blue/green deployment.
Before we begin
A crude way of implementing a blue/green strategy is to consider the following 3 steps:
- Configure network: Configure the NGINX to control the incoming traffic and direct to an application (stable and blue/green versions)
- Configure deployment agent: Configure Argo Rollout and set rules to release a new version to production using blue/green deployment.
Configure NGINX to split traffic among blue and green services
We have used NGINX to split the traffic between two application versions- blue and green. Once the performance and quality of the new version are validated and verified, the older version (or blue version) can be deprecated eventually.
The below mentioned declaration of NGINX ingress controller provides traffic splitting for blue/green to bluegreen-deployment of rollouts kind.:
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: bluegreen-deployment
annotations:
kubernetes.io/ingress.class: nginx
spec:
rules:
- http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: bluegreen-active
port:
number: 80
Let us now understand the Argo Rollout configurations.
Configure Argo Rollouts to deploy blue/green and rules for analysis
The Argo Rollouts is a K8s controller that offers a set of CRDs to implement blue/green deployment. Argo Rollouts would integrate with the ingress controller (in our case, NGINX) to gradually achieve the run-time traffic splitting ability to shift the traffic to the new (green) version. Argo provides a workload resource called Rollouts for deploying applications into Kubernetes in the form of blue and green (Read more about the Rollout blue/green templates). Note: Rollout is an extension of the Deployment/ReplicaSet resource in Kubernetes.
You have to have a service to deploy a sample application. ( Note: we will use the Argo Rollouts resource instead of the deployment resource in K8s to implement the blue/green strategy). As you can see, the Rollout bluegreen-deployment workload refers to blue and green services- bluegreen-active and bluegreen-passive services.
apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
name: bluegreen-deployment
spec:
replicas: 3
revisionHistoryLimit: 3
selector:
matchLabels:
app: bluegreen-deployment
template:
metadata:
labels:
app: bluegreen-deployment
spec:
containers:
- name: bluegreen-demo
image: argoproj/rollouts-demo:blue
imagePullPolicy: Always
ports:
- containerPort: 8080
strategy:
blueGreen:
activeService: bluegreen-active
previewService: bluegreen-preview
autoPromotionEnabled: false
Apply the bluegreen deployment resource of Argo Rollout kind using the following command.
kubectl apply -n deb-ns -f .\Argorollout-bluegreen-deployment.yaml
I have used my own namespace (deb-ns) for deploying the Rollout resources. After applying this, you can open the Argo Rollout dashboard by using the command:
kubectl argo rollouts dashboard
You can access the Argo Rollouts UI from the browser with the link: http://localhost:3100/rollouts/.
You have to create two services bluegreen-active and bluegreen-preview which can be pointed at the Argo Rollouts deployment resource. Refer to the services below.
kind: Service
apiVersion: v1
metadata:
name: bluegreen-active
spec:
selector:
app: bluegreen-deployment
ports:
- protocol: TCP
port: 80
targetPort: 8080
---
kind: Service
apiVersion: v1
metadata:
name: bluegreen-preview
spec:
selector:
app: bluegreen-deployment
ports:
- protocol: TCP
port: 80
targetPort: 8080
Apply the services in your cluster.
Often that whenever there are changes in the image (change to Rollout manifest file), Argo Rollouts will detect a new version and create another replica of the application (with new Revision).
Blue/green deployment from the Argo Rollouts UI
Once you run the application using the http://localhost:3100/rollouts/rollout/, it would showcase something like below:
You can update the image to the ‘green’ version, you would observe that Argo Rollouts would automatically create another replica called Revision-2 with the ‘green’ version of application. Once you promote the new version to your cluster, Argo Rollouts would then automatically terminate the pods of the older version (blue) and make the ‘green’ version ready to take the traffic. Refer to the video below:
Conclusion
We have discussed implementing one of the important progressive delivery strategies- blue/green deployment- using Argo Rollouts. Deploying microservices using blue/green is an essential feature in software delivery for all the DevOps and CI/CD teams across the industries to release their product quickly and without risks. I hope you find this post helpful.
If you want to learn about the best practices wrt blue/green deployment or canary deployment strategy, talk to one of our CI/CD experts. We help Fortune 500 companies achieve continuous and progressive delivery using Argo CD or Spinnaker.
About OpsMx
Founded with the vision of “delivering software without human intervention,” OpsMx enables customers to transform and automate their software delivery processes. OpsMx builds on open-source Spinnaker and Argo with services and software that helps DevOps teams SHIP BETTER SOFTWARE FASTER.
0 Comments