Как запустить, остановить или перезапустить nginx

Введение

Если у вас еще нет своего сервера для мониторинга, то рекомендую материалы на эту тему. Для тех, кто предпочитает систему CentOS:

1. Установка CentOS 8.
2. Настройка CentOS 8.
3. Установка и настройка zabbix сервера.

То же самое на Debian 10, если предпочитаете его:

1. Установка Debian 10.
2. Базовая настройка Debian.
3. Установка и настройка zabbix на debian.

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

Мы будем использовать в качестве источника информации штатные возможности nginx, apache и php-fpm, затем передавать данные в zabbix сервер и там анализировать. Я подразумеваю, что nginx или apache вы уже настроили и имеете некое представление о работе его компонентов, поэтому некоторые вещи я не разжевываю, а просто говорю, что делать.

Введение

Немного расскажу своими словами о том, как работает модуль ngx_http_proxy_module. Именно он реализует весь функционал, о котором пойдет речь. Допустим, у вас в локальной или виртуальной сети есть какие-то сервисы, не имеющие прямого доступа из интернета. А вы хотите таковой иметь. Можно пробрасывать нужные порты на шлюзе, можно что-то еще придумывать. А можно сделать проще всего — настроить единую точку входа на все свои сервисы в виде nginx сервера и с него проксировать различные запросы к нужным серверам.

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

1. Ранее я рассказывал о настройке чат серверов — matrix и mattermost. В этих статьях я как раз рассказывал о том, как проксировать запросы в чат с помощью nginx. Прошелся по теме вскользь, не останавливаясь подробно. Суть в том, что вы настраиваете на любом виртуальном сервере эти чаты, помещаете их в закрытые периметры сети без лишних доступов и просто проксируете запросы на эти сервера. Они идут через nginx, который у вас смотрит во внешний интернет и принимает все входящие соединения.
2. Допустим, у вас есть большой сервер с множеством контейнеров, например докера. На нем работает множество различных сервисов. Вы устанавливаете еще один контейнер с чистым nginx, на нем настраиваете проксирование запросов на эти контейнеры. Сами контейнеры мапите только к локальному интерфейсу сервера. Таким образом, они будут полностью закрыты извне, и при этом вы можете гибко управлять доступом.
3. Еще один популярный пример. Допустим, у вас есть сервер с гипервизором proxmox или любым другим. Вы настраиваете на одной из виртуальных машин шлюз, создаете локальную сеть только из виртуальных машин без доступа в нее извне. Делаете в этой локальной сети для всех виртуальных машин шлюз по-умолчанию в виде вашей виртуальной машины со шлюзом. На виртуальных серверах в локальной сети размещаете различные сервисы и не заморачиваетесь с настройками фаервола на них. Вся их сеть все равно не доступна из интернета. А доступ к сервисам проксируете с помощью nginx, установленным на шлюз или на отдельной виртуальной машине с проброшенными на нее портами.
4. Мой личный пример. У меня дома есть сервер synology. Я хочу организовать к нему простой доступ по https из браузера по доменному имени. Нет ничего проще. Настраиваю на сервере nginx получение бесплатного сертификата , настраиваю проксирование запросов на мой домашний ip, там на шлюзе делаю проброс внутрь локалки на synology сервер. При этом я могу фаерволом ограничить доступ к серверу только одним ip, на котором работает nginx. В итоге на самом synology вообще ничего не надо делать. Он и знать не знает, что к нему заходят по https, по стандартному порту 443.
5. Допустим, у вас большой проект, разбитый на составные части, которые живут на разных серверах. К примеру, на отдельном сервере живет форум, по пути /forum от основного домена. Вы просто берете и настраиваете проксирование всех запросов по адресу /forum на отдельный сервер. Точно так же можно без проблем все картинки перенести на другой сервер и проксировать к ним запросы. То есть вы можете создать любой location и переадресовывать запросы к нему на другие сервера.

Надеюсь в общем и целом понятно, о чем идет речь. Вариантов использования много. Я привел самые распространенные, которые пришли в голову и которые использую сам. Из плюсов, которые считаю наиболее полезными именно из своих кейсов, отмечу 2:

