Canary deployment pattern in Docker - Step-by-Step Execution

Process Flow - Canary deployment pattern

Start Deployment

↓

Deploy New Version to Small Subset

↓

Monitor Metrics & Logs

↓

Is New Version Stable?

No→Rollback to Old Version

Yes↓

Gradually Increase Traffic to New Version

↓

Full Traffic Routed to New Version

↓

Complete Deployment

The canary deployment gradually shifts traffic to a new version, monitoring stability before full rollout or rollback.

Execution Sample

Docker

docker service update --image myapp:v2 --limit-cpu 0.1 --replicas 1 myapp
# Monitor logs and metrics
# Increase replicas to 5 if stable
# Finally update replicas to 10 for full rollout

This sequence updates a Docker service to a new version with limited replicas, monitors it, then scales up if stable.

Process Table

Step	Action	Replicas	Traffic % to New Version	Status	Notes
1	Deploy new version with 1 replica	1	10%	Running	Initial canary deployment
2	Monitor logs and metrics	1	10%	Stable	No errors detected
3	Increase replicas to 5	5	50%	Running	Half traffic to new version
4	Monitor logs and metrics	5	50%	Stable	Performance good
5	Increase replicas to 10	10	100%	Running	Full traffic to new version
6	Monitor logs and metrics	10	100%	Stable	Deployment complete
7	End	10	100%	Complete	Canary deployment successful

💡 Full traffic routed to new version and deployment marked complete

Status Tracker

Variable	Start	After Step 1	After Step 3	After Step 5	Final
Replicas	10 (old version)	1 (new version)	5 (new version)	10 (new version)	10 (new version)
Traffic % to New Version	0%	10%	50%	100%	100%
Status	Running old version	Running new version	Running new version	Running new version	Complete

Key Moments - 3 Insights

Why do we start with only 1 replica and 10% traffic instead of switching all at once?

Starting small limits risk. If the new version has issues, only a small part of users are affected. This is shown in execution_table steps 1 and 2 where only 1 replica handles 10% traffic.

What happens if the new version is not stable during monitoring?

If instability is detected, the deployment should rollback to the old version to avoid impacting users. This is the 'No' branch in the concept_flow after monitoring.

Why do we gradually increase replicas and traffic instead of jumping directly to full rollout?

Gradual increase allows catching problems early and ensures stability at each stage. Execution_table steps 3 and 5 show this gradual scaling.

Visual Quiz - 3 Questions

Look at the execution_table, what is the traffic percentage to the new version after step 3?

A 50%

B 10%

C 100%

D 0%

💡 Hint

Check the 'Traffic % to New Version' column at step 3 in the execution_table.

At which step does the deployment reach full traffic to the new version?

A Step 1

B Step 5

C Step 3

D Step 2

💡 Hint

Look for 100% traffic in the 'Traffic % to New Version' column in the execution_table.

If the new version was unstable at step 2, what would be the correct action?

A Increase replicas to 5

B Increase traffic to 50%

C Rollback to old version

D Complete deployment anyway

💡 Hint

Refer to the concept_flow decision after monitoring metrics for stability.

Concept Snapshot

Canary Deployment Pattern:
- Deploy new version to small subset (e.g., 1 replica, 10% traffic)
- Monitor logs and metrics for stability
- Gradually increase traffic and replicas if stable
- Rollback immediately if issues detected
- Full rollout only after successful canary phase

Full Transcript

The canary deployment pattern is a safe way to release new software versions. It starts by deploying the new version to a small part of the system, like 1 replica handling 10% of traffic. Then, it monitors the system's health and performance. If stable, it gradually increases the number of replicas and traffic percentage to the new version. If any problems appear, it rolls back to the old version to protect users. This step-by-step approach reduces risk and ensures smooth updates.