Blue-green deployment routing in Nginx - Step-by-Step Execution

Process Flow - Blue-green deployment routing

Start with Blue environment live

↓

Deploy new version to Green environment

↓

Switch router from Blue to Green

↓

Green environment serves all traffic

↓

Keep Blue as backup or update it

↓

Repeat cycle for next deployment

Traffic is routed to one environment (Blue or Green) at a time. New version deploys to inactive environment, then router switches traffic to it.

Execution Sample

Nginx

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

# Switch proxy_pass to http://green_backend to route traffic

Nginx routes incoming requests to the active backend (blue or green). Switching proxy_pass changes live environment.

Process Table

Step	Current Active Backend	Action	Routing Change	Result
1	blue_backend	Initial state	proxy_pass http://blue_backend;	All traffic goes to Blue
2	blue_backend	Deploy new version to Green	No routing change	Green environment ready but inactive
3	green_backend	Switch proxy_pass to Green	proxy_pass http://green_backend;	All traffic now goes to Green
4	green_backend	Blue kept as backup	No routing change	Blue environment idle, ready for rollback
5	green_backend	Next deployment prepares Blue	No routing change	Blue updated, inactive
6	blue_backend	Switch proxy_pass back to Blue	proxy_pass http://blue_backend;	Traffic switches back to Blue

💡 Traffic routing switches only after new environment is ready, ensuring zero downtime.

Status Tracker

Variable	Start	After Step 2	After Step 3	After Step 4	After Step 6
active_backend	blue_backend	blue_backend	green_backend	green_backend	blue_backend
blue_status	live	live	backup	backup	live
green_status	idle	ready	live	live	idle

Key Moments - 3 Insights

Why does traffic not switch immediately when deploying the new version?

Traffic switches only after the new environment (Green) is fully ready, as shown in step 2 and 3 of the execution_table, to avoid downtime.

What happens to the old environment after switching traffic?

The old environment (Blue) becomes backup or idle, ready for rollback or next update, as shown in step 4 of the execution_table.

How does nginx know which environment to send traffic to?

Nginx uses the proxy_pass directive to route traffic to either blue_backend or green_backend, changed manually or by automation as shown in the code sample.

Visual Quiz - 3 Questions

Look at the execution_table at step 3, what is the active backend after switching?

A green_backend

B blue_backend

C both blue and green

D none

💡 Hint

Check the 'Current Active Backend' column at step 3 in the execution_table.

At which step does the green environment become ready but not yet active?

A Step 1

B Step 2

C Step 3

D Step 4

💡 Hint

Look for when the green environment status changes to 'ready' in variable_tracker and execution_table.

If proxy_pass is not switched after deployment, what happens to traffic?

A Traffic stops

B Traffic is split evenly

C Traffic continues to go to old environment

D Traffic goes to both environments

💡 Hint

Refer to execution_table step 2 where deployment happens but routing does not change.

Concept Snapshot

Blue-green deployment uses two environments: Blue (live) and Green (new).
Deploy new version to inactive environment.
Switch router (nginx proxy_pass) to new environment after ready.
Old environment kept as backup for rollback.
Ensures zero downtime and safe updates.

Full Transcript

Blue-green deployment routing means having two environments: one live (Blue) and one idle (Green). You deploy the new version to the idle environment first. Once it is ready, you switch the router, like nginx's proxy_pass, to send all traffic to the new environment. The old environment stays as backup. This way, users experience no downtime during updates. The execution table shows each step: starting with Blue live, deploying Green, switching traffic, and keeping Blue as backup. Variables track which backend is active and their statuses. Key moments clarify why traffic switches only after readiness and how nginx routes traffic. The quiz tests understanding of active backend and routing changes. The snapshot summarizes the process simply and clearly.

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