• Без проблем можете настроить https доступ к сервисам, при этом совершенно не трогая эти сервисы. Вы получаете и используете сертификаты на nginx сервере, используете https соединение с ним, а сам nginx уже передает информацию на сервера со службами, которые могут работать по обычному http и знать не знают о https.
• Вы очень легко можете менять адреса, куда проксируете запросы. Допустим у вас есть сайт, его запросы проксируются на отдельный сервер. Вы подготовили обновление или переезд сайта. Отладили все на новом сервере. Теперь вам достаточно на сервере nginx изменить адрес старого сервера на новый, куда будут перенаправляться запросы. И все. Если что-то пойдет не так, можете оперативно вернуть все обратно.

С теорией закончил. Перейдем теперь к примерам настройки. В своих примерах я буду использовать следующие обозначения:

blog.zeroxzed.ru	доменное имя тестового сайта
nginx_srv	имя внешнего сервера с установленным nginx
blog_srv	локальный сервер с сайтом, куда проксируем соединения
94.142.141.246	внешний ip nginx_srv
192.168.13.31	ip адрес blog_srv
77.37.224.139	ip адрес клиента, с которого я буду заходить на сайт

Root Directory and Index Files

The directive specifies the root directory that will be used to search for a file. To obtain the path of a requested file, NGINX appends the request URI to the path specified by the directive. The directive can be placed on any level within the , , or contexts. In the example below, the directive is defined for a virtual server. It applies to all blocks where the directive is not included to explicitly redefine the root:

Here, NGINX searches for a URI that starts with in the directory in the file system. But if the URI ends with the or extension, NGINX instead searches for the file in the directory because it is defined in the matching block.

If a request ends with a slash, NGINX treats it as a request for a directory and tries to find an index file in the directory. The directive defines the index file’s name (the default value is ). To continue with the example, if the request URI is , NGINX delivers the file if it exists. If it does not, NGINX returns HTTP code by default. To configure NGINX to return an automatically generated directory listing instead, include the parameter to the directive:

You can list more than one filename in the directive. NGINX searches for files in the specified order and returns the first one it finds.

The variable used here here is a custom variable set through the directive. The value of the variable depends on the client’s IP address.

To return the index file, NGINX checks for its existence and then makes an internal redirect to the URI obtained by appending the name of the index file to the base URI. The internal redirect results in a new search of a location and can end up in another location as in the following example:

Here, if the URI in a request is , and does not exist but does, the internal redirect to is mapped to the second location. As a result, the request is proxied.

PHP-FPM Status Page Output formats

By default the status page output is formatted as text/plain. Passing either ‘html’, ‘xml’ or ‘json’ in the query string will return the corresponding output syntax.

Examples for summary status page:

• http://example.com/status
• http://example.com/status?json
• http://example.com/status?html
• http://example.com/status?xml

Example for detailed status page:

• http://example.com/status?full
• http://example.com/status?json&full
• http://example.com/status?html&full
• http://example.com/status?xml&full

You can use json or xml format to process status page output programatically. HTML is useful when viewing detailed status report.

Архитектура и конфигурация Nginx

Установка на Linux возможна двумя способами — из предварительно собранного бинарного файла (пакета) или с помощью исходного кода.

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

Установка Nginx на Windows возможна с помощью интерфейса Win32 API. Однако, такой вариант будет гораздо менее эффективен, даже в серверных версиях и не может быть рекомендован для широкого применения.

Trying Several Options

The directive can be used to check whether the specified file or directory exists; NGINX makes an internal redirect if it does, or returns a specified status code if it doesn’t. For example, to check the existence of a file corresponding to the request URI, use the directive and the variable as follows:

The file is specified in the form of the URI, which is processed using the or directives set in the context of the current location or virtual server. In this case, if the file corresponding to the original URI doesn’t exist, NGINX makes an internal redirect to the URI specified by the last parameter, returning .

The last parameter can also be a status code (directly preceded by the equals sign) or the name of a location. In the following example, a error is returned if none of the parameters to the directive resolve to an existing file or directory.

In the next example, if neither the original URI nor the URI with the appended trailing slash resolve into an existing file or directory, the request is redirected to the named location which passes it to a proxied server.

For more information, watch the Content Caching webinar on‑demand to learn how to dramatically improve the performance of a website, and get a deep‑dive into NGINX’s caching capabilities.

Послесловие¶

Так выглядит стандартная настройка ПО в GNU/Linux. Возможно, она кажется сложной или громоздкой. На самом деле, ничего сложного здесь нет: весь процесс хорошо документирован. По сравнению с GUI имеем больше возможностей. Если нет желания настраивать вручную, для популярного ПО есть множество скриптов для автоматического развертывания.

