nginx под Windows

Версия nginx под Windows использует “родной” Win32 API (не эмуляцию Cygwin). В настоящий момент в качестве методов обработки соединений используются select() и poll() (1.15.9), поэтому не стоит ожидать высокой производительности и масштабируемости. В силу этого и ряда других известных проблем версия nginx под Windows рассматривается пока как бета-версия. На данный момент в ней доступна практически вся функциональность, что и в версии nginx под UNIX, за исключением XSLT-фильтра, фильтра изображений, модуля GeoIP и встроенного языка Perl.

Чтобы установить nginx/Windows, скачайте дистрибутив последней основной версии (1.19.10), поскольку основная ветвь nginx содержит все известные исправления. Затем распакуйте дистрибутив, перейдите в каталог nginx-1.19.10 и запустите nginx . Вот пример для корневого каталога на диске C:

Чтобы увидеть процессы nginx, запустите утилиту командной строки tasklist :

Один из процессов главный, другой — рабочий. Если nginx не запускается, нужно искать причину в в файле лога ошибок logs\error.log . Если же лог-файл не создался, то причину этого следует искать в Windows Event Log. Если вместо ожидаемой страницы выводится страница с ошибкой, нужно также искать причины ошибки в файле logs\error.log .

nginx/Windows использует каталог, в котором он был запущен, в качестве префикса для относительных путей в конфигурации. В вышеприведённом примере префиксом является C:\nginx-1.19.10\ . Пути в конфигурационном файле должны задаваться в UNIX-стиле с использованием прямых слэшей:

nginx/Windows работает как стандартное консольное приложение (не сервис) и управляется при помощи следующих команд:

Руководство для начинающих

В этом руководстве даётся начальное введение в nginx и описываются некоторые простые задачи, которые могут быть решены с его помощью. Предполагается, что nginx уже установлен на компьютере читателя. Если нет, см. Установка nginx. В этом руководстве описывается, как запустить и остановить nginx и перезагрузить его конфигурацию, объясняется, как устроен конфигурационный файл, и описывается, как настроить nginx для раздачи статического содержимого, как настроить прокси-сервер на nginx, и как связать nginx с приложением FastCGI.

У nginx есть один главный и несколько рабочих процессов. Основная задача главного процесса — чтение и проверка конфигурации и управление рабочими процессами. Рабочие процессы выполняют фактическую обработку запросов. nginx использует модель, основанную на событиях, и зависящие от операционной системы механизмы для эффективного распределения запросов между рабочими процессами. Количество рабочих процессов задаётся в конфигурационном файле и может быть фиксированным для данной конфигурации или автоматически устанавливаться равным числу доступных процессорных ядер (см. worker_processes).

Как работают nginx и его модули, определяется в конфигурационном файле. По умолчанию, конфигурационный файл называется nginx.conf и расположен в каталоге /usr/local/nginx/conf , /etc/nginx или /usr/local/etc/nginx .

Запуск, остановка, перезагрузка конфигурации

Чтобы запустить nginx, нужно выполнить исполняемый файл. Когда nginx запущен, им можно управлять, вызывая исполняемый файл с параметром -s . Используйте следующий синтаксис:

Где сигнал может быть одним из нижеследующих:

• stop — быстрое завершение
• quit — плавное завершение
• reload — перезагрузка конфигурационного файла
• reopen — переоткрытие лог-файлов

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

Команда должна быть выполнена под тем же пользователем, под которым был запущен nginx.

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

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

Посылать сигналы процессам nginx можно также средствами Unix, такими как утилита kill . В этом случае сигнал отправляется напрямую процессу с данным ID. ID главного процесса nginx записывается по умолчанию в файл nginx.pid в каталоге /usr/local/nginx/logs или /var/run . Например, если ID главного процесса равен 1628, для отправки сигнала QUIT, который приведёт к плавному завершению nginx, нужно выполнить:

Для просмотра списка всех запущенных процессов nginx может быть использована утилита ps , например, следующим образом:

Дополнительную информацию об отправке сигналов процессам nginx можно найти в Управление nginx.

Структура конфигурационного файла

