Konrad Kowalski (rootsher)Principal Platform & Reliability Architect101100101011000101100011101111111000110101101010

Blue-Green Deployment: Two Versions, One Traffic Path

date
category
CI/CD
also in
Reliability Engineering
reading
1 min / 211 words

Rolling update replaces the system piece by piece.

Sometimes that is not enough.

If rollback through another rollout takes too long, the simpler idea is:

text
keep the old version ready
start the new version next to it
switch traffic in one move

That is blue-green deployment.

One version serves users.

The other waits ready to receive traffic.

Minimal example

We have two Deployment objects.

yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-blue
spec:
  replicas: 3
  selector:
    matchLabels:
      app: api
      version: blue
  template:
    metadata:
      labels:
        app: api
        version: blue
    spec:
      containers:
        - name: api
          image: ghcr.io/example/api:1.9.0
yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-green
spec:
  replicas: 3
  selector:
    matchLabels:
      app: api
      version: green
  template:
    metadata:
      labels:
        app: api
        version: green
    spec:
      containers:
        - name: api
          image: ghcr.io/example/api:2.0.0

Traffic is selected by Service.

yaml
apiVersion: v1
kind: Service
metadata:
  name: api
spec:
  selector:
    app: api
    version: blue
  ports:
    - port: 80
      targetPort: 3000

Switching to green means changing the selector:

yaml
selector:
  app: api
  version: green

In practice, this can be done through GitOps, a patch, rollout orchestration, or routing above the Service.

The mechanism is the same:

text
the new version was ready before the switch

What it is really for

Blue-green is useful when we want to separate:

text
deploying the new version
switching users to it

You can test green before production traffic reaches it.

You can quickly return to blue if the bug is in application code or configuration.

That helps services where cold start is expensive or rollback through another rollout is too slow.

Where the name lies

Blue-green sounds like full rollback.

Often, it is only traffic rollback.

If both versions use the same database, changing a Service will not undo:

text
schema migrations
new records
changed formats
published events
queued jobs

Blue-green needs the same compatibility discipline as rolling update.

The difference is that we do not mix versions behind one Service for a long time.

But the data is still shared unless we deliberately separate it.

So blue-green is a traffic switching strategy.

It is not magic system rewind.