Словарь: термины для тех, кто пришёл из Django или WordPress

Слова знакомы - листай до «Теперь сам» и проверь себя на чужом конфиге.

Половина трудностей с nginx - не в конфиге, а в словах. Человек пять лет делает сайты на WordPress или пишет на Django, всё работает, а в статьях про nginx с первой строки: «апстрим», «реверс-прокси», «терминация TLS», «воркер». Разберём эти слова один раз - дальше в курсе они будут встречаться как родные.

Что делает nginx, если объяснять на пальцах

Веб-сервер - программа, которая слушает порт и отвечает на HTTP-запросы. nginx умеет отвечать сам (отдать файл с диска) и умеет передавать запрос кому-то ещё.

Обратный прокси (reverse proxy) - это второе умение. «Прокси» - потому что посредник, «обратный» - потому что стоит не рядом с клиентом, а перед серверами. Клиент думает, что разговаривает с сайтом; на самом деле он разговаривает с nginx, а тот уже ходит к приложению.

Бэкенд (он же upstreamupstreamИменованный список адресов приложения. nginx выбирает из него сервер по заданному правилу и умеет исключать неотвечающие. Имя группы по умолчанию уходит бэкенду в заголовке Host., «апстрим») - то, к чему nginx ходит за ответом. Для Django это gunicorn или uvicorn на порту 8000, для WordPress - php-fpm, для Node - сам процесс приложения. В конфиге бэкенд появляется в строке proxy_pass или в блоке upstream.

Терминация TLS - шифрование заканчивается на nginx. Снаружи https, внутрь, к приложению, идёт обычный http по локальной сети. Сертификаты живут у nginx, приложение о них не знает.

Если ты пришёл из WordPress и Apache

Главное отличие, из-за которого ломаются переносы сайтов: .htaccess в nginx не существует. Нельзя положить файл в каталог и поменять поведение сервера. Всё - в конфиге, и после правки нужен reload. Плюс к этому: правила из .htaccess (например, «красивые ссылки» WordPress) переписываются одной строкой try_files $uri $uri/ /index.php?$args; - и это лучше, потому что nginx не перечитывает файлы на каждый запрос.

Если ты пришёл из Django

Кто уже видел gunicorn - у него та же схема, что у nginx: мастер-процесс и воркеры. Разница в том, что воркер gunicorn на время запроса занят целиком, а воркер nginx одновременно тянет тысячи соединений: он почти не считает, он перекладывает байты.

Слова, которые встретятся в первых же разделах

Директива - строка конфига вида имя значение;. Всё в nginx - директивы.

Контекст (он же блок) - фигурные скобки, внутри которых директивы действуют: http { server { location { … } } }. Вложенность важна: то, что написано снаружи, обычно наследуется внутрь (раздел 2).

location - правило «какой кусок конфига применить к этому адресу». Не путать с папкой на диске: location /images/ не обязан соответствовать каталогу images.

Мастер и воркеры - один процесс-начальник (читает конфиг, открывает порты, следит) и несколько рабочих, которые обслуживают соединения.

reload - применение нового конфига без разрыва соединений. Не рестарт: старые запросы доживают на старом конфиге.

Статика - файлы, которые отдаются как есть: картинки, css, js, шрифты, pdf. Динамика - то, что приложение считает на каждый запрос.

Апстрим-таймаут, 502, 504 - словарь аварий: 502 обычно значит «до приложения не достучались», 504 - «приложение не ответило вовремя». Ошибка самого приложения при этом чаще выглядит как 500 (раздел 6).

TTFB - время до первого байта ответа. Именно его чаще всего улучшает кеширование и сжатие.

Теперь сам

Вот кусок чужого конфига. Назови своими словами, что делает каждая из четырёх строк, и скажи, какая из них означает поход к приложению, а какая - файл с диска.

server {
    server_name shop.local;
    root /var/www/shop;
    location /static/ { expires 30d; }
    location /api/   { proxy_pass http://app:8000; }
}

Ответ. server_name shop.local - имя сайта, по нему nginx выбирает этот блок из нескольких (аналог ServerName в Apache и близкий родственник ALLOWED_HOSTS в Django). root /var/www/shop - каталог на диске, от которого считаются пути файлов (DocumentRoot). location /static/ с expires 30d - это файл с диска плюс указание браузеру держать его месяц в кеше. location /api/ с proxy_pass - единственная строка, означающая поход к приложению: запрос уходит на app:8000, и что там внутри, nginx не знает. То есть три строки из четырёх обходятся без бэкенда вовсе - ровно то соотношение, о котором была первая глава.

Термины, которые в курсе будут дальше

Не заучивай - просто запомни, что они существуют, а разберём их по ходу:

• upstream-группа - несколько бэкендов под одним именем и правило, как между ними раскидывать запросы (раздел 8);
• буферизация - nginx забирает ответ приложения так быстро, как тот отдаёт, и дальше сам возится с медленным клиентом (раздел 7);
• keepalive - переиспользование установленного соединения вместо создания нового (разделы 7 и 8);
• SNISNIПоле в самом начале установки TLS, где клиент открытым текстом говорит, к какому имени идёт. Без него сервер не знал бы, какой сертификат показывать, когда на одном адресе много сайтов. - имя сайта, которое клиент сообщает до шифрования, чтобы сервер понял, какой сертификат предъявлять (раздел 9);
• ACME - протокол автоматического выпуска сертификатов, по нему работает Let's Encrypt (раздел 9);
• фазы обработки - последовательность этапов, через которые nginx проводит каждый запрос; на ней держится весь курс (раздел 13).