Управление сервисом Nginx: практическое руководство по основным командам

Управление сервисом Nginx не сложно, но разница между reload, restart, stop и nginx -s quit имеет значение, когда подключены реальные пользователи. Самая безопасная привычка проста: сначала проверьте конфигурацию, выполните перезагрузку, если достаточно плавной перезагрузки, и перезапускайте только тогда, когда вам действительно нужен полный цикл обслуживания.

Большинство серверов Linux сейчас используют systemd, поэтому systemctl — это команда, которую вы будете использовать чаще всего. В старых дистрибутивах может по-прежнему использоваться команда service. Бинарный файл Nginx также принимает прямые сигналы, которые полезны, когда вам нужно перезагрузить конфигурацию или повторно открыть логи, не обращаясь к менеджеру служб.

Понимание управления сервисом Nginx

Команды управления сервисом Nginx обычно выполняются с помощью системных утилит, таких как systemctl (для систем, использующих systemd, распространенных в современных дистрибутивах Linux) или service (для старых систем инициализации). Конкретная команда может немного отличаться в зависимости от вашей операционной системы и ее фреймворка управления службами.

Запуск Nginx

Чтобы запустить веб-сервер Nginx, используйте команду start. Эта команда запускает процесс Nginx, подготавливая его к приему входящих соединений.

• Использование systemctl (рекомендуется для современных систем):

  sudo systemctl start nginx
  

• Использование service (для старых систем):

  sudo service nginx start
  

При запуске Nginx читает свои файлы конфигурации и начинает прослушивать порты, указанные в его конфигурации (обычно порт 80 для HTTP и 443 для HTTPS).

Остановка Nginx

Чтобы корректно завершить работу веб-сервера Nginx, используйте команду stop. Эта команда дает Nginx сигнал прекратить прием новых соединений и позволяет завершить существующие соединения перед выходом.

• Использование systemctl:

  sudo systemctl stop nginx
  

• Использование service:

  sudo service nginx stop
  

В системах с systemd команда stop просит менеджер служб остановить Nginx. Хватит ли времени у активных запросов на завершение, зависит от конфигурации службы и поведения сигналов. Если вам специально нужно корректное завершение на уровне Nginx, sudo nginx -s quit — это прямая команда, которую нужно знать.

Перезапуск Nginx

Команда restart представляет собой комбинацию stop и последующего start. Она часто используется после внесения значительных изменений в конфигурацию, которые требуют полного цикла обслуживания для вступления в силу. Используйте эту команду с осторожностью, так как она кратковременно прерывает обслуживание.

• Использование systemctl:

  sudo systemctl restart nginx
  

• Использование service:

  sudo service nginx restart
  

Это распространенная команда для применения некоторых типов обновлений конфигурации.

Перезагрузка Nginx

Команда reload — одна из самых полезных команд Nginx для применения изменений конфигурации без разрыва активных соединений. Nginx плавно перезапускает свои рабочие процессы, позволяя им принять новую конфигурацию. Это предпочтительный метод для большинства обновлений конфигурации.

• Использование systemctl:

  sudo systemctl reload nginx
  

• Использование service:

  sudo service nginx reload
  

Совет: Всегда старайтесь использовать reload вместо restart, когда это возможно, чтобы минимизировать время простоя.

Если перезагрузка не удалась из-за неверной новой конфигурации, старые рабочие процессы обычно продолжают работать со старой конфигурацией. Это одна из причин, почему перезагрузка безопаснее перезапуска при рутинных правках. Тем не менее, всегда сначала запускайте nginx -t, чтобы не полагаться на поведение при сбое во время инцидента.

Проверка состояния Nginx

Чтобы проверить, работает ли Nginx, не произошел ли сбой или понять его текущее состояние, используйте команду status.

• Использование systemctl:

  sudo systemctl status nginx
  

• Использование service:

  sudo service nginx status
  

Эта команда предоставляет ценную информацию, включая активность службы, ее идентификатор процесса (PID) и последние записи журнала, которые могут быть полезны для быстрой диагностики.

Тестирование конфигурации Nginx

Перед применением изменений конфигурации, особенно после restart или reload, крайне важно проверить ваши файлы конфигурации на наличие синтаксических ошибок. Nginx предоставляет встроенную команду для этой цели.

Проверка синтаксиса конфигурации

Эта команда проверяет всю конфигурацию Nginx на наличие синтаксических ошибок без фактического применения изменений. Она сообщит о любых найденных проблемах.

nginx -t

Пример вывода (успех):

test is successful
nginx: configuration file /etc/nginx/nginx.conf test is successful

Пример вывода (ошибка):

