Blue Green Deployments

Blue Green deployments allow the next version (let's call it preview) of your application to be in the same environment as your active version for some time - until all your sanity checks are approved and you "promote" the preview to active
Getting Started
There are five core steps to support a Blue Green deployment for an existing Kubernetes Deployment:
Ensure your target (destination) Kubernetes cluster(s) have the Argo Rollouts controller installed (see Install DeployNow Agent for more info)
In your manifest/template, replace kind: Deployment to kind: Rollout
In your manifest/template, replace apiVersion: apps/v1 to apiVersion: argoproj.io/v1alpha1
In your manifest/template, replace spec.strategy with blueGreen and add any specific configurable features you like.
To support a preview service, add a kind: Service which is identical to your current "active" service, but change the name.
Example
A good sample app to show off this feature is from the Argo Rollouts blue-green example manifests.
Say we have a manifest, rollout-bluegreen.yaml, like so:
YAML
# 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:green
        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

---
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

# 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:green
        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

---
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
﻿
Note the extra preview Service and the app set to image: argoproj/rollouts-demo:blue.
Create an Argo App which points to this manifest:
﻿
Since this is the initial rollout, notice how nothing is suspended and active is pointing to green
﻿
Port forwarding the active service shows green:
Shell
$ kubectl port-forward svc/rollout-bluegreen-active 8080:80
$ kubectl port-forward svc/rollout-bluegreen-active 8080:80
﻿
﻿
Everything is as expected.
Update to a new version of the app
Now, let's update our Git repo to change the version from green to blue:
﻿
When your Argo App is next synced, notice how it gets in a Suspended state:
﻿
This simply means there's a new version of your app, and your current active service will still be pointing to the original version until you promote.
This is proven by port-forwarding both of the services and checking:
Shell
$ kubectl port-forward svc/rollout-bluegreen-active 8080:80
$ kubectl port-forward svc/rollout-bluegreen-active 8080:80
﻿
﻿
Shell
$ kubectl port-forward svc/rollout-bluegreen-preview 8080:80
$ kubectl port-forward svc/rollout-bluegreen-preview 8080:80
﻿
﻿
The preview service can be sanity checked until you are ready to promote it to active.
Promote the new app version to active
When you are ready to promote the preview to active, you may click on Promote-Full of the rollout:
﻿
At this point, the argo-rollouts controller will ensure that all replicas of the pod have the preview pods promoted and the active service will route traffic to that pod.
We can confirm this by looking at the active service (which should now be "blue"):
Text
$ kubectl port-forward svc/rollout-bluegreen-active 8080:80
$ kubectl port-forward svc/rollout-bluegreen-active 8080:80
﻿
﻿
﻿
Did this page help you?
RBAC configuration
Canary Deployments