Blue-green deployment routing in Nginx - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

Understanding Blue-Green Deployment Routing

In a blue-green deployment, two identical environments (blue and green) run different versions of an application. What is the main purpose of routing traffic between these environments?

A To run both versions simultaneously and merge their databases

B To gradually shift user traffic from the old version to the new version without downtime

C To deploy the new version only after the old version is completely shut down

D To randomly distribute traffic between unrelated applications

💡 Hint

Think about how users experience updates without interruptions.

Blue-green deployment routing allows switching user traffic smoothly from the old (blue) environment to the new (green) environment, minimizing downtime and risk.

💻 Command Output

intermediate

Nginx Configuration Output for Blue-Green Routing

Given this simplified Nginx snippet for blue-green deployment routing, what will be the upstream server handling requests when the set $upstream variable is set to green?

Nginx

upstream blue {
    server 10.0.0.1:8080;
}

upstream green {
    server 10.0.0.2:8080;
}

server {
    listen 80;
    location / {
        set $upstream green;
        proxy_pass http://$upstream;
    }
}

A Requests are forwarded to 10.0.0.2:8080

B Nginx will throw a syntax error due to variable usage in proxy_pass

C Requests are forwarded to 10.0.0.1:8080

D Requests are load balanced between 10.0.0.1:8080 and 10.0.0.2:8080

💡 Hint

Check which upstream block matches the variable $upstream.

The variable $upstream is set to green, so proxy_pass sends requests to the green upstream, which is 10.0.0.2:8080.

❓ Configuration

advanced

Identify the Error in Blue-Green Nginx Routing Configuration

Review this Nginx configuration snippet intended for blue-green deployment routing. Which option correctly identifies the error that will prevent proper routing?

Nginx

upstream blue {
    server 10.0.0.1:8080;
}

upstream green {
    server 10.0.0.2:8080;
}

server {
    listen 80;
    location / {
        set $upstream blue;
        proxy_pass http://$upstream/;
    }
}

A The 'set' directive cannot be used inside location blocks

B The upstream blocks must be named with IP addresses, not 'blue' or 'green'

C The trailing slash in proxy_pass causes Nginx to ignore the variable and route incorrectly

D Nginx requires proxy_pass to use a fixed URL, variables are not allowed

💡 Hint

Consider how Nginx handles proxy_pass with variables and trailing slashes.

When proxy_pass uses a variable with a trailing slash, Nginx ignores the variable and uses the literal string, causing routing errors. The trailing slash should be removed.

🔀 Workflow

advanced

Blue-Green Deployment Switch Workflow Using Nginx

Which sequence of steps correctly describes switching traffic from the blue environment to the green environment using Nginx configuration?

A 3,1,2,4

B 1,3,2,4

C 3,2,1,4

D 2,1,3,4

💡 Hint

Think about the logical order: readiness, config change, reload, then monitor.

First verify the green environment is ready, then update the config, reload Nginx to apply, and finally monitor traffic for issues.

❓ Troubleshoot

expert

Diagnosing Nginx Routing Failure in Blue-Green Deployment

After switching Nginx upstream from blue to green, users report 502 Bad Gateway errors. Which is the most likely cause?

A The proxy_pass directive is missing the http:// prefix

B Nginx configuration syntax error prevents reload

C The blue upstream block is missing from the config

D The green backend server at 10.0.0.2:8080 is down or unreachable

💡 Hint

502 Bad Gateway usually means Nginx cannot connect to the backend server.

502 errors indicate Nginx cannot reach the backend. Since traffic was switched to green, the green server is likely down or unreachable.

Practice

1. What is the main purpose of using blue-green deployment routing with Nginx?

easy

A. To encrypt traffic between client and server

B. To increase the number of servers in the cluster

C. To cache static files for faster loading

D. To switch traffic between two app versions without downtime

Solution

1. Step 1: Understand blue-green deployment concept

   Blue-green deployment uses two versions of an app (blue and green) to switch traffic smoothly.

2. Step 2: Identify Nginx role in routing

   Nginx switches traffic by changing proxy_pass between blue and green upstreams, avoiding downtime.