Если вы когда нибудь брали дешевые или бесплатные хостинги для сайтов, то у вас может возникнуть вопрос: зачем мучиться с настройкой, если там все проще? Все эти хостинги работают на тех же Apache и Nginx, но не дают возможности хоть сколько-нибудь настроить их. Более разумным решением будет взять VDS или VPS и поднять веб-сервер. Крупные компании для размещения сайтов и приложений пользуются такими решениями, как AWS или MS Azure.

Установка¶

Установка пакета

Подключим репозиторий epel, в котором много полезного для CentOS 7. Установим пакет Nginx из репозитория ():

yum install epel-release
yum install nginx

Запуск и автозапуск

Запустим веб-сервер и сразу добавим его в автозагрузку, чтобы он автоматически запускался при старте ОС. Для этого используем ():

systemctl start nginx
systemctl enable nginx

Подсказка

Эквивалентная команда:

systemctl enable --now nginx

Проверим, что веб-сервер успешно запустился:

systemctl status nginx

В результате должно быть что-то такое:

● nginx.service - The nginx HTTP and reverse proxy server
   Loaded: loaded (/usr/lib/systemd/system/nginx.service; enabled; vendor preset: disabled)
   Active: active (running) since Thu 2019-05-02 16:10:57 UTC; 3h 6min ago
   ...

Log Files and syslog

The NGINX and contain a lot of useful information suitable for metric collection. You can use NGINX variables to fully customize the . Certain monitoring tools can leverage NGINX log files for metric collection.

To meet various performance and security requirements, consider using the NGINX syslog capability. While log files are written to disk, syslog allows NGINX to send log data over a network protocol. For example, you can set up a dedicated Linux system to collect all of your log data from various NGINX instances.

For more information on logging, please refer to the NGINX Plus Admin Guide.

Что такое Nginx

Nginx (NGINX, Engine-X, «Энжин-кс») — это бесплатный веб- и почтовый прокси-сервер с непоточной (асинхронной) архитектурой и открытым кодом.

Разработку Nginx начал в 2002 году Игорь Сысоев для Rambler. А в 2004 году он стал доступен широкому кругу пользователей . С 2011 года серверное ПО начала выпускать уже собственная фирма Игоря, которая спустя 2 года запустила расширенную платную версию продукта (Nginx Plus). Весной 2019 года Nginx была выкуплена крупным американским девелопером F5 Networks.

Nginx работает на ОС Unix-типа и был успешно протестирован на OpenBSD, FreeBSD, Linux, Mac OS X, Solaris. На ОС Windows он стал доступен после выпуска бинарной сборки 0,7.52.

На данный момент функционалом пользуются такие известные платформы: Rambler, Begun, Yandex, SourceForge.net, WordPress.com, vkontakte.ru. Статистика показывает, что Nginx используют 22,3 млн веб-сайтов и 2,03 млн дополнительных активных сайтов.

4. Настройка PageSpeed

Google Pagespeed — это модуль Nginx, который выполняет различные оптимизации для того, чтобы страницы грузились быстрее, веб-сервер работал эффективнее, а пользователи не чувствовали дискомфорта. Сюда входит кэширование, оптимизация html кода, оптимизация картинок, объединение javascript и css кода и многое другое. Все это выполняется на уровне Nginx, поэтому эффективнее, чем если бы вы это делали в php. Но тут есть один недостаток, модуль удаляет заголовок Last Modified.

Дело в том, что PageSpeed устанавливает очень долгий строк кэширования для всех файлов, а в имя файла добавляет его хэш. Так скорость загрузки ресурсов выходит намного выше, поскольку браузер будет запрашивать файлы только с новым хэшем, а LastModified удаляется чтобы пользователи смогли увидеть изменения в случае если какой-либо файл будет изменен. А теперь рассмотрим как установить модуль. Нам придется собрать его из исходных кодов.

Сначала установите инструменты для сборки, очень важно, если не установите, потом получите ошибку и не будете знать что делать:

Скачайте и распакуйте исходники Nginx для вашей версии, например, 1.13.3:

Настройка сервера nginx не включает пере сборку и замену программы из репозитория, мы просто используем эти исходники для сборки модуля. Скачайте и распакуйте исходники PageSpeed:

Скачайте и распакуйте библиотеку оптимизации PageSpeed в папку с исходниками модуля:

Скачайте и распакуйте исходники OpenSSL 1.02:

