Progressive Delivery With Argo Rollouts: Blue-Green Deployment

Continuous integration (CI) and continuous delivery (CD) have been widely adopted in modern software development enabling organizations to quickly deploy these software to customers. But doing it in the right way is equally important, as in some cases, unfinished code can lead to failures and customers have to face downtime. To solve this, progressive delivery was introduced, which enables the delivery of software with the right changes to the right amount of customers at the right time. More precisely, it controls the speed at which changes are deployed for a software.

Traditional CI/CD and Progressive Delivery

Continuous integration (CI) is an automation process that helps in continuously integrating software development changes. It automates the building, testing, and validation of the source code. Its goal is to ultimately produce a packaged artifact that is ready to deploy.

Continuous delivery (CD) helps in deploying software changes to users. It needs CI to produce an artifact that can be deployed to users.

But continuous delivery poses many challenges, such as handling fast delivery of changes and managing high-risk failures to ensure uptime and efficient software performance. To solve the above problems of continuous delivery, progressive delivery comes into action along with different deployment strategies like blue-green deployment and canary deployment.

Progressive delivery is one step ahead of continuous delivery. It enables the delivery of software updates in a controlled manner by reducing the risks of failures. It is done by first exposing new software changes to a smaller set of users. Then, by observing and analyzing the correct behavior, it is then exposed to more users progressively. It is known to move fast, but with more control.

Challenges With Default “RollingUpdate” Kubernetes Deployment Strategy

Kubernetes comes with a default RollingUpdate deployment strategy. At present, it has the following set of limitations:

• Fewer controls over speed of the rollout
• Inability to control traffic flow to the new version
• Readiness probes cannot be used for deeper, stress, or one-time checks
• You cannot query external metrics to verify an update
• You can halt the progression, but you cannot automatically abort and roll back the update

Argo Projects

Argo is a group of many open-source projects which help in the fast and safe delivery of software by extending the capabilities of Kubernetes.

• Argo Workflows: Container-native workflow engine
• Argo CD: Declarative GitOps continuous delivery
• Argo Events: Event-based dependency manager
• Argo Rollouts: Progressive delivery with support for Canary and blue-green deployment strategies
• Argoproj-labs: Separate GitHub org that is setup for community contributions related to the Argoproj ecosystem

To overcome the limitations of native Kubernetes deployment strategies, Argo Rollouts has been introduced. It contains a different set of projects as detailed below.

What Is Argo Rollouts?

Argo Rollouts is a Kubernetes controller and a set of CRDs which provides progressive delivery features along with advanced deployments such as blue-green, canary, and canary analysis. It has the potential to control and shift traffic to a newer version of software through ingress controllers and service meshes.

The below table shows a comparative analysis of capabilities of the default Kubernetes deployment strategy vs. Argo Rollouts.

How Does Argo Rollouts Work?

The Argo Rollouts controller helps in finding and detecting the resource of a kind: Rollout in the cluster which manages the replicasets just like Kubernetes deployment does. It creates a stable replicaset for the older version of the software and a canary replicaset for the newer version of the software.

Source: Argo-Rollout-Architecture

The AnalysisTemplate helps in doing the analysis of the replicasets through the AnalysisRun component. Together, they help to observe the working of the newly deployed version. Accordingly, it can automatically roll out to a newer version or roll back it. For this one can use any metrics tool like Prometheus, Kubernetes jobs, and so on.

Lab/Hands-on of Argo Rollouts With Blue-Green Deployments

If you do not have a K8s cluster readily available to do further labs, then we recommend trying the CloudYuga platform-based version of this article. Otherwise, you can set up your own kind local cluster with nginx controller also deployed, and follow along to execute the below commands against your kind cluster.

Clone the Argo Rollouts example GitHub repo, or preferably, please fork this:

git clone https://github.com/NiniiGit/argo-rollouts-example.git

Installation of Argo Rollouts Controller

Create the namespace for installation of the Argo Rollouts controller.

kubectl create namespace argo-rollouts

You will see the namespace has been created.

kubectl get ns argo-rollouts

We will use the latest version to install the Argo Rollouts controller.

kubectl apply -n argo-rollouts -f https://github.com/argoproj/argo-rollouts/releases/latest/download/install.yaml

You will see the controller and other components have been deployed. Wait for the pods to be in the Running state.

kubectl get all -n argo-rollouts

Install Argo Rollouts Kubectl plugin with curl for easy interaction with Rollout controller and resources.

curl -LO https://github.com/argoproj/argo-rollouts/releases/latest/download/kubectl-argo-rollouts-linux-amd64
chmod +x ./kubectl-argo-rollouts-linux-amd64
sudo mv ./kubectl-argo-rollouts-linux-amd64 /usr/local/bin/kubectl-argo-rollouts
kubectl argo rollouts version

Argo Rollouts comes with its own GUI as well that you can access with the below command.

kubectl argo rollouts dashboard

