Canary deployments in Nginx - Step-by-Step Execution

Process Flow - Canary deployments

Start Deployment

↓

Deploy New Version to Small %

↓

Monitor Metrics & Logs

↓

Increase %

↓

Repeat

This flow shows deploying a new version to a small user portion, monitoring it, then either increasing traffic or rolling back.

Execution Sample

Nginx

upstream backend {
  server stable:80 weight=90;
  server canary:80 weight=10;
}

server {
  listen 80;
  location / {
    proxy_pass http://backend;
  }
}

This NGINX config snippet routes 10% of traffic to the canary backend.

Process Table

Step	Action	Traffic % to Canary	Traffic % to Stable	Result
1	Start deployment	0%	100%	All traffic to stable version
2	Deploy canary with 10% traffic	10%	90%	10% users see new version
3	Monitor metrics	10%	90%	No errors detected
4	Increase canary to 30%	30%	70%	More users see new version
5	Monitor metrics	30%	70%	No errors detected
6	Increase canary to 50%	50%	50%	Half users see new version
7	Monitor metrics	50%	50%	Errors detected
8	Rollback to stable	0%	100%	All traffic back to stable
9	End deployment	0%	100%	Deployment stopped due to errors

💡 Deployment stops after errors detected at 50% canary traffic and rollback occurs

Status Tracker

Variable	Start	After Step 2	After Step 4	After Step 6	After Step 8	Final
canary_traffic_percent	0%	10%	30%	50%	0%	0%
stable_traffic_percent	100%	90%	70%	50%	100%	100%
deployment_status	stable	canary started	canary increased	canary increased	rolled back	stable

Key Moments - 3 Insights

Why does traffic to canary start at a low percentage like 10%?

Starting with low traffic limits risk. As shown in execution_table step 2, only 10% users see the new version to catch issues early.

What happens if errors are detected during canary deployment?

As in step 7 and 8, if errors appear, traffic is rolled back to 0% canary and 100% stable to protect users.

Why do we increase canary traffic gradually?

Gradual increase (steps 4 and 6) helps verify stability before full rollout, reducing impact of bugs.

Visual Quiz - 3 Questions

Look at the execution_table, what is the canary traffic percentage at step 4?

A 50%

B 10%

C 30%

D 0%

💡 Hint

Check the 'Traffic % to Canary' column at step 4 in the execution_table.

At which step does the deployment rollback happen according to the execution_table?

A Step 8

B Step 7

C Step 6

D Step 9

💡 Hint

Look for the row where 'Rollback to stable' is the action.

If no errors were detected at step 7, what would likely happen next?

A Rollback to stable

B Increase canary traffic further

C Stop deployment

D Decrease canary traffic

💡 Hint

Refer to the pattern of increasing traffic after successful monitoring in the execution_table.

Concept Snapshot

Canary deployments gradually route a small % of traffic to a new version.
Monitor for errors before increasing traffic.
Rollback immediately if errors occur.
Use NGINX weighted routing to control traffic split.
This reduces risk of full rollout failures.

Full Transcript

Canary deployments start by sending a small portion of user traffic to a new version of an application. This is done to test the new version in real conditions with limited impact. Using NGINX, we can set weights to control how much traffic goes to the new version versus the stable one. We monitor metrics and logs carefully. If no problems appear, we increase the traffic gradually. If errors are detected, we rollback to the stable version immediately. This process helps keep users safe while deploying new features.

Practice

1. What is the main purpose of a canary deployment in NGINX?

easy

A. To gradually route traffic between old and new application versions

B. To block all traffic during deployment

C. To increase server CPU usage intentionally

D. To disable logging temporarily

Solution

1. Step 1: Understand canary deployment concept

   Canary deployment means sending some traffic to a new version while most traffic still goes to the old version.

2. Step 2: Identify NGINX role in canary deployment

   NGINX controls traffic split using weights in upstream blocks to route requests gradually.

3. Final Answer:

   To gradually route traffic between old and new application versions -> Option A

