Canary deployment pattern in Docker - Mini Project: Build & Apply

Canary Deployment Pattern with Docker

📖 Scenario: You work in a team that manages a web application using Docker containers. Your team wants to deploy a new version of the app safely by using the canary deployment pattern. This means you will run the new version alongside the old one, but only send a small portion of traffic to the new version first. This helps catch problems early without affecting all users.

🎯 Goal: Build a simple Docker Compose setup that runs two versions of a web app: the stable version and the canary version. Configure the setup so that 90% of traffic goes to the stable version and 10% goes to the canary version. This simulates a canary deployment.

📋 What You'll Learn

Create a Docker Compose file with two services: web_stable and web_canary

Use the official nginx image for both services

Configure web_stable to listen on port 8080

Configure web_canary to listen on port 8081

Add a simple nginx configuration file for each service that returns a different message

Create a load_balancer service using nginx that routes 90% of traffic to web_stable and 10% to web_canary

Expose the load balancer on port 80

💡 Why This Matters

🌍 Real World

Canary deployments help teams release new software versions safely by exposing only a small portion of users to changes first. This reduces risk and improves reliability.

💼 Career

Understanding canary deployments and Docker Compose is essential for DevOps roles that manage application releases and infrastructure automation.

1

Create Docker Compose services for stable and canary

Create a docker-compose.yml file with two services: web_stable and web_canary. Use the nginx image for both. Map port 8080 on the host to 80 in web_stable and port 8081 on the host to 80 in web_canary.

Docker

# Your code here

Hint

Use ports to map host ports to container ports for each service.

2

Add custom nginx configuration files for stable and canary

Create two nginx configuration files named stable.conf and canary.conf. In stable.conf, configure nginx to return a simple HTML page with the text Stable Version. In canary.conf, configure nginx to return a simple HTML page with the text Canary Version. Then, update the docker-compose.yml to mount these config files into /etc/nginx/conf.d/default.conf for web_stable and web_canary respectively.

Docker

version: '3.8'
services:
  web_stable:
    image: nginx
    ports:
      - "8080:80"
    # Mount stable.conf here
  web_canary:
    image: nginx
    ports:
      - "8081:80"
    # Mount canary.conf here

# Your code here

Hint

Use volumes to mount config files as read-only inside the containers.

3

Add load balancer service with traffic split

Add a new service called load_balancer in docker-compose.yml using the nginx image. Mount a custom nginx config file load_balancer.conf into /etc/nginx/nginx.conf. Expose port 80 on the host. The load balancer will route 90% of traffic to web_stable and 10% to web_canary using nginx upstream and split configuration.

Docker

version: '3.8'
services:
  web_stable:
    image: nginx
    ports:
      - "8080:80"
    volumes:
      - ./stable.conf:/etc/nginx/conf.d/default.conf:ro
  web_canary:
    image: nginx
    ports:
      - "8081:80"
    volumes:
      - ./canary.conf:/etc/nginx/conf.d/default.conf:ro
  # Add load_balancer service below

# Your code here

Hint

Use depends_on to ensure the load balancer starts after the web services.

4

Run Docker Compose and verify canary deployment

Run docker-compose up -d to start all services. Then, run curl -s http://localhost multiple times. You should see Stable Version about 90% of the time and Canary Version about 10% of the time, showing the canary deployment is working.

Docker

# Run docker-compose up -d
# Run curl -s http://localhost multiple times
# Your code here

Hint

Run docker-compose up -d to start containers. Use curl to test the load balancer. You should see mostly "Stable Version" and some "Canary Version" responses.

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