Веб-сервер Nginx

Nginx – это быстрый, надежный HTTP-сервер. Кроме своих основных функций веб-сервера, Nginx может выполнять роли:

• обратного прокси-сервера;
• почтового прокси-сервера;
• TCP/UDP прокси-сервера общего назначения.

Часто Nginx используют в связке с веб-сервером Apache в качестве frontend web-сервера, отвечающий за контент, который видит пользователь в браузере. Два веб-сервера распределяют между собой нагрузку, что ускоряет работу сайта.

Nginx создавался для решения проблемы C10k – обработки сервером одновременно 10 тыс. соединений. Все эти запросы Nginx выполняет в рамках одного потока, не тратя ресурсы и время на создание отдельных потоков.

Установка Nginx

Веб-сервер Nginx – программный продукт с открытым исходным кодом. Чтобы установить Nginx, воспользуйтесь предподготовленными пакетами вашего дистрибутива. Например, для Ubuntu 20.04 это две команды:

$ sudo apt update

$ sudo apt install nginx

После этого в браузере по адресу localhost,  IP-адресу сервера или вашего домена вы получите вывод базового сообщения о работоспособности установленного веб-сервера.

Вывод предустановленного сообщения о работоспособности Nginx

В каталоге /var/www/html находится файл-заглушка index.nginx-debian.html, в котором и содержится текст сообщения по умолчанию. Позже  вы сможете добавить файлы вашего сайта в этот каталог, убрав заглушку, заменить index.html и т.д. Если понадобится связка с интерпретатором PHP, работа с базой данных, то нужно будет доустановить необходимые компоненты в вашей системе.  

Настройка параметров работы веб-сервера Nginx выполняется путем редактирования конфигурационных файлов в каталоге /etc/nginx. Например, базовая настройка веб-сервера:

server {
 listen   80;
 server_name example.com www.example.com;
 #...другие параметры
}

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

Веб-сервер Nginx поддерживает протокол https, но для его реализации необходимо купить либо получить бесплатный SSL-сертификат. Затем добавить в секцию server конфигурационного файла настройки: 

server {
 listen           443 ssl;
 server_name      www.example.com;
              ssl_certificate     www.example.com.crt;
              ssl_certificate_key www.example.com.key;
 ssl_protocols    TLSv1 TLSv1.1 TLSv1.2;
 ssl_ciphers      HIGH:!aNULL:!MD5;
 #... другие параметры
}

• параметр listen определяет сетевой порт, на котором будет отвечать веб-сервер;
• server_name – имя сервера;
• ssl_certificate – указывает местоположения публичного сертификата сервера;
• ssl_certificate_key – секретный ключ, с доступом на чтение только для главного процесса Nginx;
• ssl_protocols и ssl_ciphers задают значение номера версии протоколов и шифры, которые будут использоваться при установке соединения и передаче данных.    

Для упрощения процедуры настройки SSL-соединения, можно воспользоваться генератором конфигурации, разработанного компанией Mozilla (проект на GitHub).

Mozilla SSL Configuration Generator

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

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

По команде:  

$ sudo nginx -s reload

веб-сервер Nginx поручает главному процессу проверить правильность настроек.

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

Вместе с управлением поведением веб-сервера Nginx вы можете управлять непосредственно работой его службы, например, остановка службы выполняется командой:

$ sudo systemctl stop nginx

Запустить снова процесс работы nginx:

$ sudo systemctl start nginx

Узнать состояние, в котором находится процесс nginx:

$ systemctl status nginx

Вывод сообщения о работоспособности службы Nginx

Как вы можете увидеть на скриншоте, Nginx работает, и его работу обеспечивают два процесса:

• master – главный процесс (он всегда один);
• worker – рабочий процесс (их может быть несколько).

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

Количество рабочих процессов должно соответствовать количеству процессорных ядер в системе (настраивается директивой worker_processes в файле конфигурации nginx.conf).

По умолчанию конфигурационный файл nginx настроен таким образом, что веб-сервер отвечает на любой запрос на свой IP-адрес по 80 порту.

