Blue-green deployment routing in Nginx - Commands & Configuration

Introduction

Blue-green deployment routing helps you switch traffic between two versions of your app smoothly. It avoids downtime by running both versions and directing users to one at a time.

When you want to update your website without making it unavailable to users.

When you want to test a new app version with real users before fully switching.

When you want to quickly roll back to the old version if the new one has problems.

When you want to reduce risks during app updates by having two live environments.

When you want to control traffic routing at the web server level for deployments.

Config File - nginx.conf

nginx.conf

worker_processes 1;
events { worker_connections 1024; }
http {
    upstream blue_backend {
        server 127.0.0.1:8081;
    }
    upstream green_backend {
        server 127.0.0.1:8082;
    }

    server {
        listen 80;

        # Change this to switch traffic between blue and green
        set $active_backend blue_backend;

        location / {
            proxy_pass http://$active_backend;
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header X-Forwarded-Proto $scheme;
        }
    }
}

This config defines two backend groups: blue_backend and green_backend, each pointing to a different app version on ports 8081 and 8082.

The set $active_backend blue_backend; line controls which backend receives traffic. Change it to green_backend to switch.

The proxy_pass directive sends incoming requests to the active backend.

Commands

Check if the nginx configuration file syntax is correct before applying changes.

Terminal

sudo nginx -t

Expected Output

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok

nginx: configuration file /etc/nginx/nginx.conf test is successful

Reload nginx to apply the new configuration without stopping the server, so traffic routing changes take effect immediately.

Terminal

sudo systemctl reload nginx

Expected Output

No output (command runs silently)

Send a request to nginx to verify it routes traffic to the active backend (blue or green).

Terminal

curl -I http://localhost

Expected Output

HTTP/1.1 200 OK

Server: nginx

Date: Thu, 01 Jan 1970 00:00:00 GMT

Content-Type: text/html

Content-Length: 1234

Connection: keep-alive

→

-I - Fetch only HTTP headers to quickly check server response

Switch the active backend from blue to green by editing the nginx config file directly.

Terminal

sed -i 's/set \$active_backend blue_backend;/set \$active_backend green_backend;/' /etc/nginx/nginx.conf

Expected Output

No output (command runs silently)

Reload nginx again to apply the backend switch so traffic now goes to the green version.

Terminal

sudo systemctl reload nginx

Expected Output

No output (command runs silently)

Key Concept

If you remember nothing else from this pattern, remember: blue-green deployment routing switches user traffic between two live app versions by changing the backend target in the web server.

Common Mistakes

Forgetting to reload nginx after changing the config file.

Nginx keeps using the old config until reloaded, so traffic won't switch as expected.

Always run 'sudo systemctl reload nginx' after editing the config to apply changes.

Setting both blue and green backends to the same port or server.

Traffic won't actually switch because both backends point to the same app version.

Ensure blue and green backends point to different app instances on separate ports or servers.

Not testing nginx config syntax before reload.

A syntax error can cause nginx to fail reloading, leading to downtime.

Always run 'sudo nginx -t' to verify config syntax before reloading.

Summary

Define two backend groups in nginx config for blue and green app versions.

Use a variable to control which backend receives traffic and change it to switch versions.

Test nginx config syntax and reload nginx to apply routing changes without downtime.

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