nginx: [emerg] unknown directive "server_name " in /etc/nginx/sites-available/default:10
nginx: configuration file /etc/nginx/nginx.conf test failed

Предупреждение: Всегда запускайте nginx -t после изменения любого файла конфигурации и перед перезагрузкой или перезапуском Nginx. Этот простой шаг может предотвратить незапланированные простои, вызванные синтаксическими ошибками.

Если ваша конфигурация использует пользовательский основной файл конфигурации, передайте его явно:

sudo nginx -t -c /path/to/nginx.conf

Чтобы увидеть полную загруженную конфигурацию, включая включенные файлы, используйте:

sudo nginx -T

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

Включение автозапуска Nginx

Одноразовый запуск Nginx отличается от включения его после перезагрузки. В системах с systemd используйте:

sudo systemctl enable nginx

Чтобы включить и сразу запустить:

sudo systemctl enable --now nginx

Чтобы отключить автоматический запуск при загрузке:

sudo systemctl disable nginx

Это полезно после установки пакета. Я видел множество серверов, где Nginx был запущен вручную во время настройки, отлично работал неделями, а затем оставался выключенным после перезагрузки для обслуживания, потому что никто не включил службу.

Проверка логов после действий со службой

После неудачного запуска или перезагрузки не смотрите на приглашение командной строки. Спросите systemd и Nginx, что произошло:

sudo journalctl -u nginx -n 100 --no-pager

И проверьте журнал ошибок Nginx:

sudo tail -n 100 /var/log/nginx/error.log

Типичные сообщения достаточно прямолинейны, если знать, что искать:

• bind() to 0.0.0.0:80 failed: другой процесс, возможно, уже использует порт, или неверные разрешения.
• unknown directive: опечатка, отсутствующий модуль или директива, используемая в неправильной сборке Nginx.
• host not found in upstream: ошибка DNS или неверное имя вышестоящего сервера.
• permission denied: Nginx не может прочитать файл, записать логи или получить доступ к ключу сертификата.

При конфликтах портов обычно помогает следующее:

sudo ss -ltnp | grep -E ':80|:443'

Если другой веб-сервер прослушивает тот же порт, решите, какая служба должна его использовать. Не убивайте процесс, если не знаете, почему он там.

Перезагрузка против перезапуска в реальных ситуациях

Используйте reload после большинства правок конфигурации: новые блоки server, измененные заголовки proxy, обновленные значения тайм-аутов, новые редиректы, измененные форматы логов или скорректированные расположения статических файлов. Nginx запускает новые рабочие процессы с новой конфигурацией и позволяет старым рабочим процессам завершить текущую работу.

Используйте restart, когда самой службе требуется чистый запуск. Примеры включают измененные лимиты systemd, измененное окружение, наследуемое службой, обновления пакетов, где изменился бинарный файл, или ситуации, когда главный процесс нездоров. Перезапуск может кратковременно прервать трафик, поэтому делайте это намеренно.

Используйте stop, когда вы хотите остановить службу. Это звучит очевидно, но это важно во время обслуживания. Если балансировщик нагрузки все еще отправляет трафик на сервер после остановки Nginx, пользователи увидят ошибки. По возможности сначала отключайте сервер от балансировщика нагрузки.

Используйте nginx -s reopen после ручной ротации логов, если ваш процесс ротации уже не отправляет сигнал Nginx. Без повторного открытия Nginx может продолжать запись в старый дескриптор файла даже после того, как видимый файл лога был перемещен.

Имена пакетов и имена служб

Большинство дистрибутивов называют службу nginx, но не все окружения идентичны. Если systemctl status nginx говорит, что юнит не существует, перечислите соответствующие юниты:

systemctl list-unit-files | grep -i nginx

На некоторых хостах Nginx может быть установлен из пользовательского пакета, контейнера, панели управления или объединенного стека. В этих случаях команды systemd могут не управлять тем экземпляром, который вы фактически используете. Подтвердите путь к бинарному файлу и конфигурации:

which nginx
nginx -V

nginx -V выводит параметры сборки и пути к модулям. Это также полезно, когда директива конфигурации работает на одном сервере, но не работает на другом, потому что модуль отсутствует.

Если Nginx работает в Docker, команды службы на хосте могут быть неактуальны. Вместо этого вы будете проверять и перезагружать через рабочий процесс контейнера:

docker ps
docker exec <container> nginx -t
docker exec <container> nginx -s reload

Используйте инструмент оркестрации, который владеет процессом. Для Kubernetes это обычно означает изменение ConfigMap или ресурса Ingress и позволение контроллеру выполнить перезагрузку, а не вход в под для постоянного исправления.

Несколько последовательностей команд на случай инцидента

Когда изменение конфигурации нарушает перезагрузку:

sudo nginx -t
sudo journalctl -u nginx -n 50 --no-pager
sudo tail -n 50 /var/log/nginx/error.log

Исправьте первую синтаксическую ошибку или ошибку файла, показанную nginx -t, затем протестируйте снова. Не перезапускайте службу, чтобы "посмотреть, сработает ли", когда синтаксический тест уже говорит, что не сработает.

Когда сайт не работает, и вы не уверены, работает ли Nginx:

sudo systemctl status nginx
sudo ss -ltnp | grep -E ':80|:443'
curl -I http://127.0.0.1/

Это разделяет три вопроса: активна ли служба, прослушивает ли что-то ожидаемые порты, и работает ли локальный HTTP-запрос? Если локальный curl работает, а публичный сайт нет, смотрите DNS, правила брандмауэра, облачные группы безопасности, балансировщики нагрузки или TLS.

Когда HTTPS не работает после обновления сертификата:

sudo nginx -t
sudo systemctl reload nginx
sudo journalctl -u nginx -n 50 --no-pager

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

Когда логи перестают обновляться после ротации:

sudo nginx -s reopen
sudo ls -l /var/log/nginx/
sudo tail -f /var/log/nginx/access.log

Многие пакеты logrotate уже обрабатывают это. Команда все еще полезна, когда вы выполняете ротацию логов вручную или используете пользовательскую настройку ведения журнала.

Чего не следует делать

Не запускайте kill -9 против рабочих процессов Nginx как обычный метод управления. Это не дает процессу шанса завершить работу или очиститься. Используйте systemctl stop, systemctl restart или команды сигналов Nginx, если только вы не имеете дело с действительно зависшим процессом и понимаете побочные эффекты.

Не редактируйте файлы в sites-available и не предполагайте, что они активны. В макетах Debian-стиля сайту обычно требуется символическая ссылка в sites-enabled. В других дистрибутивах макет может использовать conf.d. nginx -T — это самый быстрый способ увидеть, что Nginx на самом деле загружает.

Не забывайте sudo. Запуск nginx -t от непривилегированного пользователя может завершиться неудачей, потому что он не может прочитать ключи сертификатов или включенные файлы, даже если сама служба может. Тестируйте так же, как служба будет работать в продакшене:

sudo nginx -t

Не используйте перезапуск рефлекторно. Перезапуск имеет свое место, но он тяжелее, чем перезагрузка. Во время тихого окна обслуживания это может не иметь значения. Во время оживленного мероприятия по продажам — имеет.

Управление процессами Nginx (продвинутый уровень)

Хотя systemctl и service являются основными инструментами для управления службой Nginx в целом, вы также можете напрямую взаимодействовать с главным процессом Nginx, используя команду nginx с определенными сигналами.

Отправка сигналов Nginx

Nginx использует главный процесс, который управляет рабочими процессами. Вы можете отправлять сигналы главному процессу, чтобы влиять на его поведение. Самый распространенный способ сделать это — найти PID главного процесса и использовать команду kill или, что более удобно, использовать nginx -s <signal>.

• Перезагрузка конфигурации: Аналогично команде reload выше.

  sudo nginx -s reload
  

• Плавное завершение работы: Аналогично команде stop.

  sudo nginx -s quit
  

• Быстрое завершение работы: Это немедленно завершит все рабочие процессы, не дожидаясь обслуживания текущих запросов.

  sudo nginx -s stop
  

• Повторное открытие файлов логов: Полезно, если вы выполняете ротацию файлов логов вручную или если логи записываются в другое место.

  sudo nginx -s reopen
  

Чтобы использовать nginx -s <signal>, Nginx должен знать, где находится файл PID его главного процесса. По умолчанию это часто /var/run/nginx.pid или /run/nginx.pid. При необходимости вы можете указать другое расположение файла PID с помощью опции -c, но это редко требуется для стандартных установок.

Безопасный повседневный рабочий процесс

Для обычных правок конфигурации используйте этот рабочий процесс:

sudo nginx -t
sudo systemctl reload nginx
sudo systemctl status nginx

Затем проверьте сайт с клиента:

curl -I https://example.com/

Если служба не запускается, не запускайте перезапуск повторно. Прочитайте вывод состояния и логи, исправьте первую реальную ошибку, протестируйте снова, а затем запустите или перезагрузите. Команды управления сервисом Nginx невелики, но при правильном использовании они предотвращают превращение плохой правки конфигурации в неизбежный простой.