Nginx в разных системах

Nginx – это кроссплатформенное решение, но если для Linux-дистрибутивов и FreeBSD все в порядке, то на платформе Windows этот веб-сервер желательно использовать в тестовом режиме, т.к. он не оптимизирован на производительность и масштабирование.

На платформе Windows логичнее использовать другой веб-сервер, например, IIS. Однако, если все-таки в Windows появится необходимость получить работающий Nginx, то всегда есть альтернативное решение – это использование систем виртуализации.

Nginx – небольшой веб-сервер, он идеально подходит для работы в контейнере. Например, если у вас установлен Docker, то поднять контейнер с Nginx можно из официального образа:

$ docker run --name mynginx1 -p 80:80 -d nginx

• mynginx1 – имя создаваемого контейнера на базе образа nginx, находящегося на Docker Hub;
• параметр -p – указывает соответствие портов контейнера и узла, на котором он запущен.

Такой вариант позволяет быстро получить работоспособную систему.

Виртуальные серверы

Nginx может быть разделен на несколько виртуальных машин при едином централизованном управлении веб-сервером. Это удобно для поддержки и администрирования множества сайтов на одном хосте.

В файле конфигурации nginx.conf, в отдельной секции server {}, для каждого виртуального сервера должно быть указано его уникальное доменное имя или IP-адрес, или уникальный для данного физического сервера порт.

Например, для сайта с адресом site.local сначала создайте на сервере отдельный каталог для хранения файлов виртуального сервера:

$ sudo mkdir /var/www/site.local

$ sudo mkdir /var/www/site.local/html

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

$ sudo chown -R $USER:$USER /var/www/site.local/html

Дайте непривилегированному пользователю права на доступ к каталогу и файлам виртуального сервера:

$ sudo chmod -R 755 /var/www/site.local/html

Добавьте тестовый файл для виртуального сервера:

$ nano /var/www/site.local/html/index.html

Например, с таким содержанием:

<!DOCTYPE html>
 <html lang="en">
     <head>
         <meta charset="utf-8">
         <title>Nginx Virtual Server</title>
     </head>
    <body>
         <h1>Welcome to nginx!</h1>
         <p>The virtual server works great!</p>
     </body>
</html>

Затем добавьте секцию server {} вашего виртуального сервера в файл конфигурации Nginx.

Все параметры задаются в основном файле конфигурации nginx.conf. Но, чтобы конфигурационный файл не разрастался, используйте модель, где основные параметры задаются в файле /etc/nginx/nginx.conf, затем параметры для установок по умолчанию /etc/nginx/sites-available/default, например, добавьте в него секцию: 

