Конспект: конфиг и reload

Где лежит конфиг, что nginx видит на самом деле и как применять правки, не роняя прод.

Раскладка файлов

/etc/nginx/
├── nginx.conf              главный файл, всё начинается тут
├── conf.d/*.conf           способ от самого nginx - обычно сюда и пишут
├── sites-available/        придумка Debian: файлы лежат тут
├── sites-enabled/          …а «включаются» симлинком отсюда
├── mime.types              расширение → Content-Type
└── snippets/               куски для нескольких мест

include - это подстановка текста, а не «импорт модуля»: важно, в каком контексте стоит директива.

Три команды

$ команда

nginx -T                          # что nginx видит ПОСЛЕ всех include
nginx -t && systemctl reload nginx  # проверить и применить
nginx -s reload                   # то же без systemd (контейнер)

Приём разбора чужого сервера:

$ команда

nginx -T | grep -n "server_name\|listen\|proxy_pass"

За секунду показывает карту: какие сайты объявлены, на каких портах, куда что уходит.

Что делает reload

Мастер читает новый конфиг, поднимает новых воркеров, старым говорит доработать текущие запросы и завершиться. Битый конфиг не применяется - старые воркеры продолжают работать.

include - это подстановка текста

Три следствия, из которых растут почти все сюрпризы:

контекст задаётся местом вставки, а не именем файла: один сниппет, подключённый в http и в server, окажется на разных уровнях;
маска *.conf разворачивается по алфавиту, и там, где nginx берёт первое подходящее, выбор зависит от имён файлов;
файл вне дерева включений не существует, и ошибки при этом нет: nginx -t честно скажет syntax is ok, проверив конфиг без него. Отсюда классика с shop.conf.bak и с файлом в sites-available без симлинка.

Чего reload НЕ делает

Перечитывается только конфиг. Остаются как были: содержимое proxy_cache, счётчики limit_req и limit_conn. Имена бэкендов при этом спрашиваются заново - и на старте, и на каждом reload; чего nginx не делает, так это не перерезолвит их сам между перезагрузками (лечит resolve у сервера группы, восьмой раздел).

Старые воркеры видны в ps как worker process is shutting down. Ждёт их мастер по умолчанию бесконечно - ограничивается директивой worker_shutdown_timeout.

Ловушки джокера

Две традиции на одном сервере. Конфиг, который «не применяется», нередко просто лежит в sites-available без симлинка в sites-enabled.
reload без nginx -t. Синтаксис проверится и так, но лучше знать об ошибке до, а не после: -t показывает и предупреждения, и точный номер строки.
Правки в nginx.conf вместо своего файла - обновление пакета однажды спросит, чью версию оставить.