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.

Practice

1.

What is the main goal of a canary deployment in Docker?

easy

A. To update a small number of containers first to reduce risk

B. To update all containers at once for faster deployment

C. To delete old containers before deploying new ones

D. To run containers without any updates

Solution

1. Step 1: Understand canary deployment purpose

   Canary deployment updates only a few containers initially to test changes safely.

2. Step 2: Compare options

   Only To update a small number of containers first to reduce risk describes updating a small number of containers to reduce risk, which matches the canary deployment goal.

3. Final Answer:

   To update a small number of containers first to reduce risk -> Option A

4. Quick Check:

   Canary deployment = update few containers first [OK]

Hint: Canary means small test update first, not all at once [OK]

Common Mistakes:

• Thinking canary updates all containers simultaneously
• Confusing canary with blue-green deployment
• Assuming canary deletes old containers immediately

2.

Which Docker command option controls how many containers update at the same time during a canary deployment?

docker service update --help

easy

A. --replicas

B. --update-delay

C. --update-parallelism

D. --rollback

Solution

1. Step 1: Identify update control options

   Docker's --update-parallelism controls how many containers update simultaneously.

2. Step 2: Differentiate from other options

   --update-delay controls wait time between updates, --replicas sets container count, and --rollback reverts updates.

3. Final Answer:

   --update-parallelism -> Option C

4. Quick Check:

   Parallelism = containers updated at once [OK]

Hint: Parallelism means how many update together [OK]

Common Mistakes:

• Confusing delay with parallelism
• Using replicas to control update speed
• Thinking rollback controls update count

3.

Given the command:

docker service update --image myapp:v2 --update-parallelism 2 --update-delay 10s myservice

What happens during this update?

medium

A. Two containers update to v2, then wait 10 seconds before next two

B. Update fails because of wrong syntax

C. One container updates every 10 seconds until all are updated

D. All containers update to v2 immediately

Solution

1. Step 1: Analyze update-parallelism

   It sets 2 containers to update at the same time.

2. Step 2: Analyze update-delay

   It waits 10 seconds between each batch of updates.

3. Final Answer:

   Two containers update to v2, then wait 10 seconds before next two -> Option A

4. Quick Check:

   Parallelism=2 + Delay=10s means batch update with wait [OK]

Hint: Parallelism sets batch size; delay sets wait time [OK]

Common Mistakes:

• Assuming all containers update instantly
• Confusing delay as total update time
• Thinking syntax is incorrect

4.

What is wrong with this command for canary deployment?

docker service update --image myapp:v2 --update-parallelism 0 --update-delay 5s myservice

medium

A. Delay cannot be less than 10 seconds

B. Service name must come before options

C. Image version syntax is incorrect

D. Parallelism cannot be zero; it must be at least 1

Solution

1. Step 1: Check update-parallelism value

   Parallelism controls how many containers update at once and must be at least 1.

2. Step 2: Validate other options

   Delay of 5s is valid; image syntax and option order are correct.

3. Final Answer:

   Parallelism cannot be zero; it must be at least 1 -> Option D

4. Quick Check:

   Parallelism=0 invalid, must be ≥1 [OK]

Hint: Parallelism must be ≥1, zero disables updates [OK]

Common Mistakes:

• Setting parallelism to zero to pause updates
• Thinking delay must be ≥10s
• Misordering command options

5.

You want to deploy a new version of your app with canary deployment using Docker Swarm. You have 10 replicas. You want to update 3 containers at a time, wait 15 seconds between batches. Which command correctly implements this?

hard

A. docker service update --image myapp:v2 --update-parallelism 3 --update-delay 15s --rollback-condition on-failure myservice

B. docker service update --image myapp:v2 --update-parallelism 3 --update-delay 15s myservice

C. docker service update --image myapp:v2 --update-parallelism 3 --update-delay 15s --rollback-on-failure myservice

D. docker service update --image myapp:v2 --update-parallelism 3 --update-delay 15s --rollback myservice

Solution

1. Step 1: Identify correct canary options

   --update-parallelism 3 and --update-delay 15s correctly set batch size and delay; no other flags needed.

2. Step 2: Verify update options

   These match exactly in docker service update --image myapp:v2 --update-parallelism 3 --update-delay 15s myservice.

3. Step 3: Check options in each command

   --rollback-condition and --rollback-on-failure are invalid; --rollback forces rollback instead of update.

4. Final Answer:

   docker service update --image myapp:v2 --update-parallelism 3 --update-delay 15s myservice -> Option B

5. Quick Check:

   Parallelism + delay with valid flags only [OK]

Hint: Parallelism sets batch size; delay sets wait; avoid invalid flags [OK]

Common Mistakes:

• Adding invalid rollback flags
• Missing parallelism or delay options
• Assuming rollback must be specified