Copies behind one address

This step shows how nginx splits requests between copies and where you can see which copy answered.

nginx gathers the copies of an application into a group — an upstream block. Instead of one copy's address, proxy_pass holds the group name:

nginx

upstream app {
    server 127.0.0.1:8081;
    server 127.0.0.1:8082;
}
server {
    listen 80 default_server;
    location / {
        proxy_pass http://app;
    }
}

Each server line is one copy, a backend. nginx hands out requests in a circle: the first goes to 8081, the second to 8082, the third to 8081 again. That is why one sick copy out of two spoils every other answer.

nginx knows which copy answered: the copy's address is in the $upstream_addr variable, its status code in $upstream_status. On this server they are written to the /var/log/nginx/lb-access.log log (the upstream= and ustatus= fields) and to the X-Upstream response header.

bash

tail -n 4 /var/log/nginx/lb-access.log

Check yourself 1 question

The upstream has three copies — 8081, 8082 and 8083 — and 8083 is sick: it answers 500. Which of six requests in a row will get 500?

The circle now has three copies: every third request lands on the sick one.
The first request goes to the first server line, 8081. 8083 is third, so it gets the third and the sixth.
The second request goes to the healthy 8082. Going round, 8083 gets the third and the sixth.

nginx hands out requests in a circle, in the order of the server lines: 8081, 8082, 8083, then 8081 again. The third copy gets the third and the sixth requests. To check, look at the upstream= field in tail -n 6 /var/log/nginx/lb-access.log.

Key points

An upstream block gathers application copies under one name, and proxy_pass sends requests to that name.
Copies get requests in a circle: one sick copy out of two spoils every other answer.
$upstream_addr and $upstream_status tell who answered: the load balancer's log shows which copy is sick.

A load balancer and health checks

Signing in is needed to start the machine