nginx состоит из модулей, которые настраиваются директивами, указанными в конфигурационном файле. Директивы делятся на простые и блочные. Простая директива состоит из имени и параметров, разделённых пробелами, и оканчивается точкой с запятой ( ; ). Блочная директива устроена так же, как и простая директива, но вместо точки с запятой после имени и параметров следует набор дополнительных инструкций, помещённых внутри фигурных скобок ( < и >). Если у блочной директивы внутри фигурных скобок можно задавать другие директивы, то она называется контекстом (примеры: events, http, server и location).

Директивы, помещённые в конфигурационном файле вне любого контекста, считаются находящимися в контексте main. Директивы events и http располагаются в контексте main , server — в http , а location — в server .

Часть строки после символа # считается комментарием.

Раздача статического содержимого

Одна из важных задач конфигурации nginx — раздача файлов, таких как изображения или статические HTML-страницы. Рассмотрим пример, в котором в зависимости от запроса файлы будут раздаваться из разных локальных каталогов: /data/www , который содержит HTML-файлы, и /data/images , содержащий файлы с изображениями. Для этого потребуется отредактировать конфигурационный файл и настроить блок server внутри блока http с двумя блоками location.

Во-первых, создайте каталог /data/www и положите в него файл index.html с любым текстовым содержанием, а также создайте каталог /data/images и положите в него несколько файлов с изображениями.

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

В общем случае конфигурационный файл может содержать несколько блоков server , различаемых по портам, на которых они слушают, и по имени сервера. Определив, какой server будет обрабатывать запрос, nginx сравнивает URI, указанный в заголовке запроса, с параметрами директив location , определённых внутри блока server .

В блок server добавьте блок location следующего вида:

Этот блок location задаёт “ / ” в качестве префикса, который сравнивается с URI из запроса. Для подходящих запросов добавлением URI к пути, указанному в директиве root, то есть, в данном случае, к /data/www , получается путь к запрашиваемому файлу в локальной файловой системе. Если есть совпадение с несколькими блоками location , nginx выбирает блок с самым длинным префиксом. В блоке location выше указан самый короткий префикс, длины один, и поэтому этот блок будет использован, только если не будет совпадения ни с одним из остальных блоков location .

Далее, добавьте второй блок location :

Он будет давать совпадение с запросами, начинающимися с /images/ ( location / для них тоже подходит, но указанный там префикс короче).

Итоговая конфигурация блока server должна выглядеть следующим образом:

Это уже работающая конфигурация сервера, слушающего на стандартном порту 80 и доступного на локальном компьютере по адресу http://localhost/ . В ответ на запросы, URI которых начинаются с /images/ , сервер будет отправлять файлы из каталога /data/images . Например, на запрос http://localhost/images/example.png nginx отправит в ответ файл /data/images/example.png . Если же этот файл не существует, nginx отправит ответ, указывающий на ошибку 404. Запросы, URI которых не начинаются на /images/ , будут отображены на каталог /data/www . Например, в результате запроса http://localhost/some/example.html в ответ будет отправлен файл /data/www/some/example.html .

Чтобы применить новую конфигурацию, запустите nginx, если он ещё не запущен, или отправьте сигнал reload главному процессу nginx, выполнив:

В случае если что-то работает не как ожидалось, можно попытаться выяснить причину с помощью файлов access.log и error.log из каталога /usr/local/nginx/logs или /var/log/nginx .

Настройка простого прокси-сервера

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

Мы настроим базовый прокси-сервер, который будет обслуживать запросы изображений из локального каталога и отправлять все остальные запросы на проксируемый сервер. В этом примере оба сервера будут работать в рамках одного экземпляра nginx.

Во-первых, создайте проксируемый сервер, добавив ещё один блок server в конфигурационный файл nginx со следующим содержимым:

Это будет простой сервер, слушающий на порту 8080 (ранее директива listen не указывалась, потому что использовался стандартный порт 80) и отображающий все запросы на каталог /data/up1 в локальной файловой системе. Создайте этот каталог и положите в него файл index.html . Обратите внимание, что директива root помещена в контекст server . Такая директива root будет использована, когда директива location , выбранная для выполнения запроса, не содержит собственной директивы root .