Теперь нам нужно собрать модуль. Сначала смотрим опции, с которыми собран текущий Nginx:

А теперь переходим в папку с Nginx, подставляем все полученные опции, опцию —add-dynamic-module для PageSpeed, OpenSSL и пробуем собрать:

Если все было сделано правильно, то на выходе вы получите модуль ngx_pagespeed.so в папке obj, его нужно скопировать в папку /etc/nginx/modules:

Создаем папку для кэша:

Теперь добавьте такую строчку для включения модуля в /etc/nginx/nginx.conf:

Затем, в секцию сервер достаточно добавить:

Теперь вам достаточно перезапустить nginx чтобы изменения вступили в силу:

Using the stub_status Module

There’s a module for NGINX Open Source called (or simply ) that exposes a few important metrics about NGINX activity.

To check if your NGINX build has the module, run :

All of our include the module on all supported platforms.

If your NGINX build does not include the module, you have to rebuild from source and include the parameter to the script.

As the next step, enable the module in your NGINX configuration by including the directive in a block. You can always add the block to an existing configuration. Alternatively, add a separate block, with a single specialized for the directive, as here:

Appropriate blocks for the directive are sometimes found outside of the main configuration file (nginx.conf). If you don’t see a suitable block in that file, search for additional configuration files which are typically in nginx.conf.

We also recommend that you allow only authorized users to access the metrics, for example by including the and directives in the or block.

After the module is configured, don’t forget to reload the NGINX configuration (with the command, for example). You can read more about NGINX control signals here.

To display the metrics, make a query. The following is appropriate for the configuration shown above:

If this doesn’t work, check where the requests to /nginx_status are routed. In many cases, another block can be the reason why you can’t access the metrics. To read more about these instance‑wide NGINX metrics, see the reference documentation .

With the module enabled in NGINX and working, you can proceed with the installation and configuration of your monitoring system of choice.

Добавление бэкендов

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

upstream cache-api {
    server 10.32.18.6:8080;
    server 10.32.18.7:8080;
    server 10.32.18.8:8080;
}

Сейчас я не касаюсь вопросов тонкой настройки балансировки. Будем идти от простого к сложному. На текущий момент мы добавили три сервера, на которые будет распределяться нагрузка. Далее в настройках виртуального хоста добавляем location, запросы к которому будем равномерно распределять.

location / {
    proxy_pass http://cache-api/;
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Real-IP $remote_addr;
    }

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

weight	Задает вес сервера, по умолчанию 1. Чем больше вес сервера, тем пропорционально больше запросов он будет принимать от балансировщика.
max_conns	Ограничивает максимальное число одновременных активных соединений к проксируемому серверу Значение по умолчанию равно 0 и означает, что ограничения нет.
max_fails	Задаёт число неудачных попыток работы с сервером, которые должны произойти в течение времени, заданного параметром fail_timeout, чтобы сервер считался недоступным на период времени, также заданный параметром fail_timeout. Дефолтное значение — 1.
fail_timeout	Задаёт время, в течение которого должно произойти заданное число неудачных попыток работы с сервером для того, чтобы сервер считался недоступным и время, в течение которого сервер будет считаться недоступным. По умолчанию параметр равен 10 секундам.
backup	Помечает сервер как запасной сервер. На него будут передаваться запросы в случае, если не работают основные серверы.
down	Помечает сервер как постоянно недоступный.

Подробнее об этом написано в официальной документации, в описании модуля ngx_http_upstream_module. К примеру, конфиг бэкендов для балансировки может быть таким.

server 10.32.18.6:8080 max_fails=2 fail_timeout=10s;
server 10.32.18.7:8080 max_fails=2 fail_timeout=10s;
server 10.32.18.8:8080 max_fails=2 fail_timeout=10s;

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

Метод балансировки

Рассмотрим способы балансировки, которые можно использовать в NGINX:

1. Round Robin.
2. Hash.
3. IP Hash.
4. Least Connections.
5. Random.
6. Least Time (только в платной версии NGINX).

Настройка метода балансировки выполняется в директиве upstream. Синтаксис:

upstream <название апстрима> {
    <метод балансировки>
    …
}

Round Robin

Веб-сервер будет передавать запросы бэкендам по очереди с учетом их весов. Данный метод является методом по умолчанию и его указывать в конфигурационном файле не нужно.

Hash

