Blue/Green Deployments in Amazon EKS using Flagger
Table of Contents
- Sample App
- Blue Environment
- Flagger Canary
- Green Environment
- About the Author ✍🏻
Flagger is a progressive delivery tool that automates the release process for applications running on Kubernetes. It reduces the risk of introducing a new software version in production by gradually shifting traffic to the new version while measuring metrics and running conformance tests.
This article describes in detail how to achieve the simplest blue/green deployment of an app in Kubernetes. Here’s what we’re looking for:
- There’s a live, production version of an app running in our cluster: the blue version
- We deploy a new version (the green version) of this app, alongside the blue one
- We manually run tests on the green version
- If all tests pass, we promote the green version to be the new live/prod/blue version
This article assumes familiarity with Flagger concepts like the Canary CRD. If you’re new to Flagger, please read the Flagger introduction first.
Before we begin, let’s simulate a production (blue) environment using a sample app. We’ll use “the parrot app” from Jérôme Decoster‘s awesome blog post. This fun little app simply shows the image of a blue parrot when you hit the blue version & a green parrot when you hit the green version:
Start by deploying the following deployment & ingress into your cluster:
apiVersion: apps/v1 kind: Deployment metadata: name: parrot namespace: blue-green spec: replicas: 1 selector: matchLabels: app: parrot template: metadata: labels: app: parrot spec: containers: - name: parrot image: kmharish/parrot-app:v1.2 ports: - containerPort: 3000
apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: parrot namespace: blue-green labels: app: parrot spec: ingressClassName: nginx rules: - host: parrot.example.com http: paths: - path: / pathType: Prefix backend: service: name: parrot port: number: 80
Note that we’re using the NGINX ingress controller with Flagger.
Instead of creating the parrot service ourselves, we let Flagger manage it by creating a Flagger Canary CRD:
apiVersion: flagger.app/v1beta1 kind: Canary metadata: name: parrot namespace: blue-green spec: provider: nginx targetRef: apiVersion: apps/v1 kind: Deployment name: parrot ingressRef: apiVersion: networking.k8s.io/v1 kind: Ingress name: parrot service: port: 80 targetPort: 3000 analysis: interval: 1m iterations: 1 threshold: 60 # auto-destroy green env after 1 hour webhooks: - name: confirm-promotion type: confirm-promotion url: https://webhook.site/6f0ce11c-d2d8-4375-895d-a5c1ec90a323
targetRef tells Flagger which deployment to manage.
ingressRef tells Flagger which ingress to manage.
service block tells Flagger what parameters to use for the parrot service it generates.
Since we’re only interested in manual testing of our green environment, the only canary analysis we ask Flagger to run, is to call a webhook which tells it when it’s OK to promote green to blue.
analysis.interval = 1 minute means Flagger will call the webhook every minute.
Since we’re not creating a canary scenario wherein traffic is shifted gradually from blue to green in several iterations, we set
analysis.iterations = 1 so all traffic shifts from blue to green when the webhook gives the OK.
analysis.threshold = 60 means if the webhook returns 60 consecutive failure responses, destroy the canary & don’t promote it to blue. This combined with the
analysis.interval of 1 minute gives us 1 hour to run our manual tests on the canary & promote it, before it expires.
analysis.webhooks defines the webhook to call every minute to check whether it’s time to promote the canary to prod. You can create your own webhook at webhook.site. Configure it to respond with HTTP 500 till it’s time to promote the canary.
Deploy a new (green) version of the app by changing its image:
kubectl set image deploy/parrot parrot=kmharish/parrot-app:v2.2
This causes Flagger to create the green environment. You can now test the new version using the service
parrot-canary. Once testing passes, reconfigure the webhook to send HTTP 200. When Flagger notices this, it will replace the blue version with the new version.
Congratulations! You’ve just deployed a new version of your app using the blue/green deployment strategy!
About the Author ✍🏻
Harish KM is a Principal DevOps Engineer at QloudX & a top-ranked AWS Ambassador since 2020. 👨🏻💻
With over a decade of industry experience as everything from a full-stack engineer to a cloud architect, Harish has built many world-class solutions for clients around the world! 👷🏻♂️
With over 20 certifications in cloud (AWS, Azure, GCP), containers (Kubernetes, Docker) & DevOps (Terraform, Ansible, Jenkins), Harish is an expert in a multitude of technologies. 📚
These days, his focus is on the fascinating world of DevOps & how it can transform the way we do things! 🚀