Canary deployment pattern in Docker - Time & Space Complexity

Time Complexity: Canary deployment pattern

O(n)

Understanding Time Complexity

We want to understand how the time to deploy changes grows when using the canary deployment pattern with Docker.

Specifically, how does adding more users or instances affect deployment time?

Scenario Under Consideration

Analyze the time complexity of the following Docker commands for a canary deployment.

# Deploy new version to 1 container (canary)
docker run -d --name app_1 myapp:v2

# Wait and monitor canary container
# If stable, deploy to rest of containers
for i in $(seq 2 10); do
  docker stop app_$i
  docker rm app_$i
  docker run -d --name app_$i myapp:v2
  sleep 10
  # monitor logs or health
 done

This script deploys a new version first to one container, then sequentially updates the rest after monitoring.

Identify Repeating Operations

Look for repeated steps in the deployment process.

• Primary operation: Stopping, removing, and starting containers one by one.
• How many times: The loop runs for each container after the canary, here 9 times.

How Execution Grows With Input

As the number of containers increases, the deployment time grows roughly in direct proportion.

Input Size (n)	Approx. Operations
10	~10 container updates
100	~100 container updates
1000	~1000 container updates

Pattern observation: Deployment time grows linearly as more containers are updated one after another.

Final Time Complexity

Time Complexity: O(n)

This means deployment time increases directly with the number of containers to update.

Common Mistake

[X] Wrong: "Deploying to multiple containers at once will always be faster and have constant time."

[OK] Correct: Even if started simultaneously, monitoring and ensuring stability often requires sequential checks, so total time usually grows with the number of containers.

Interview Connect

Understanding how deployment time scales helps you design better release strategies and explain trade-offs clearly in real projects.

Self-Check

"What if we deployed all containers in parallel without waiting for monitoring? How would the time complexity change?"

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