Данный метод определяет контрольную сумму на основе переменных веб-сервера и ассоциирует каждый полученный результат с конкретным бэкендом. Пример настройки:

upstream dmosk_backend {
    hash $scheme$request_uri;
    server 192.168.10.10;
    server 192.168.10.11;
    server 192.168.10.12;
}

* это самый распространенный пример настройки hash — с использованием переменных $scheme (http или https) и $request_uri. При данной настройке каждый конкретный URL будет ассоциирован с конкретным сервером.

IP Hash

Ассоциация выполняется исходя из IP-адреса клиента и только для HTTP-запросов. Таким образом, для каждого посетителя устанавливается связь с одним и тем же сервером. Это, так называемый, Sticky Session метод.

Для адресов IPv4 учитываются только первые 3 октета — это позволяет поддерживать одинаковые соединения с клиентами, чьи адреса меняются (получение динамических адресов от DHCP провайдера). Для адресов IPv6 учитывается адрес целиком.

Пример настройки:

upstream dmosk_backend {
    ip_hash;
    server 192.168.10.10;
    server 192.168.10.11;
    server 192.168.10.12;
}

Least Connections

NGINX определяет, с каким бэкендом меньше всего соединений в данный момент и перенаправляет запрос на него (с учетом весов).

Настройка выполняется с помощью опции least_conn:

upstream dmosk_backend {
    least_conn;
    server 192.168.10.10;
    server 192.168.10.11;
    server 192.168.10.12;
}

Random

Запросы передаются случайным образом (но с учетом весов). Дополнительно можно указать опцию two — если она задана, то NGINX сначала выберет 2 сервера случайным образом, затем на основе дополнительных параметров отдаст предпочтение одному из них. Это следующие параметры:

• least_conn — исходя из числа активных подключений.
• least_time=header (только в платной версии) — на основе времени ответа (расчет по заголовку).
• least_time=last_byte (только в платной версии) — на основе времени ответа (расчет по полной отдаче страницы).

Пример настройки:

upstream dmosk_backend {
    random two least_conn;
    server 192.168.10.10;
    server 192.168.10.11;
    server 192.168.10.12;
}

Least Time

Данная опция будет работать только в NGINX Plus. Балансировка выполняется исходя из времени ответа сервера. Предпочтение отдается тому, кто отвечает быстрее.

Опция для указания данного метода — least_time. Также необходимо указать, что мы считаем ответом — получение заголовка (header) или когда страница возвращается целиком (last_byte).

Пример 1:

upstream dmosk_backend {
    least_time header;
    server 192.168.10.10;
    server 192.168.10.11;
    server 192.168.10.12;
}

* в данном примере мы будем делать расчет исходя из того, как быстро мы получаем в ответ заголовки.

Пример 2:

upstream dmosk_backend {
    least_time last_byte;
    server 192.168.10.10;
    server 192.168.10.11;
    server 192.168.10.12;
}

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

Заключение

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

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

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

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

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

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

Онлайн курс по Linux

Если у вас есть желание научиться строить и поддерживать высокодоступные и надежные системы, рекомендую познакомиться с онлайн-курсом «Administrator Linux. Professional» в OTUS. Курс не для новичков, для поступления нужны базовые знания по сетям и установке Linux на виртуалку. Обучение длится 5 месяцев, после чего успешные выпускники курса смогут пройти собеседования у партнеров.

Что даст вам этот курс:

• Знание архитектуры Linux.
• Освоение современных методов и инструментов анализа и обработки данных.
• Умение подбирать конфигурацию под необходимые задачи, управлять процессами и обеспечивать безопасность системы.
• Владение основными рабочими инструментами системного администратора.
• Понимание особенностей развертывания, настройки и обслуживания сетей, построенных на базе Linux.
• Способность быстро решать возникающие проблемы и обеспечивать стабильную и бесперебойную работу системы.

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

Заключение

Nginx представляет собой практически готовое решение для множества задач, требующих развёртывания полноценного веб-сервера или прокси. По ряду параметров Nginx превосходит своего «старшего коллегу» Apache. Главные из них — отсутствие требовательности к ресурсам и способность обрабатывать большое число соединений одновременно.

Понимание работы и принципа обработки запросов в Nginx позволяет грамотно масштабировать и балансировать нагрузку на современных сайтах, располагающих контентом разных категорий. А связка Nginx и Apache позволяет максимально расширить эффективность применения веб-сервера.

Оцените материал: