Как перезапустить nginx только после успешного завершения теста конфигурации в ubuntu?

Popular Nginx commands

Reference the following list of popular commands if you ever need a quick reminder on how to use a certain command or what it does. Remember, if you aren’t a root user, you’ll need to each command in order for them to properly work.

Start Nginx

Starting Nginx is very simple. Just use the following command:

If you’re using a systemd based version such as Ubuntu Linux 16.04 LTS and above, use within the command, like so:

Example response:

Stop Nginx

Stopping Nginx will kill all system processes quickly. This will terminate Nginx even if there are open connections. In order to do so, run one of the following commands:

Example response:

This command can still, however, take some time on busy servers. Therefore, if you want Nginx to stop even faster, you can also use:

Quit Nginx

Quitting Nginx is very similar to stopping it however it does so gracefully which means it will finish serving open connections before shutting down. To quit Nginx, use one of the following commands:

Restart Nginx

Restarting Nginx basically performs a stop then a start. Use one of the following commands to run an Nginx restart:

Example response:

Reload Nginx

Reload is a bit different from restart in that, again, it is more gracefully. According to Nginx, reload is defined as «start the new worker process with a new configuration, gracefully shut down old worker processes.». You can reload Nginx by using one of the following commands:

Example response:

Check what the current status of your Nginx web server is with one of the following commands:

Example response:

Test Nginx configuration

You can test your Nginx server’s configuration file before restarting or reloading it completely. This helps prevent any unforeseen errors which can cause your website to gown down. To do this there are two separate commands you can use, both return the same information:

Or use one of the following:

Example response:

Check Nginx version

There are also two different ways to check your Nginx version. Both are fairly similar but one shows a little more information than the other. Use one of the following Nginx commands to print the Nginx version:

Use the following command to print the Nginx version, compiler version and configure parameters.

Show command help

If you’d like a quick reference guide of the commands available directly from within the terminal, use one of the following help commands:

Or:

Основные ошибки nginx и их устранение

502 Bad Gateway

Ошибка означает, что NGINX не может получить ответ от одного из сервисов на сервере. Довольно часто эта ошибка появляется, когда NGINX работает в связке с Apache, Varnish, Memcached или иным сервисом, а также обрабатывает запросы PHP-FPM.
Как правило, проблема возникает из-за отключенного сервиса (в этом случае нужно проверить состояние напарника и при необходимости перезапустить его) либо, если они находятся на разных серверах, проверить пинг между ними, так как, возможно, отсутствует связь между ними.
Также, для PHP-FPM нужно проверить права доступа к сокету.
Для этого убедитесь, что в прописаны правильные права

listen = /tmp/php5-fpm.sock 
listen.group = www-data
listen.owner = www-data

504 Gateway Time-out

Ошибка означает, что nginx долгое время не может получить ответ от какого-то сервиса. Такое происходит, если Apache, с которым NGINX работает в связке, отдаёт ответ слишком медленно.
Проблему можно устранить с помощью увеличения времени таймаута.
При работе в связке NGINX+Apache в конфигурационный файл можно внести изменения:

server { 
... 
   send_timeout 800;
   proxy_send_timeout 800;
   proxy_connect_timeout 800;  
   proxy_read_timeout 800;  
... 
}

Тут мы выставили ожидание таймаута в 800 секунд.

Upstream timed out (110: Connection timed out) while reading response header from upstream

Причиной может быть сложная и потому долгая обработка php в работе PHP-FPM.
Здесь тоже можно увеличить время ожидания таймаута

location ~ \.php$ { 
   include fastcgi_params;
   fastcgi_index index.php; 
   fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; 
   fastcgi_pass unix:/tmp/php5-fpm.sock;  
   fastcgi_read_timeout 800;
}

800 секунд на ожидание ответа от бекенда.

413 Request Entity Too Large

Ошибка означает, что вы пытались загрузить слишком большой файл. В настройках nginx по умолчанию стоит ограничение в 1Mb.
Для устранения ошибки в nginx.conf нужно найти строку

client_max_body_size 1m;

и заменить значение на нужное. Например, мы увеличим размер загружаемых файлов до

client_max_body_size 100m;

