Canary deployment pattern in Docker - Commands & Configuration

Introduction

When you want to update your app without risking all users seeing a broken version, canary deployment helps. It sends the new version to a small group first, then gradually to everyone if all goes well.

When releasing a new feature and you want to test it with a small group of users first

When fixing a bug and you want to make sure the fix works before full rollout

When updating your app but want to reduce downtime and risk

When you want to monitor the new version's performance before full deployment

When you want to rollback quickly if the new version causes problems

Config File - docker-compose.yml

docker-compose.yml

version: '3.8'
services:
  app:
    image: my-app:stable
    ports:
      - "80:80"
  app_canary:
    image: my-app:canary
    ports:
      - "8080:80"
    deploy:
      replicas: 1
      labels:
        - "traefik.http.routers.app_canary.rule=PathPrefix(`/`) && Headers(`X-Canary`, `true`)"

This file defines two services: app runs the stable version on port 80, and app_canary runs the new canary version on port 8080.

The canary service is set to one replica to limit exposure.

Labels can be used by a reverse proxy like Traefik to route only users with a special header to the canary version.

Commands

Start both the stable and canary app versions in the background so they run simultaneously.

Terminal

docker-compose up -d

Expected Output

Creating network "default" with the default driver

Creating volume "default_app_data" with default driver

Creating default_app_1 ... done

Creating default_app_canary_1 ... done

→

-d - Run containers in detached mode (in the background)

Check that both the stable and canary containers are running.

Terminal

docker ps

Expected Output

CONTAINER ID   IMAGE          COMMAND                  CREATED          STATUS          PORTS                    NAMES

abc123def456   my-app:stable  "/bin/sh -c 'npm start'"  10 seconds ago   Up 9 seconds    0.0.0.0:80->80/tcp       default_app_1

xyz789ghi012   my-app:canary  "/bin/sh -c 'npm start'"  10 seconds ago   Up 9 seconds    0.0.0.0:8080->80/tcp     default_app_canary_1

Send a request with the special header to test the canary version directly.

Terminal

curl -H "X-Canary: true" http://localhost:8080

Expected Output

<html><body><h1>Welcome to my-app Canary Version</h1></body></html>

Send a normal request to the stable version to confirm it is still serving users.

Terminal

curl http://localhost:80

Expected Output

<html><body><h1>Welcome to my-app Stable Version</h1></body></html>

Key Concept

If you remember nothing else from this pattern, remember: deploy the new version to a small user group first, then gradually shift all traffic if it works well.

Common Mistakes

Deploying the new version directly to all users without testing.

This risks exposing all users to bugs or downtime if the new version has issues.

Use canary deployment to test with a small group before full rollout.

Not routing traffic properly to the canary version for testing.

Without directing some users to the canary, you cannot verify it works in production.

Use headers or routing rules in your proxy to send a subset of users to the canary.

Running too many replicas of the canary version initially.

This increases risk by exposing too many users to an untested version.

Start with one or very few replicas for the canary.

Summary

Use docker-compose to run stable and canary app versions side by side.

Route a small portion of traffic to the canary version using headers or proxy rules.

Test the canary version before shifting all users to it.

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