Canary deployments in Nginx - Cheat Sheet & Quick Revision

Recall & Review

beginner

What is a canary deployment?

A canary deployment is a way to release new software to a small group of users first. It helps check if the new version works well before giving it to everyone.

beginner

How does NGINX help with canary deployments?

NGINX can send some user requests to the new version of the app and the rest to the old version. This way, it controls who sees the new release.

beginner

What is the main benefit of using canary deployments?

It reduces risk by testing new changes on a small group first. If problems happen, only a few users are affected, and fixes can be made quickly.

intermediate

In NGINX, which directive can be used to split traffic for canary deployments?

The 'split_clients' directive can divide users into groups to send some to the new version and others to the old one.

intermediate

What is a common way to decide which users get the new version in a canary deployment?

Users can be split by a percentage, like 5% get the new version and 95% get the old one. This is often done using cookies or IP hashing.

What is the main goal of a canary deployment?

A Ignore user feedback

B Test new software on a small user group first

C Remove old software immediately

D Deploy software to all users at once

Canary deployments test new software on a small group before full release.

Which NGINX directive helps split traffic for canary deployments?

A listen

B proxy_pass

C split_clients

D server_name

The 'split_clients' directive divides traffic between versions.

In canary deployments, what percentage of users usually get the new version first?

A 100%

B 0%

C 50%

D A small percentage like 5%

A small percentage like 5% is typical to limit risk.

Why is canary deployment safer than deploying to all users at once?

A It tests changes on a small group to catch problems early

B It ignores errors

C It forces all users to update immediately

D It removes old versions instantly

Testing on a small group helps find issues before full rollout.

Which method can NGINX use to decide which users see the new version?

A Random selection with split_clients

B Always send all users to new version

C Send users based on browser type

D Send users based on screen size

NGINX uses split_clients to randomly assign users to versions.

Explain how NGINX can be configured to perform a canary deployment.

Think about how to split users and send requests to different servers.

Describe the benefits of using canary deployments in software release.

Consider what happens if new software has problems.

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