Также, можно отключить проверку размера тела ответа полностью значением ноль:

client_max_body_size 0;

304 Not Modified не устанавливается

Если возникает проблема с правильным отображением ответного заголовка сервера , то проблема, скорее всего, в пунктах:

В секции конкретного сайта включен (). По умолчанию, ssi отключен, но некоторые хостеры и ISPManager любят его прописывать в дефолтную конфигурацию сайта включенным. Его нужно обязательно отключить, закомментировав или удалив эту строку;
установить в , то есть на уровне или конкретного прописать:

Сжатие

Это один из самых эффективных методов ускорить ответ от вашего веб-сервера nginx.

Пример настроенного nginx.conf:

http {
…
gzip on;
gzip_min_length 1000;
gzip_proxied expired no-cache no-store private auth;
gzip_types text/plain text/css text/javascript application/javascript application/x-javascript text/xml application/xml application/xml+rss application/json;
gzip_disable «msie6»;
…

gzip включает сжатие.

gzip_min_length устанавливает минимальную длину ответов, для которых будет применяться сжатие. По умолчанию 20, но имеет смысл поставить больше, так как постоянное сжатие приведет к повышению нагрузки на процессоры сервера и клиента.

gzip_proxied перечисляет параметры проксированных запросов, для которых будет разрешено сжатие.

gzip_types по умолчанию включено сжатие для ответов типа текст. В данном параметре можно перечислить все необходимые типы ответов.

gzip_disable запрещает для перечисленных параметров заголовка User-Agent сжатие. В данном примере для Internet Explorer 6 сжатие применяться не будет (данный браузер не умеет принимать сжатые ответы).

Установка PHP и PHP-FPM

Устанавливаем PHP и PHP-FPM:

apt-get install php php-fpm

Разрешаем автозапуск php-fpm и запускаем его:

systemctl enable php7.2-fpm

* обратите внимание, что мы запустили php-fpm версии 7.2. Но установлена может быть и другая версия — ее можно узнать по версии php командой php -v

Настройка связки NGINX + PHP

Открываем файл для настройки виртуального домена по умолчанию:

vi /etc/nginx/sites-enabled/default

В секции location или server редактируем параметр index на следующее значение:

…
index index.php index.html index.htm;
…

* в данном случае мы сказали серверу сначала искать индексный файл index.php, затем остальные по списку.

А внутри секции server добавим следующее:

location ~ \.php$ {
set $root_path /var/www/html;
fastcgi_pass unix:/run/php/php7.2-fpm.sock;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $root_path$fastcgi_script_name;
include fastcgi_params;
fastcgi_param DOCUMENT_ROOT $root_path;
}

* где /var/www/html — корневой путь хранения скриптов; /run/php/php7.2-fpm.sock — путь до сокетного файла для взаимодействия с php-fpm

Обратите еще раз внимание, что если в нашей системе будет установлена другая версия php, необходимо внести соответствующую корректировку

Пример файла default:

server {
listen 80 default_server;
listen :80 default_server;
   root /var/www/html;
index index.php index.html index.htm index.nginx-debian.html;
server_name _;
location / {
index index.php index.html index.htm;
}
   location ~ \.php$ {
       set $root_path /var/www/html;
        fastcgi_pass unix:/run/php/php7.2-fpm.sock;
        fastcgi_index index.php;
        fastcgi_param SCRIPT_FILENAME $root_path$fastcgi_script_name;
        include fastcgi_params;
        fastcgi_param DOCUMENT_ROOT $root_path;
   }
}

Проверяем правильность настроек nginx:

nginx -t

И перезагружаем его:

systemctl restart nginx

Открываем конфигурационный файл PHP-FPM:

vi /etc/php/7.2/fpm/pool.d/www.conf

Проверяем, что путь до сокетного файла такой же, как мы задали в настройках NGINX:

listen = /run/php/php7.2-fpm.sock

В противном случае меняем его и перезапускаем сервис:

systemctl restart php7.2-fpm

Теперь заходим в каталог хранения настроенного сайта:

cd /var/www/html

Создаем index.php со следующим содержимым:

vi index.php

<?php phpinfo(); ?>

Открываем браузере и переходим по адресу http://<IP-адрес сервера>. Мы должны увидеть сводную информацию по PHP и его настройкам:

* в данном примере используется php версии 7.2.

Шаг 3: Проверка работы веб-сервера

После завершения процесса установки Ubuntu 16.04 запустит Nginx автоматически. Таким образом веб-сервер уже должен быть запущен.

Мы можем убедиться в этом выполнив следующую команду:

Как видно из вывода выше, сервис запущен и работает. Тем не менее, убедимся в его полной работоспособности путём запроса веб-страницы.

Для этого мы можем проверить, отображается ли веб-страница Nginx, доступная по умолчанию при вводе доменного имени или IP адреса сервера.

Если у вас ещё нет настроенного доменного имени для вашего сервера, вы можете узнать, как настроить домен в Digital Ocean из этой статьи.

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

В результате будет выведено несколько IP адресов. Попробуйте вставить каждый из них в браузер.

Другим способом определить свой IP адрес будет проверка, как ваш сервер виден из Интернета:

Наберите полученный IP адрес или доменное имя в вашем веб-браузере. Вы должны увидеть страницу Nginx по умолчанию.

Если вы видите подобную страницу в своём браузере, вы успешно установили Nginx.

Шаг 4: Управление процессом Nginx

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

Для остановки веб-сервера используйте команду:

Для запуска остановленного веб-сервера наберите:

Для перезапуска веб-сервера можно использовать следующую команду:

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

По умолчанию Nginx настроен на автоматический запуск при запуске сервера. Если такое поведение веб-сервера вам не нужно, вы можете отключить его следующей командой:

Для повторного включения запуска Nginx при старте сервера введите:

Как nginx обрабатывает запросы

nginx вначале решает, какой из серверов должен обработать запрос.
Рассмотрим простую конфигурацию,
где все три виртуальных сервера слушают на порту *:80:

В этой конфигурации, чтобы определить, какому серверу следует направить
запрос, nginx проверяет только поле “Host” заголовка запроса.
Если его значение не соответствует ни одному из имён серверов
или в заголовке запроса нет этого поля вовсе,
nginx направит запрос в сервер по умолчанию для этого порта.
В вышеприведённой конфигурации сервером по умолчанию будет первый сервер,
что соответствует стандартному поведению nginx по умолчанию.
Сервер по умолчанию можно задать явно с помощью параметра
в директиве
:

Следует иметь в виду, что сервер по умолчанию является свойством
слушающего порта, а не имени сервера.
Подробнее это обсуждается ниже.

Если запросы без поля “Host” в заголовке не должны
обрабатываться, можно определить сервер, который будет их отклонять:

Здесь в качестве имени сервера указана пустая строка, которая
соответствует запросам без поля “Host” в заголовке,
и возвращается специальный для nginx код 444, который закрывает
соединение.

Рассмотрим более сложную конфигурацию,
в которой некоторые виртуальные серверы слушают на разных адресах:

В этой конфигурации nginx вначале сопоставляет IP-адрес и порт
запроса с директивами

в блоках
.
Затем он сопоставляет значение поля “Host”
заголовка запроса с директивами

в блоках
,
которые соответствуют IP-адресу и порту.
Если имя сервера не найдено, запрос будет обработан в
сервере по умолчанию.
Например, запрос , пришедший на порт
192.168.1.1:80, будет обработан сервером по умолчанию для порта
192.168.1.1:80, т.е. первым сервером, т.к. для этого порта
не указан в списке имён серверов.

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

Теперь посмотрим на то, как nginx выбирает location
для обработки запроса на примере обычного простого PHP-сайта:

nginx вначале ищет среди всех префиксных location’ов, заданных строками,
максимально совпадающий.
В вышеприведённой конфигурации
указан только один префиксный location “”, и поскольку
он подходит под любой запрос, он и будет использован, если других
совпадений не будет найдено.
Затем nginx проверяет location’ы, заданные регулярными выражениями, в
порядке их следования в конфигурационном файле.
При первом же совпадении поиск прекращается и nginx использует
совпавший location.
Если запросу не соответствует ни одно из регулярных выражений,
nginx использует максимально совпавший префиксный location,
найденный ранее.

Следует иметь в виду, что location’ы всех типов сопоставляются только с
URI-частью строки запроса без аргументов.
Так делается потому, что аргументы в строке запроса могут быть
заданы различными способами, например:

Кроме того, в строке запроса можно запросить что угодно:

Теперь посмотрим, как бы обрабатывались запросы
в вышеприведённой конфигурации:

Запросу “” во-первых соответствует префиксный
location “”, а во-вторых — регулярное выражение
“”,
поэтому он обрабатывается location’ом регулярного выражения.
Согласно директиве “” запрос
отображается в файл , который
и посылается клиенту.
Запросу “” также во-первых соответствует префиксный
location “”, а во-вторых — регулярное выражение
“”.
Следовательно, он обрабатывается location’ом регулярного выражения
и запрос передаётся FastCGI-серверу, слушающему на localhost:9000.
Директива

устанавливает FastCGI-параметр
в “”,
и сервер FastCGI выполняет указанный файл.
Переменная равна
значению директивы
,
а переменная равна
URI запроса, т.е. “”.
Запросу “” соответствует только префиксный
location “”, поэтому запрос обрабатывается в нём.
Согласно директиве “” запрос
отображается в файл , который
и посылается клиенту.
Обработка запроса “” более сложная.
Ему соответствует только префиксный location “”,
поэтому запрос обрабатывается в нём.
Затем директива

проверяет существование индексных файлов согласно своих параметров
и директиве “”.
Если файл не существует,
а файл существует, то
директива делает внутреннее перенаправление на “”
и nginx снова сопоставляет его с location’ами,
как если бы такой запрос был послан клиентом.
Как мы видели ранее, перенаправленный запрос будет в конечном итоге
обработан сервером FastCGI.

Заключение

Подведем итог того, что мы сделали:

Настроили сервисы nginx, apache, php-fpm таким образом, чтобы они отдавали информацию о своем состоянии.
С помощью zabbix агентов передали эту информацию на сервер.
Используя зависимые элементы (dependent items) настроили парсинг метрик.
Настроили на сервере мониторинга необходимые шаблоны и прикрепили их к наблюдаемым серверам.
Собрали dashboard для мониторинга за веб сервером.

То есть выполнили весь комплекс действий для организации полноценного мониторинга web сервера в zabbix.

Одно из применений подобного мониторинга — выбор более быстрого хостинга для сайта. К примеру, мне некоторое время назад понадобилось сменить хостинг. Но как узнать, будет ли он быстрее текущего или нет. Характеристики примерно у всех одинаковые. Я просто взял тестовый период, настроил на сервере все, что мне нужно, в том числе мониторинг веб сервера, перенес туда сайт и понаблюдал сутки. Уже по времени отклика nginx и php-fpm мне стало понятно, что новый хостинг быстрее:

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

Это пример из старой версии статьи, где показаны старые метрики и графики. Оставил его, так как он в целом информативен. Текущий мониторинг web сайта так же можно использовать для анализа производительности хостинга.

Онлайн курс «Сетевой инженер»

Если у вас есть желание научиться строить и поддерживать высокодоступные и надежные сети, рекомендую познакомиться с онлайн-курсом «Сетевой инженер» в OTUS. Это авторская программа в сочетании с удалённой практикой на реальном оборудовании и академическим сертификатом Cisco! Студенты получают практические навыки работы на оборудовании при помощи удалённой онлайн-лаборатории, работающей на базе партнёра по обучению — РТУ МИРЭА: маршрутизаторы Cisco 1921, Cisco 2801, Cisco 2811; коммутаторы Cisco 2950, Cisco 2960.

Особенности курса:

Курс содержит две проектные работы.;
Студенты зачисляются в официальную академию Cisco (OTUS, Cisco Academy, ID 400051208) и получают доступ ко всем частям курса «CCNA Routing and Switching»;
Студенты могут сдать экзамен и получить вместе с сертификатом OTUS ещё сертификат курса «CCNA Routing and Switching: Scaling Networks»;

Проверьте себя на вступительном тесте и смотрите программу детальнее по .