Далее, используйте конфигурацию сервера из предыдущего раздела и видоизмените её, превратив в конфигурацию прокси-сервера. В первый блок location добавьте директиву proxy_pass, указав протокол, имя и порт проксируемого сервера в качестве параметра (в нашем случае это http://localhost:8080 ):

Мы изменим второй блок location , который на данный момент отображает запросы с префиксом /images/ на файлы из каталога /data/images так, чтобы он подходил для запросов изображений с типичными расширениями файлов. Изменённый блок location выглядит следующим образом:

Параметром является регулярное выражение, дающее совпадение со всеми URI, оканчивающимися на .gif , .jpg или .png . Регулярному выражению должен предшествовать символ

. Соответствующие запросы будут отображены на каталог /data/images .

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

Итоговая конфигурация прокси-сервера выглядит следующим образом:

Этот сервер будет фильтровать запросы, оканчивающиеся на .gif , .jpg или .png , и отображать их на каталог /data/images (добавлением URI к параметру директивы root ) и перенаправлять все остальные запросы на проксируемый сервер, сконфигурированный выше.

Чтобы применить новую конфигурацию, отправьте сигнал reload nginx’у, как описывалось в предыдущих разделах.

Существует множество других директив для дальнейшей настройки прокси-соединения.

Настройка проксирования FastCGI

nginx можно использовать для перенаправления запросов на FastCGI-серверы. На них могут исполняться приложения, созданные с использованием разнообразных фреймворков и языков программирования, например, PHP.

Базовая конфигурация nginx для работы с проксируемым FastCGI-сервером включает в себя использование директивы fastcgi_pass вместо директивы proxy_pass , и директив fastcgi_param для настройки параметров, передаваемых FastCGI-серверу. Представьте, что FastCGI-сервер доступен по адресу localhost:9000 . Взяв за основу конфигурацию прокси-сервера из предыдущего раздела, замените директиву proxy_pass на директиву fastcgi_pass и измените параметр на localhost:9000 . В PHP параметр SCRIPT_FILENAME используется для определения имени скрипта, а в параметре QUERY_STRING передаются параметры запроса. Получится следующая конфигурация:

Таким образом будет настроен сервер, который будет перенаправлять все запросы, кроме запросов статических изображений, на проксируемый сервер, работающий по адресу localhost:9000 , по протоколу FastCGI.

Настройка производительного веб-сервера на NGINX + PHP-FPM

PHP-FPM (Fast Process Manager) – это отдельная реализация обработчика FastCGI для выполнения PHP скриптов. На базе связки веб-сервера NGINX (который обрабатывает статику) и PHP-FPM вы можете построить более быстрый и производительный веб-сервер для своих веб-проектов по сравнению с использованием «классической» связки NGINX, Apache и модуль mod_php (стек LAMP).

В данной статье мы рассмотрим установку и оптимизацию стека LEMP для размещения нагруженного веб-проекта на сервере с CentOS 7 на базе связки NGINX+ PHP-FPM + MariaDB/MySQL + установим для сайта SSL сертификата Let’s Encrypt .

Подключение репозитория, обновление сервера

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

# yum install epel-release -y
# yum update -y

Репозиторий установился, но пакетов для обновлений не найдено, так как установлен свежий образ CentOS.

Установка и настройка веб-сервера Nginx

Для установки свежей версии Nginx, подключим репозиторий разработчика, выполнив команду:

# rpm -Uvh http://nginx.org/packages/centos/7/noarch/RPMS/nginx-release-centos-7-0.el7.ngx.noarch.rpm

Или создав конфигурационный файл репозитория /etc/yum.repos.d/nginx.repo со следующим содержимым:

Если вы используете CentOS 8, измените версию в URL.

Установите пакет веб-сервера Nginx с помощью менеджера пакетов yum (или dnf):

# yum install nginx -y

Теперь можно запустить nginx и добавить его в автозагрузку с помощью systemctl:

# systemctl start nginx
# systemctl enable nginx

Чтобы проверить, что веб-сервер работает, откройте в браузере IP-адрес сервера.

Если у вас тестовая страница не открылась, проверьте настройки разрешенных служб, портов, зон в firewalld на своем сервере.

Настроим конфигурационный файл для отдельного домена build-centos.info. Создадим для сайта отдельную директорию и сам конфигурационный файл:

# mkdir -p /var/www/build-centos.info && mkdir -p /var/www/build-centos.info/log

Откроем файл конфигурации:

И добавим в него следующее содержимое:

Конфигурационный файл содержит настройки для доступа по защищенному протоколу https, так как многие популярные CMS в данный момент по умолчанию работают через него. В дальнейшем мы установим и настроим бесплатный SSL сертификат Let’s Encrypt (по аналогии с установкой Let’s Encrypt сертификата на IIS сайта в Windows Server).

Установка php-fpm и дополнительных модулей php

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

Nginx в свою очередь дает существенный выигрыш при отдаче статики. В нашей конфигурации ngnix будет выступать прокси-сервером (кэширующим и front-end сервером), а в качестве бэкенда будет работать php-fpm.

Для установки свежих версий php, используем репозиторий REMI:

# rpm -ivh http://rpms.famillecollet.com/enterprise/remi-release-7.rpm

После установки, отредактируйте файл /etc/yum.repos.d/remi-php74.repo:

Запустите установку php-fpm и популярных модулей php:

# yum install php-fpm php-cli php-mysql php-gd php-ldap php-odbc php-pdo php-opcache php-pear php-xml php-xmlrpc php-mbstring php-snmp php-soap php-zip

Запустите сервис php-fpm и добавитье его в автозагрузку:

# systemctl start php-fpm
# systemctl enable php-fpm

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

Сервис php-fpm нужно запустить через unix-сокет. В конфигурационном файле /etc/php-fpm.d/www.conf удалите строку listen = 127.0.0.1:9000 и добавьте:

Чтобы запускать php-fpm не от пользователя apache (по-умолчанию), укажите следующие параметры в конфигурационном файле:

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

# systemctl restart php-fpm

Установка Let’s Encrypt и подключение сертификата

Чтобы выпустить бесплатный сертификат Let’s Encrypt, нужно установить нужное certbot.

# yum install certbot

После запуска команды, вам нужно будет заполнить все данные, указав почтовый ящик, домен и так далее:

Чтобы сертификат был корректно выпущен, ваш домен должен быть существующим и направлен на соответствующий веб-сервер.

После выпуска сертификата, выполните перезагрузку веб-сервера nginx и проверье результат.

# systemctl restart nginx

Соединение в браузере защищено!

Для автоматического продление сертификатов измените конфигурационный файл /etc/letsencrypt/renewal/build-centos.info.conf следующим образом:

# renew_before_expiry = 30 days
version = 0.18.1
archive_dir = /etc/letsencrypt/archive/ build-centos.info
cert = /etc/letsencrypt/live/build-centos.info/cert.pem
privkey = /etc/letsencrypt/live/build-centos.info/privkey.pem
chain = /etc/letsencrypt/live/build-centos.info/chain.pem
fullchain = /etc/letsencrypt/live/build-centos.info/fullchain.pem

# Options used in the renewal process
[renewalparams]
authenticator = webroot
installer = None
account = e9c86e6aa57b45f9614bc7c0015927a5
post_hook = nginx -s reload
[[webroot_map]]
www.build-centos.info = /var/www/build-centos.info
build-centos.info = /var/www/build-centos.info

После изменения файла, добавьте в крон задание:

30 2 * * * root /usr/bin/certbot renew —post-hook «nginx -s reload»

Чтобы проверить, что nginx работает с php, я создал файл index.php и добавил в него:

Установка MySQL/MariaDB на веб сервере

Данный шаг мы полностью пропустим, так как на сайте уже есть статья по установке и тюнингу MariaDB. Воспользуйтесь ей.

Настройка Nginx и PHP-FPM для высоконагруженных проектов

Чтобы ваш веб-сервер работал с высокой производительностью и мог обработать большое количество запросов от клиентов, одного железа недостаточно. Важно правильно настроить работу связки nginx и php-fpm.

Настройка nginx

Откройте файл /etc/nginx/nginx.conf и изменит конфигурацию Nginx следующим образом:

• worker_processes 2; — уставите количество рабочих процессов равным количеству ядер на сервере.
• worker_connections 1024; — определяет количество соединений одного рабочего процесса. Выставляйте значения от 1024 до 4096.
• use epoll; — оптимальный вариант метода соединений для Linux.
• multi_accept on; — nginx будет принимать максимальное количество соединений.

• tcp_nodelay on; — отправляет заголовки и начало файла в одном пакете.
• tcp_nopush on;

Для проектов в которых содержится большое количество статических файлов, обязательно включайте gzip сжатие:

Добавьте большое количество типов файлов, чтобы все проверки на googlespeed проходили:
gzip_types application/atom+xml application/javascript text/javascript application/json application/ld+json application/manifest+json application/rss+xml application/vnd.geo+json font/ttf application/x-font-ttf application/vnd.ms-fontobject application/font-woff application/font-woff2 application/x-web-app-manifest+json application/xhtml+xml application/xml font/opentype image/bmp image/svg+xml image/x-icon text/cache-manifest text/css text/plain text/vcard text/vnd.rim.location.xloc text/vnd.wap.wml text/vtt text/x-component text/x-cross-domain-policy;

Настройка сжатия позволит ускорить ваш проект.

• keepalive_timeout 30; — веб-сервер будет ожидать 30 секунд, прежде чем закрыть keepalive соединения
• keepalive_requests 100; — максимальное количество keepalive запросов от одного клиента
• reset_timedout_connection on; — включите данный параметр, если не хотите, чтобы соединение от клиента, который перестал отвечать, сбрасывались.
• client_body_timeout 10; — веб-сервер будет ждать 10 секунд подтверждение запроса от клиента, по истечению этого времени, соединение сбросится.
• send_timeout 2; — если клиент прекращает чтение ответа от веб-сервера, nginx сбросит соединение с ним.

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

• client_max_body_size 2m; — сервер не примет запросы больше 2 Мб.

Если контент на вашем проекте меняется не так часто, вы можете использовать кеширование «expires max;» Либо добавьте соответствующую опцию в конфигурационный файл вашего хоста для нужного типа файлов, например:

* ^.+.(js|css|png|jpg|jpeg|gif|ico|woff)$ <
expires 7d;

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

# systemctl restart nginx

Настройка php-fpm

При установке php-fpm вы сразу перевели его на unix-сокет. Это дает существенных прирост в производительности. По оценкам производительность вырастает в 2-3 раза. Остальные же параметры php-fpm нужно настраивать под каждый проект отдельно, рассмотрим пример настройки для сервера с 1024 Мб памяти.

Для php-fpm мы можем выделить примерно 512 мб, оставив остальное под БД и nginx.

В конфигурационный файл /etc/php-fpm/www.conf, добавим:

• pm.max_children = 18 — максимальное число дочерних процессов
• pm.start_servers = 6 — число дочерних процессов, создаваемых при запуске
• pm.min_spare_servers = 4 — минимальное число неактивных процессов сервера
• pm.max_spare_servers = 16 — максимальное число неактивных процессов сервера
• pm.max_requests = 400 — число запросов дочернего процесса, после которого процесс будет перезапущен.

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

На текущий сервер я сразу же установил последнюю версию CMS Bitrix, для проверки производительности. На мой взгляд это самая ресурсоемкая CMS и результаты получились неплохие, если учитывать, что это виртуальная машина на KVM с одним ядром (vCPU) и 1024 ОЗУ:

Оптимизацию настроек MariaDB я не расписывал, так как есть соответствующая статья на сайте. Я сформировал параметры для my.cnf по статье и база показала отличный результат.

При запуске сайте вы заметите невооруженным взглядом, что nginx + php-fpm будет намного быстрее обрабатывать ваши запросы и возвращать страницы, чем apache2 + mod_php. Если у вас есть возможность провести нагрузочные тесты во время настройки сервера, то это несомненно будет плюсом, если же такой возможности нет, вы можете изменить параметры для своих ресурсов исходя из нашего мануала.