server {
        listen 80;
        listen [::]:80;
        server_name site.local;
        root /var/www/site.local/html;
        index index.html;
        location / {
                try_files $uri $uri/ =404;
        }

После внесения изменений в конфигурацию веб-сервера следует применить настройки. В нашем примере веб-сервер был запущен в локальной сети на виртуальной машине, доступной по IP-адресу 192.168.0.120, а сайты должны отвечать на локальные DNS: example.local и site.local.

На ОС Windows, чтобы получить доступ к этой виртуальной машине по локальному доменному имени, нужно отредактировать файл hosts. Обычно он находится в папке C:\Windows\System32\drivers\etc. В конце файла hosts добавьте строки:

192.168.0.120 example.local

192.168.0.120 site.local

После чего вы сможете открыть виртуальный сервер в браузере:

Вывод пользовательского сообщения о работоспособности виртуального сервера в Nginx.

Далее можно еще более сегментировать конфигурацию веб-сервера Nginx.

Для этого вынесите секцию server {} вашего виртуального сервера в отдельный файл, например, /etc/nginx/sites-available/ site.local, а затем, чтобы разрешить доступ к этому ресурсу, добавьте символьную ссылку в каталог /sites-enabled:

$ sudo ln -s /etc/nginx/sites-available/site.local /etc/nginx/sites-enabled/

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

После внесения изменений в конфигурацию можно проверить ее правильность:

$ sudo nginx -t

И перезагрузите сервис для вступления настроек в силу:

$ sudo systemctl restart nginx

Такая централизированная конфигурация очень удобна для выполнения настроек веб-сервера. 

Nginx и высокие нагрузки

Nginx в роли обратного (реверсивного) прокси-сервера используется администраторами для равномерного распределения нагрузки. Реверсивный прокси-сервер применяется в качестве frontend-сервера и устанавливается  перед backend-сервером (очень часто это  Apache). Таким образом, Nginx сразу же обрабатывает все запросы пользователей, поступившие из Интернета и “разделяет” функции ответа веб-серверов. Так, сам Nginx в роли frontend-сервера отвечает за отдачу контента, видимого пользователям в их браузерах. Как правило, это все статические файлы сайта: HTML, CSS, JavaScript. Backend-сервер в этом случае будет отвечать за выполнение скриптов сайта, за информацию из базы данных. Работая вместе, два веб-сервера ускоряют ответ сайта на запросы пользователей. 

Nginx в роли реверсивного прокси-сервера

Конфигурация Nginx как реверсивного прокси-сервера задается внутри секции server {} директивой location:

location /path/ {
              proxy_pass http://www.example.local/link/;
}

В этом случае все запросы на ваш хост, внутри пути /path, например: /path/index.html будет переброшен на прокси-сервер http://www.example.local/link/index.html. Вы можете задавать номера портов проксируемого сервера и т. п.

server {
 location / {
              proxy_pass http://localhost:8080/;
               }
 location ~ \.(gif|jpg|png)$ {
                   root /data/images;
               }
}

Такая конфигурация сервера обеспечит проксирование всех запросов на http://localhost:8080/, кроме изображений .gif, .jpg или png, которые Nginx будет отдавать сам как статику из каталога /data/images.

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

Для быстрого развертывания связки Nginx и Apache можно воспользоваться разработкой проекта веб-панели Vesta Control Panel. На своем VPS/VDS или, поэкспериментировав локально в среде виртуализации, можно на базе поддерживаемых проектом версий RHEL/CentOS, Debian или Ubuntu в считанные минуты получить настроенный виртуальный хостинг с прокси-сервером Nginx и удобной панелью управления.

Редактирование параметров хоста в VestaCP

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

Nginx в роли балансировщика нагрузки

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

• Round Robin (круговая система) – запросы клиентов равномерно распределяются между внутренними бэкэнд-серверами. Для бэкэнд-серверов можно указывать весовой коэффициент. Чем выше вес бэкэнд-сервера, тем больше он будет получать запросов.
• Least Connections (наименьшее количество подключений) – запросы направляются на наименее загруженный бэкэнд-сервер.
• IP Hash (IP- хэш) – для каждого входящего сообщения вычисляется хэш-функция по его IP-адресу, и запросы от определенного клиента всегда попадают на обслуживающий его сервер.
• Hash (хэш) – пользователь в строке URI, IP-адреса или порта может в виде переменной задать целевой бэкэнд-сервер для обработки запроса.
• Random (Случайно) – клиентские запросы передаются случайным образом на целевые бэкэнд- серверы.

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

Настройка балансировщика нагрузки выполняется задачей параметров конфигурационного файла Nginx, например:

http {
 upstream myapp1 {
 ip_hash;
     server srv1.example.com;
     server srv2.example.com;
     server srv3.example.com;
 }
 server {
     listen 80;
location / {
         proxy_pass http://myapp1;
     }
 }
}

Таким образом, Nginx отлично приспособлен для решения задач поддержки работоспособности обычных веб-сайтов и на высоких нагрузках, прибавив к этому возможности гибкого управления трафиком TCP/UDP и почтового прокси-сервера. На сайте проекта, заполнив небольшую форму, можно бесплатно загрузить книгу NGINX Cookbook  на английском языке с многочисленными примерами конфигураций для решения практических задач на базе свободной и коммерческой версий Nginx.

Выводы

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

Плюсы:

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

Минусы:

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