4. Quick Check:

   Canary deployment = gradual traffic routing [OK]

Hint: Canary means gradual traffic shift, not blocking or disabling [OK]

Common Mistakes:

• Thinking canary blocks all traffic
• Confusing canary with load increase
• Assuming canary disables logging

2. Which NGINX configuration snippet correctly sets a 90% traffic weight to the old version and 10% to the new version?

easy

A. upstream backend { server old.example.com weight=90; server new.example.com weight=10; }

B. upstream backend { server old.example.com weight=10; server new.example.com weight=90; }

C. upstream backend { server old.example.com; server new.example.com; }

D. upstream backend { server old.example.com weight=100; server new.example.com weight=0; }

Solution

1. Step 1: Understand weight meaning in NGINX upstream

   Weight controls traffic share; higher weight means more traffic.

2. Step 2: Match weights to desired traffic split

   Old version should get 90%, new version 10%, so old weight=90, new weight=10.

3. Final Answer:

   upstream backend { server old.example.com weight=90; server new.example.com weight=10; } -> Option A

4. Quick Check:

   Weight 90 old, 10 new = 90% old traffic [OK]

Hint: Higher weight means more traffic; assign accordingly [OK]

Common Mistakes:

• Swapping weights between old and new servers
• Omitting weights defaults to equal traffic
• Setting weight=0 disables server completely

3. Given this NGINX upstream configuration:

upstream backend {
  server old.example.com weight=80;
  server new.example.com weight=20;
}

What percentage of traffic will be routed to new.example.com?

medium

A. 80%

B. 20%

C. 50%

D. 100%

Solution

1. Step 1: Calculate total weight

   Total weight = 80 (old) + 20 (new) = 100.

2. Step 2: Calculate new server traffic percentage

   New server traffic = (20 / 100) * 100% = 20%.

3. Final Answer:

   20% -> Option B

4. Quick Check:

   New server weight 20 of 100 total = 20% traffic [OK]

Hint: Traffic % = server weight / total weight * 100 [OK]

Common Mistakes:

• Confusing weight with percentage directly
• Adding weights incorrectly
• Assuming equal traffic without weights

4. You wrote this NGINX upstream block for canary deployment:

upstream backend {
  server old.example.com weight=70
  server new.example.com weight=30;
}

But NGINX fails to start. What is the error?

medium

A. Cannot use weight in upstream block

B. Weight values must be equal

C. Missing semicolon after first server directive

D. Server names must be IP addresses

Solution

1. Step 1: Check syntax of upstream block

   Each server directive must end with a semicolon in NGINX config.

2. Step 2: Identify missing semicolon

   First server line lacks semicolon after weight=70, causing syntax error.

3. Final Answer:

   Missing semicolon after first server directive -> Option C

4. Quick Check:

   Semicolons required after each directive [OK]

Hint: Check semicolons after each server line [OK]

Common Mistakes:

• Ignoring missing semicolon errors
• Thinking weights must be equal
• Assuming server names must be IPs

5. You want to deploy a new version with 5% traffic initially, then increase to 50% after testing. Which NGINX configuration approach supports this canary deployment best?

hard

A. Use limit_conn to limit new server connections

B. Use proxy_pass without weights to split traffic

C. Set weight=0 for new server until ready

D. Manually update weight values in upstream block and reload NGINX

Solution

1. Step 1: Understand canary traffic control in NGINX

   NGINX uses weights in upstream blocks to control traffic percentage per server.

2. Step 2: Adjust weights gradually and reload NGINX

   Manually changing weights from 5 to 50 and reloading NGINX safely shifts traffic as needed.

3. Final Answer:

   Manually update weight values in upstream block and reload NGINX -> Option D

4. Quick Check:

   Weight changes + reload = traffic control [OK]

Hint: Change weights and reload to shift traffic gradually [OK]

Common Mistakes:

• Using proxy_pass without weights for traffic split
• Setting weight=0 disables server, not gradual traffic
• Using limit_conn limits connections, not traffic percentage