Blue/Green Deployments with ArgoCD in Kubernetes

Introduction

Blue/Green deployments are a popular strategy for managing releases and minimizing downtime and risk. By having two identical environments, the “blue” and “green”, we can switch traffic between them to release new versions of an application. In this article, we will explore how to implement a Blue/Green deployment strategy using ArgoCD in a Kubernetes environment.

Why Blue/Green Deployments?

Blue/Green deployments bring several benefits:

1. Reduced downtime: The new version can be deployed and tested in the ‘inactive’ environment before switching traffic to it. This results in virtually zero downtime during the release process.
2. Risk Mitigation: If something goes wrong with the new release, we can quickly switch back to the ‘active’ environment without needing to rollback the faulty release.
3. Simpler Testing: It is easy to test the new version in a production-like environment before it receives any real user traffic.

Setting up ArgoCD in Kubernetes

ArgoCD is a declarative, GitOps continuous delivery tool for Kubernetes. It follows the principle of Infrastructure as Code (IaC), allowing infrastructure setup to be version-controlled and automated.

Here are the basic steps to set up ArgoCD in a Kubernetes cluster:

# Create a new namespace for ArgoCD
kubectl create namespace argocd

# Apply the ArgoCD Install Manifest
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/v2.0.3/manifests/install.yaml

After installation, you can access the ArgoCD API server using port-forward:

kubectl port-forward svc/argocd-server -n argocd 8080:443

Implementing Blue/Green Deployments with ArgoCD

ArgoCD supports automated Blue/Green deployments via a Custom Resource Definition (CRD) called Application.

Let’s consider a simple example where we have two environments, “blue” and “green”, each represented as a namespace in our Kubernetes cluster.

We will use a Kubernetes Service to manage the traffic routing between these environments. The Service will select pods based on a label, say color, which can be either blue or green.

Initially, the Service will be configured to route traffic to the blue environment.

apiVersion: v1
kind: Service
metadata:
  name: my-app
spec:
  selector:
    color: blue
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080

When we want to deploy a new version of our application, we deploy it to the green environment. We can use ArgoCD to synchronize the green environment with the desired state described in our Git repository.

Once we are ready to switch traffic to the green environment, we simply need to update the Service to select green pods:

apiVersion: v1
kind: Service
metadata:
  name: my-app
spec:
  selector:
    color: green
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080

In ArgoCD, this can be done via a manual sync, or it can be automated using ArgoCD’s Webhook functionality.

Conclusion

Blue/Green deployments provide a powerful strategy for minimizing downtime and risk during software releases. By leveraging the capabilities of ArgoCD and Kubernetes, we can automate this process and make it part of our continuous delivery pipeline.

It’s important to note that while Blue/Green deployments can greatly reduce risks associated with releasing new versions of your software, it is not a silver bullet. This strategy requires careful planning and thorough testing. It also requires careful management of data, especially for stateful applications where database schemas may change between versions.

By automating the process with ArgoCD and Kubernetes, we can ensure that our deployments are reproducible, traceable, and that they adhere to the principles of Infrastructure as Code (IaC). This brings us one step closer to the goal of full automation and reliability in our release process.