11 software delivery problems solved by intelligence software delivery platform  Download
Select Page
Share

In software delivery, a Blue-Green deployment strategy (sometimes known as Red Black Deployment) is one where the old and the new instances of the application or microservice run in parallel at the same time in production, and a load balancer switches traffic from the older version to the newer version.

In this blog, we are going to deploy two versions of an application ( Blue and Green) in production-like environments in Kubernetes.

What is Blue-Green deployment?

Blue-green deployment is a technique that reduces downtime and risk by running two identical production environments called Blue and Green. Blue is the current version, whereas Green is the new version to be deployed. 

At any point of time, only one of the environments is live, with the live environment serving all production traffic. If you are interested to know more, read Blue-Green Deployment.

Once our new version of software has passed all the testing, and is ready for production, DevOps managers usually wait for an approval of a release manager for the final deployment. After the approval, the new version called Green is deployed and then one can just switch the router Green version instead of Blue. Green is now live and takes all the production traffic.

Although Blue-Green can be implemented using NGNIX and simple load balancer, but istio is the easiest and safest way to achieve this implementation.  And since Spinnaker is the widely accepted open-source multicloud continuous delivery solution, we will explore how Blue-Green can be implemented using Spinnaker and istio in the below steps.

Blue Green deployment opsmx

What is Istio?

Istio addresses the challenges developers and operators face as monolithic applications transition towards a distributed microservice architecture.

The term service mesh is used to describe the network of microservices that make up such applications and the interactions between them. As a service mesh grows in size and complexity, it can become harder to understand and manage. Its requirements can include discovery, load balancing, failure recovery, metrics, and monitoring. A service mesh also often has more complex operational requirements, like A/B testing, canary rollouts, rate limiting, access control, and end-to-end authentication.

Istio provides behavioral insights and operational control over the service mesh as a whole, offering a complete solution to satisfy the diverse requirements of microservice applications.

If you are interested,  read more Why istio is necessary for Kubernetes.

PreRequisites for the setup of the Blue-Green implementation:

  1. Kubernetes Cluster.
  2. Istio of required version installed in it.
  3. Kubectl cli installed.

In this blog, we will be taking two versions of nginx applications called v1 (blue) and v2 (green).

Considering v1 is running in the production environment, it will be replaced with the new version v2 of the application using the Spinnaker pipelines.

Steps to Deploy Blue version ( or v1) of the Application:

1. Create a namespace called “nginx”

             Kubectl create ns nginx

2. Labels the namespace to enable istio sidecar.

             Kubectl label ns nginx istio-injection=enabled.

3. Deploy the v1 Version of nginx application. You will need to configure the Blue Config file, Blue Service and Blue Application deployment in Spinnaker. The Spinnaker pipeline looks like the below:

Below are the steps to achieve deployment of the Blue version.

               a. Create the Blue config: Create a Deploy-manifest stage in the Spinnaker pipeline  and provide configuration file of your Blue version. For reference, you can just copy and paste the below content URL in the Spinnaker pipeline https://raw.githubusercontent.com/OpsMx/istio-config/master/nginx/cm/nginx-blue.yaml 

                  b. Create Blue Service: You need to create a Blue-Service stage after the Blue-config stage in the same Spinnaker pipeline and provide the following link in the content URL under the manifest artifact. https://raw.githubusercontent.com/OpsMx/istio-config/master/nginx/svc/nginx-blue.yaml

 

deploy blue service

               c. Create Stage for Blue Application Deployment: You can use deploy_blue.yaml (link below) and use it in the content URL.

https://raw.githubusercontent.com/OpsMx/istio-config/master/nginx/deployments/deploy_blue.yaml 

deploy blue config

4. Creating the virtual service. For accessing NGINX blue application through UI

https://raw.githubusercontent.com/OpsMx/istio-config/master/nginx/vs/main_vs.yaml

deploy blue virtual service

5. Accessing the Blue version of Application. ( Istio ingress controller IP .. pod). In case you have noticed, I have used the background as powderblue.

Accessing the Blue version of Application

Steps to Deploy Green version v2 of the Application:

Deploy the Green version of nginx application. What I have done is changed the background color from powderblue to palegreen in the V2 config file.

You will need to configure a pipeline with the following stages: Green Config file, Green Service, Green Application deployment, split Blue-Green , and Validate Green version, and Switch-to-Green in Spinnaker. The Spinnaker pipeline looks like the below: 

deploy green validate

Deploy the v2 Version of nginx application.

               a. Create the Green config stage as below. You can use the nginx-green.yaml from link: https://raw.githubusercontent.com/OpsMx/istio-config/master/nginx/cm/nginx-green.yaml

deploy green config istio

                b. Create Green Service: Use the below service yaml file in the Green Service stage. https://raw.githubusercontent.com/OpsMx/istio-config/master/nginx/svc/nginx-green.yaml 

deploy green depends on

                c. Deploy Green Application: You can use the deploy_green yaml in the content URL of the Deploy Green Application stage; https://raw.githubusercontent.com/OpsMx/istio-config/master/nginx/deployments/deploy_green.yaml

Deploy Green Application yaml

             d. Update the virtual service to make the traffic 50-50 between blue and Green. https://raw.githubusercontent.com/OpsMx/istio-config/master/nginx/vs/50-50.yaml

spilt blue green

               e. You can use a manual judgement stage to check if both Blue and Green appear as expected. 

validate green deployment

You can check the application using the IP of the pods and then approve the pipeline while execution to apply the final changes.

Since the traffic is getting split equally between Blue and Green version by istio Gateway controller in round-robin fashion, so you may not be able to see the Green version of the application in the first go. Please refresh a couple of times for the background to change from powderblue color to palegreen.

Blue and Green version by istio Gateway

Once the testing is done and you approve the validation stage of the Spinnaker pipeline, you will want to flip the version from v1 (Blue) to v2 ( Green) completely.

Configure the final stage Switch-to-Green using the following yaml file. 

https://raw.githubusercontent.com/OpsMx/istio-config/master/nginx/vs/blue_green.yaml

You will notice that the changes have taken place permanently and the background appears as palegreen color

Configure the final stage Switch to Green

Conclusion

Blue-Green deployment implementation has been used by many SREs and DevOps engineers of many Fortune 100 companies who want to avoid downtime during product or service implementation. If you want to try complex deployment strategies like blue-green or canary then explore more from our repository of sample pipliens in Github.

Do contact us, in case you have any questions.

For Spinnaker users, who want to enhance visibility, configuration and security, we have launched a free Spinnaker add-on. Do try.

Tags : Spinnaker

Vamsi Krishna

Vamsi Krishna is a Software Engineer at OpsMx and has over 5+ years of industrial expertise in the DevOps domain. He has previously worked in companies like IBM, Kloud9. His current assignments involve, build and release activities with the high efficient CI/CD tools on to the different environments (both on-prem and Cloud), design and build and deliver highly scalable applications while extending existing Open Source platforms. He has fair knowledge in building a microservice-based application on to the Kubernetes Clusters hosted on different cloud Environments and in integrating DevOps Applications end to end and implementing the complete Automated systems as per the requirements. He holds CKA certification. He has also developed ticketing systems using Jira Administration for the Projects. His areas of expertise include - Cloud, GCP, Kubernetes/ Docker, Jenkins, Jira,Git, High Availability.

0 Comments

Submit a Comment

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.