Upstream blocks in Nginx - Mini Project: Build & Apply

Configuring an Nginx Upstream Block

📖 Scenario: You are setting up a simple load balancer using Nginx to distribute web traffic to multiple backend servers. This helps your website handle more visitors smoothly.

🎯 Goal: Build an Nginx configuration that defines an upstream block with two backend servers and uses it in a server block to proxy requests.

📋 What You'll Learn

Create an upstream block named backend with two servers: 192.168.1.10:8080 and 192.168.1.11:8080

Add a server block listening on port 80

Configure the location / to proxy requests to the backend upstream

Use the directive proxy_pass http://backend; inside the location block

💡 Why This Matters

🌍 Real World

Nginx upstream blocks are used to balance load between multiple backend servers, improving website reliability and speed.

💼 Career

Understanding upstream blocks is essential for DevOps roles managing web server configurations and scaling web applications.

1

Create the upstream block

Create an upstream block named backend with two servers: 192.168.1.10:8080 and 192.168.1.11:8080.

Nginx

# Your code here

Hint

Use the upstream directive followed by the name backend. Inside the block, add two server lines with the exact IP addresses and ports.

2

Add a server block listening on port 80

Add a server block that listens on port 80.

Nginx

upstream backend {
    server 192.168.1.10:8080;
    server 192.168.1.11:8080;
}

# Your code here

Hint

Use the server directive and inside it add listen 80; to accept HTTP traffic on port 80.

3

Configure location block to proxy requests

Inside the server block, add a location / block that uses proxy_pass http://backend; to forward requests to the upstream.

Nginx

upstream backend {
    server 192.168.1.10:8080;
    server 192.168.1.11:8080;
}

server {
    listen 80;
    # Your code here
}

Hint

Inside the server block, add location / {} and inside it add proxy_pass http://backend;.

4

Display the complete Nginx configuration

Print the complete Nginx configuration including the upstream and server blocks.

Nginx

upstream backend {
    server 192.168.1.10:8080;
    server 192.168.1.11:8080;
}

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

# Your code here

Hint

Show the full configuration text exactly as built in previous steps.

Practice

1. What is the main purpose of an upstream block in an nginx configuration?

easy

A. To set caching rules for static files

B. To group backend servers for load balancing

C. To define client request headers

D. To configure SSL certificates

Solution

1. Step 1: Understand the role of upstream blocks

   Upstream blocks in nginx are used to group backend servers together.

2. Step 2: Identify the purpose of grouping

   This grouping allows nginx to distribute incoming traffic among these servers, which is called load balancing.

3. Final Answer:

   To group backend servers for load balancing -> Option B

4. Quick Check:

   Upstream blocks = backend server groups [OK]

Hint: Upstream blocks group servers for load balancing [OK]

Common Mistakes:

• Confusing upstream with SSL or caching settings
• Thinking upstream defines client headers
• Assuming upstream is for static file rules

2. Which of the following is the correct syntax to define an upstream block named backend with two servers server1.example.com and server2.example.com?

easy

A. upstream backend { server server1.example.com; server server2.example.com; }

B. upstream backend { server1.example.com; server2.example.com; }

C. upstream backend { backend server1.example.com; backend server2.example.com; }

D. upstream backend { server: server1.example.com; server: server2.example.com; }

Solution

1. Step 1: Recall the upstream block syntax

   The correct syntax requires the keyword server before each backend server address inside curly braces.

2. Step 2: Match the syntax with options

   upstream backend { server server1.example.com; server server2.example.com; } correctly uses server server1.example.com; and server server2.example.com; inside the upstream block.

3. Final Answer:

   upstream backend { server server1.example.com; server server2.example.com; } -> Option A

4. Quick Check:

   Each backend needs 'server' keyword [OK]

Hint: Each server line starts with 'server' keyword [OK]

Common Mistakes:

• Omitting 'server' keyword before addresses
• Using colons instead of spaces
• Adding extra keywords like 'backend' inside block

3. Given this nginx upstream block:

upstream backend {
    server 192.168.1.10 weight=3;
    server 192.168.1.11;
}

What does the weight=3 mean for 192.168.1.10?

medium

A. It receives three times more requests than 192.168.1.11

B. It is a backup server and only used if 192.168.1.11 fails

C. It limits connections to 3 simultaneous clients

D. It will be ignored because weight is invalid here

Solution

1. Step 1: Understand weight in upstream servers

   The weight parameter assigns relative load share to a server. A higher weight means more requests.

2. Step 2: Interpret the weight=3 for 192.168.1.10

   Since 192.168.1.10 has weight=3 and 192.168.1.11 has default weight=1, the first server gets 3 times more requests.

3. Final Answer:

   It receives three times more requests than 192.168.1.11 -> Option A

4. Quick Check:

   Weight controls request distribution [OK]

Hint: Weight multiplies request share for that server [OK]

Common Mistakes:

• Confusing weight with backup role
• Thinking weight limits connections
• Assuming weight is ignored if not 1

4. Identify the error in this upstream block configuration:

upstream backend {
    server 10.0.0.1;
    server 10.0.0.2 backup;
    server 10.0.0.3 weight=two;
}

medium

A. Upstream block cannot have more than two servers

B. Backup server must be listed first

C. Missing semicolon after server 10.0.0.1

D. The weight value 'two' is invalid; it must be a number

Solution

1. Step 1: Check syntax of weight parameter

   The weight parameter must be a numeric value. 'two' is a string and invalid.

2. Step 2: Verify other parts of the block

   Semicolons are present, backup server can be anywhere, and multiple servers are allowed.

3. Final Answer:

   The weight value 'two' is invalid; it must be a number -> Option D

4. Quick Check:

   Weight must be numeric [OK]

Hint: Weight values must be numbers, not words [OK]

Common Mistakes:

• Placing backup server only first
• Forgetting semicolons
• Limiting number of servers incorrectly

5. You want to configure an upstream block named app_servers with three servers: 10.1.1.1 (weight 5), 10.1.1.2 (weight 1), and 10.1.1.3 as a backup. Which configuration is correct?

hard

A. upstream app_servers { server 10.1.1.1 weight=5; server 10.1.1.2; server 10.1.1.3 backup=1; }

B. upstream app_servers { server 10.1.1.1 weight=5; server 10.1.1.2 weight=1 backup; server 10.1.1.3; }

C. upstream app_servers { server 10.1.1.1 weight=5; server 10.1.1.2 weight=1; server 10.1.1.3 backup; }

D. upstream app_servers { server 10.1.1.1; server 10.1.1.2 weight=1; server 10.1.1.3 backup weight=5; }

Solution

1. Step 1: Assign weights correctly

   Servers 10.1.1.1 and 10.1.1.2 must have weights 5 and 1 respectively, using weight=.

2. Step 2: Mark backup server properly

   Server 10.1.1.3 should be marked with the backup keyword without weight.

3. Step 3: Validate options

   upstream app_servers { server 10.1.1.1 weight=5; server 10.1.1.2 weight=1; server 10.1.1.3 backup; } correctly assigns weights and backup keyword. Others misuse backup or weight syntax.

4. Final Answer:

   upstream app_servers { server 10.1.1.1 weight=5; server 10.1.1.2 weight=1; server 10.1.1.3 backup; } -> Option C

5. Quick Check:

   Weight and backup keywords used correctly [OK]

Hint: Use 'weight=' for load, 'backup' alone for backup server [OK]

Common Mistakes:

• Using 'backup=1' instead of 'backup'
• Combining weight and backup on same server
• Omitting weight for weighted servers