3. Final Answer:

   To switch traffic between two app versions without downtime -> Option D

4. Quick Check:

   Blue-green routing = traffic switch without downtime [OK]

Hint: Blue-green means two versions, switch traffic smoothly [OK]

Common Mistakes:

• Confusing blue-green with load balancing
• Thinking it increases server count automatically
• Assuming it handles encryption or caching

2. Which Nginx directive is used to switch traffic between blue and green app versions in blue-green deployment?

easy

A. proxy_pass

B. listen

C. server_name

D. root

Solution

1. Step 1: Identify directive for routing requests

   The proxy_pass directive tells Nginx where to send incoming requests.

2. Step 2: Understand blue-green switching

   Switching proxy_pass between blue and green upstream blocks changes the app version served.

3. Final Answer:

   proxy_pass -> Option A

4. Quick Check:

   proxy_pass switches traffic in blue-green [OK]

Hint: proxy_pass directs traffic to app versions [OK]

Common Mistakes:

• Using listen to switch app versions
• Confusing server_name with routing
• Using root which sets document root, not proxy

3. Given this Nginx config snippet, what backend will receive traffic?

upstream blue {
  server 10.0.0.1:8080;
}
upstream green {
  server 10.0.0.2:8080;
}
server {
  listen 80;
  location / {
    proxy_pass http://green;
  }
}

medium

A. 10.0.0.1:8080 (blue)

B. 10.0.0.2:8080 (green)

C. Both blue and green servers

D. No backend, config error

Solution

1. Step 1: Check proxy_pass target

   The proxy_pass points to http://green, so traffic goes to green upstream.

2. Step 2: Identify green upstream server

   Green upstream has server 10.0.0.2:8080, so this server receives traffic.

3. Final Answer:

   10.0.0.2:8080 (green) -> Option B

4. Quick Check:

   proxy_pass to green = 10.0.0.2:8080 [OK]

Hint: proxy_pass target = backend server [OK]

Common Mistakes:

• Assuming traffic goes to blue by default
• Thinking both upstreams get traffic simultaneously
• Believing config has syntax errors

4. Identify the error in this Nginx blue-green deployment config snippet:

upstream blue {
  server 10.0.0.1:8080;
}
upstream green {
  server 10.0.0.2:8080
}
server {
  listen 80;
  location / {
    proxy_pass http://blue;
  }
}

medium

A. Missing semicolon after green server line

B. proxy_pass should use https instead of http

C. listen directive must specify IP address

D. upstream block names must be uppercase

Solution

1. Step 1: Check upstream block syntax

   The green upstream server line lacks a semicolon at the end, causing syntax error.

2. Step 2: Validate other directives

   proxy_pass with http is valid; listen can omit IP; upstream names can be lowercase.

3. Final Answer:

   Missing semicolon after green server line -> Option A

4. Quick Check:

   Missing semicolon causes config error [OK]

Hint: Check semicolons after each directive line [OK]

Common Mistakes:

• Assuming http must be https in proxy_pass
• Thinking listen needs IP address
• Believing upstream names must be uppercase

5. You want to switch live traffic from blue to green app version with zero downtime using Nginx. Which is the best approach?

hard

A. Stop blue servers and start green servers without changing Nginx

B. Change DNS to point to green servers and wait for propagation

C. Change proxy_pass in Nginx config from blue to green and reload Nginx

D. Restart Nginx without changing config to refresh connections

Solution

1. Step 1: Understand zero downtime switch

   Changing proxy_pass in Nginx config directs traffic to green without downtime.

2. Step 2: Reload Nginx to apply changes

   Reloading Nginx applies new config smoothly without dropping connections.

3. Final Answer:

   Change proxy_pass in Nginx config from blue to green and reload Nginx -> Option C

4. Quick Check:

   proxy_pass switch + reload = zero downtime [OK]

Hint: Switch proxy_pass and reload Nginx for smooth update [OK]

Common Mistakes:

• Stopping blue servers causes downtime
• Relying on DNS changes delays switch
• Restarting Nginx without config change does nothing