Canary deployments in Nginx - Interactive Code Practice

Practice - 5 Tasks

1fill in blank

easy

Complete the code to define the upstream servers for canary deployment.

Nginx

upstream backend {
    server backend-v1.example.com;
    server [1];
}

Drag options to blanks, or click blank then click option'

Abackend-v2.example.com

Bbackend-test.example.com

Cbackend-old.example.com

Dbackend-v3.example.com

Attempts:

3 left

💡 Hint

Common Mistakes

Choosing the old or unrelated server name instead of the new version.

The canary deployment uses a new version server, here backend-v2.example.com, alongside the stable version.

2fill in blank

medium

Complete the code to split traffic with 90% to stable and 10% to canary.

Nginx

server {
    location / {
        proxy_pass http://backend;
        [1];
    }
}

Drag options to blanks, or click blank then click option'

Aproxy_set_header X-Weight 90 10

Bsplit_clients $request_id $upstream_server { 90% backend-v1; 10% backend-v2; }

Csplit_clients $request_id $upstream_server { 90% backend-v1.example.com; 10% backend-v2.example.com; }

Dproxy_set_header X-Canary 10%

Attempts:

3 left

💡 Hint

Common Mistakes

Using incorrect directive names or wrong server names.

The split_clients directive is used to split traffic by percentage. The correct syntax uses server names without domain extensions.

3fill in blank

hard

Fix the error in the canary header condition to route 10% traffic to canary.

Nginx

map $http_x_canary $upstream_canary {
    default backend-v1;
    [1] backend-v2;
}

Drag options to blanks, or click blank then click option'

A"10%"

B"canary"

C"1"

D"yes"

Attempts:

3 left

💡 Hint

Common Mistakes

Using percentage strings or numeric values that don't match the header.

The map directive matches the header value. Using "yes" is a common practice to indicate canary traffic.

4fill in blank

hard

Fill both blanks to complete the canary routing using the map variable.

Nginx

server {
    location / {
        proxy_pass http://[1];
        proxy_set_header X-Canary [2];
    }
}

Drag options to blanks, or click blank then click option'

Aupstream_canary

B$http_x_canary

C"yes"

D"no"

Attempts:

3 left

💡 Hint

Common Mistakes

Using the raw header variable in proxy_pass or wrong header values.

The proxy_pass uses the mapped upstream variable upstream_canary. The header is set to "yes" to indicate canary traffic.

5fill in blank

hard

Fill all three blanks to define a canary deployment with weighted upstream and header control.

Nginx

upstream backend {
    server backend-v1.example.com weight=[1];
    server backend-v2.example.com weight=[2];
}

server {
    location / {
        proxy_pass http://backend;
        proxy_set_header X-Canary [3];
    }
}

Drag options to blanks, or click blank then click option'

A90

B10

C"yes"

D"no"

Attempts:

3 left

💡 Hint

Common Mistakes

Using incorrect weights or header values that don't match routing logic.

The weights define 90% traffic to stable and 10% to canary. The header X-Canary is set to "yes" to mark canary requests.

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