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:
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.
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
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.
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:
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:
the new version was ready before the switch
What it is really for
Blue-green is useful when we want to separate:
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:
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.