Blue-green deployment routing in Nginx - Interactive Code Practice

Practice - 5 Tasks

1fill in blank

easy

Complete the code to define the server block for the blue environment.

Nginx

server {
    listen 80;
    server_name example.com;

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

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

Agreen_backend

Blocalhost:8080

Cblue_backend

D127.0.0.1:3000

Attempts:

3 left

💡 Hint

Common Mistakes

Using the green backend name instead of blue.

Using an IP address instead of the backend name.

The blue environment backend is named blue_backend in the proxy_pass directive.

2fill in blank

medium

Complete the code to define the upstream block for the green environment.

Nginx

upstream [1] {
    server 10.0.0.2:8080;
    server 10.0.0.3:8080;
}

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

Abackend_green

Bgreen_backend

Cblue_backend

Dgreen_servers

Attempts:

3 left

💡 Hint

Common Mistakes

Using the blue backend name.

Using a name not matching the proxy_pass directive.

The upstream block for the green environment is named green_backend.

3fill in blank

hard

Fix the error in the load balancer configuration to route traffic to the active environment.

Nginx

server {
    listen 80;
    server_name example.com;

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

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

Ainactive_backend

Bblue_backend

Cgreen_backend

Dactive_backend

Attempts:

3 left

💡 Hint

Common Mistakes

Hardcoding blue or green backend names instead of using an active alias.

Using a backend name that does not exist.

The load balancer should route traffic to the active_backend, which points to the currently active environment.

4fill in blank

hard

Fill both blanks to configure health checks for blue and green upstreams.

Nginx

upstream blue_backend {
    server 10.0.0.1:8080 [1];
}

upstream green_backend {
    server 10.0.0.2:8080 [2];
}

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

Amax_fails=3

Bmax_fails=5

Cfail_timeout=10s

Dfail_timeout=30s

Attempts:

3 left

💡 Hint

Common Mistakes

Using the same health check settings for both backends.

Mixing max_fails and fail_timeout values incorrectly.

The blue backend uses max_fails=3 and the green backend uses fail_timeout=10s for health checks.

5fill in blank

hard

Fill all three blanks to complete the blue-green deployment routing with sticky sessions.

Nginx

upstream active_backend {
    ip_hash;
    server 10.0.0.1:8080 [1];
    server 10.0.0.2:8080 [2];
}

server {
    listen 80;
    location / {
        proxy_pass http://[3];
    }
}

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

Amax_fails=3

Bfail_timeout=15s

Cactive_backend

Dmax_fails=5

Attempts:

3 left

💡 Hint

Common Mistakes

Not using the correct backend name in proxy_pass.

Mixing up health check parameters.

The upstream servers have health checks with max_fails=3 and fail_timeout=15s. The proxy_pass uses active_backend to route traffic.

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