Now you can access Argo Rollout console, by accessing http://localhost:3100 on your browser. You will be presented with a UI as shown below (currently, it won’t show you anything, since we are yet to deploy any Argo Rollouts-based app).

Now, let’s go ahead and deploy our first sample app using the blue-green deployment strategy.

Blue-Green Deployment With Argo Rollouts

To experience how blue-green deployment works with Argo Rollouts, we will deploy the sample app which contains Rollouts, Service, and Ingress as Kubernetes objects.

rollout.yaml content:

# This example demonstrates a Rollout using the blue-green update strategy, which contains a manual
# gate before promoting the new stack.
apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: rollout-bluegreen
spec:
  replicas: 2
  revisionHistoryLimit: 2
  selector:
    matchLabels:
      app: rollout-bluegreen
  template:
    metadata:
      labels:
        app: rollout-bluegreen
    spec:
      containers:
      - name: rollouts-demo
        image: argoproj/rollouts-demo:blue
        imagePullPolicy: Always
        ports:
        - containerPort: 8080
  strategy:
    blueGreen: 
      # activeService specifies the service to update with the new template hash at time of promotion.
      # This field is mandatory for the blueGreen update strategy.
      activeService: rollout-bluegreen-active
      # previewService specifies the service to update with the new template hash before promotion.
      # This allows the preview stack to be reachable without serving production traffic.
      # This field is optional.
      previewService: rollout-bluegreen-preview
      # autoPromotionEnabled disables automated promotion of the new stack by pausing the rollout
      # immediately before the promotion. If omitted, the default behavior is to promote the new
      # stack as soon as the ReplicaSet are completely ready/available.
      # Rollouts can be resumed using: `kubectl argo rollouts promote ROLLOUT`
      autoPromotionEnabled: false

service.yaml content:

kind: Service
apiVersion: v1
metadata:
  name: rollout-bluegreen-active
spec:
  selector:
    app: rollout-bluegreen
  ports:
  - protocol: TCP
    port: 80
    targetPort: 8080

---
kind: Service
apiVersion: v1
metadata:
  name: rollout-bluegreen-preview
spec:
  selector:
    app: rollout-bluegreen
  ports:
  - protocol: TCP
    port: 80
    targetPort: 8080

ingress.yaml content:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: rollout-bluegreen
  annotations:
    kubernetes.io/ingress.class: nginx
spec:
  rules:
  - http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: rollout-bluegreen-active
            port:
              number: 80

Now, let’s create all these objects for now in the default namespace. Please execute the below commands:

kubectl apply -f argo-rollouts-example/blue-green-deployment-example/

You will be able to see all the objects that have been created in the default namespace by running the below commands:

kubectl get all

Now, you can access your sample app by accessing http://localhost:80 on your browser.
You will be able to see the app as shown below:

Now, visit the Argo-Rollouts console again. This time, you can see the sample deployed on the Argo Rollouts console as below:

You can click on this rollout-bluegreen in the console and it will present you with its current status as below:

Going forward, either you can use this GUI or else (preferably) use the commands shown below to continue with this demo.

You can see the current status of this rollout by running the below command as well.

kubectl argo rollouts get rollout rollout-bluegreen

Now, let’s deploy the Green version of the app via command line.

kubectl argo rollouts set image rollout-bluegreen rollouts-demo=argoproj/rollouts-demo:green

You will be able to see new, i.e., green version based set of pods of our sample app:

kubectl get pods

Now, after a few seconds, you will be able to see both your old set of pods (with version blue) as well as the new set of pods (with version green) available. Also on the Argo console, you will be able to see the new revision of the app with the changed image version running, as below.

If you visit the http://localhost:80 on your browser, you will still see only the blue version is visible —rightly because we have not yet fully promoted the green version of our app. You can confirm the same now, by running the command below, which shows the new version is in a paused state.

kubectl argo rollouts get rollout rollout-bluegreen

Now, let us promote the green version of our app, by executing the below command.

kubectl argo rollouts promote rollout-bluegreen

Run the following command and you will see it’s scaling the new, i.e., green version of our app completely.

kubectl argo rollouts get rollout rollout-bluegreen

The same can be confirmed by running the below command, which shows the old set of pods, i.e., the old blue version of our app, terminating or already terminated.

kubectl get pods

If you visit the app URL on http://localhost:80 on your browser, you would see only the green version is visible right now because we have fully promoted the green version of our app.

Congratulations! You have successfully completed a blue-green deployment using Argo Rollouts.

You can delete this entire setup, i.e., our sample deployed app using the below command.

kubectl delete -f argo-rollouts-example/blue-green-deployment-example/

Summary

In this article, we discussed what progressive delivery is all about and its characteristics. We also learned about Argo Rollouts' custom controller and how it can help to achieve blue-green deployment, which is ultimately a form of progressive delivery.

I hope you found this article informative and engaging. 

What's next? Now that we have developed an understanding of progressive delivery and created a blue-green deployment, next would be to try canary deployment using Argo Rollouts.