Nginx как файловый сервер

Обновлено: 25.01.2025

Установка

Запуск

Настройка

Первые шаги по настройке и использованию nginx описаны в руководстве Beginner’s Guide. Вы можете настроить сервер, редактируя файлы в /etc/nginx/ ; главный файл настроек расположен в /etc/nginx/nginx.conf .

Более подробную информацию можно прочитать на странице Nginx Configuration Examples и в официальной документации.

Приведенные далее примеры покрывают большинство типичных потребностей. Предполагается, что вы используете стандартное место расположения веб-документов ( /usr/share/nginx/html ). Если это не так, замените путь на свой.

Основные настройки

Процессы и соединения

Вы должны выбрать подходящее значение для worker_processes . Этот параметр определяет сколько одновременных соединений сможет принимать nginx и сколько процессоров он сможет при этом использовать. Как правило, это значение устанавливают равным количеству аппаратных потоков в системе. Однако, начиная с версий 1.3.8 и 1.2.5, в качестве значения worker_processes вы также можете задать auto , при этом nginx попытается автоматически подобрать оптимальное значение (источник).

Максимальное количество одновременных соединений, которое nginx сможет принимать, вычисляется как max_clients = worker_processes * worker_connections .

Запуск под другим пользователем

По умолчанию nginx выполняется от имени пользователя nobody. Чтобы запустить его от имени другого пользователя, измените строку user в nginx.conf :

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

Блоки server

Посредством добавления блоков server в файл настроек возможно обслуживать сразу несколько доменов одновременно. Эти блоки работают аналогично "VirtualHosts" в Apache.

В этом примере сервер принимает запросы для двух доменов: domainname1.dom и domainname2.dom :

Перезапустите службу nginx , чтобы изменения вступили в силу.

Следует настроить DNS-сервер, например BIND или dnsmasq, чтобы у подключающихся клиентов эти доменные имена разрешались в IP-адрес сервера.

А пока вы можете просто добавить их в ваш файл /etc/hosts , заменив 192.168.0.101 на фактический IP-адрес сервера:

TLS/SSL

openssl предоставляет поддержку TLS/SSL и установлен по умолчанию на установленных Arch.

Создайте секретный ключ и самоподписанный сертификат. Это подходит для большинства случаев, в которых не требуется CSR:

Примечание: Опция -days является необязательной, а RSA keysize можно уменьшить до 2048 (по умолчанию).

Если же вам нужно создать CSR, то следуйте данным инструкциям по созданию ключа, вместо приведённых выше:

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

Пример nginx.conf , использующего SSL:

Совет: У Mozilla есть полезная SSL/TLS статья, которая описывает рекомендации по настройке специально для nginx, а также автоматизированный инструмент, который поможет вам создать более безопасную конфигурацию.

Перезапустите службу nginx , чтобы изменения вступили в силу.

FastCGI

FastCGI или просто FCGI — это протокол, являющийся интерфейсом между веб-сервером и интерактивными программами. Это модифицированный CGI (Common Gateway Interface), главная цель которого — снизить накладные расходы, связанные со взаимодействием веб сервера и CGI программ, тем самым позволяя серверу обрабатывать большее количество запросов одновременно.

Технология FastCGI встроена в nginx для работы со многими внешними инструментами, например, Perl, PHP и Python.

Реализация PHP

В качестве FastCGI-сервера для PHP рекомендуется использовать PHP-FPM.

Настройка PHP

Опция open_basedir в /etc/php/php.ini должна содержать список всех каталогов, с файлами PHP, которые должны быть доступны серверу. Например, для /usr/share/nginx/html/ и /usr/share/webapps/ :

После этого настройте нужные вам модули. Например, для использования sqlite3 нужно установить php-sqlite . Затем включите этот модуль в файле /etc/php/php.ini , раскомментировав следующую строку:

Основным конфигурационным файлом PHP-FPM является /etc/php/php-fpm.conf . Включите и запустите systemd службу php-fpm .

Примечание: Если вы запускаете nginx в изолированном окружении (к примеру, chroot находится в /srv/nginx-jail , веб-документы расположены в /srv/nginx-jail/www ), то вы должны в /etc/php/php-fpm.conf добавить опции chroot /srv/nginx-jail и listen = /srv/nginx-jail/run/php-fpm/php-fpm.sock внутри секции пула (по умолчанию это [www] ). Создайте каталог для файла сокета, если его нет.

MariaDB

Настройте MySQL/MariaDB как описано в MariaDB.

Раскомментируйте хотя бы одну из следующих строк в /etc/php/php.ini :

Важно: Начиная с PHP 5.5, mysql.so объявлен устаревшим [устаревшая ссылка 2021-05-17] , ваши лог файлы будут переполнены.

Вы можете добавить менее привилегированных MySQL пользователей для ваших веб скриптов. Вы можете также захотеть отредактировать /etc/mysql/my.cnf и раскомментировать строку skip-networking , чтобы MySQL сервер был доступен только из localhost. Вы должны перезапустить MySQL, чтобы изменения вступили в силу.

Совет: Вы можете захотеть установить инструменты вроде phpMyAdmin, Adminer или mysql-workbench , чтобы работать с вашими базами данных.

Настройка nginx

Добавление к основной конфигурации

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

Если требуется обрабатывать другие расширения наряду с PHP (например .html и .htm):

Все расширения, обрабатываемые в php-fpm должны быть также явно добавлены в /etc/php/php-fpm.conf :

Примечание: Аргумент fastcgi_pass должен быть определен как TCP-сокет или сокет Unix выбранным FastCGI сервером в его конфигурационном файле. По умолчанию для php-fpm используется сокет

Вы можете использовать также общий TCP-сокет:

Однако, доменные сокеты Unix должны работать быстрее.

Пример, показанный ниже, является копией рабочей конфигурации. Заметьте, что в этом примере путь к root определен непосредственно в server , а не внутри location (как это сделано в конфигурации по умолчанию).

Управление несколькими блоками (опционально)

Если вы добавляете однотипную конфигурацию для PHP сразу во множество блоков server , может оказаться удобнее использовать для этого внешний файл:

Теперь включите файл php.conf в каждый из блоков server :

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

Перезапустите службы php-fpm и nginx после изменения настроек, чтобы изменения вступили в силу.

Чтобы проверить работу FastCGI, создайте новый файл .php внутри каталога веб-документов, содержащий:

При открытии файла в браузере должна отобразиться информационная страница с текущими настройками PHP.

Реализация CGI

Эта реализация нужна для CGI-приложений.

fcgiwrap

Установите fcgiwrap . Файл настроек находится в /usr/lib/systemd/system/fcgiwrap.socket . Включите и запустите fcgiwrap.socket .

Несколько рабочих потоков

Если вы хотите породить несколько рабочих потоков, вам рекомендуется использовать multiwatch AUR , который умеет отслеживать упавшие подпроцессы и перезапускать их. Вам нужно использовать spawn-fcgi , чтобы создать доменный сокет Unix, так как multiwatch не может обрабатывать сокеты, созданные systemd, однако, fcgiwrap сама по себе не вызывает никаких проблем, если вызывается непосредственно из юнит-файла.

Скопируйте юнит-файл из /usr/lib/systemd/system/fcgiwrap.service в /etc/systemd/system/fcgiwrap.service (и юнит fcgiwrap.socket , если он есть), и отредактируйте строку ExecStart в соответствии с вашими нуждами. В примере показан юнит файл, который использует multiwatch AUR . Убедитесь, что fcgiwrap.socket не включен и не запущен, потому что он будет конфликтовать с этим юнитом:

Выберите подходящий -f 10 , чтобы изменить количество порождаемых подпроцессов.

Важно: Строка ExecStartPost требуется из-за странного поведения, которое я наблюдаю при использовании опции -M 660 для spawn-fcgi . Устанавливается неправильный режим. Может это баг?

Настройка nginx

Внутри каждого блока server CGI-приложения должен находиться вложенный блок location :

Стандартным сокетом для fcgiwrap является /run/fcgiwrap.sock .

Установка в chroot

Установка nginx в chroot добавляет дополнительный уровень безопасности. Для максимальной безопасности chroot должен включать только файлы, необходимые для запуска сервера nginx, при этом все файлы должны иметь по возможности максимально ограниченные права доступа. Например, как можно больше файлов должно принадлежать пользователю root, а таким каталогам, как /usr/bin должен быть установлен запрет на чтение и запись.

Существует perl-скрипт для создания chroot-окружения, который доступен в jail.pl gist. Вы можете либо использовать его, либо следовать дальнейшим инструкциям из этой статьи. Скрипт требует прав суперпользователя для работы. Вам нужно будет раскомментировать строку, перед тем, как он сможет выполнять какие-либо изменения.

Создание необходимых устройств

Для nginx нужны /dev/null , /dev/random и /dev/urandom . Чтобы установить их в chroot мы создадим каталог /dev и добавим устройства с помощью mknod. Избегайте монтирования всех устройств в /dev : тогда, даже если chroot будет скомпрометирован, атакующий должен будет выбраться из chroot-окружения чтобы добраться до важных устройств, например /dev/sda1 .

Совет: Смотрите mknod(1) и ls -l /dev/ , чтобы лучше понять опции mknod.

Создание необходимых каталогов

Примечание: Если вы используете 64-битное ядро, вам нужно создать символические ссылки для lib64 и usr/lib64 в usr/lib : cd $JAIL; ln -s usr/lib lib64 и cd $JAIL/usr; ln -s lib lib64 .

Затем смонтируйте $JAIL/tmp и $JAIL/run как tmpfs-ы. Размер должен быть ограничен, чтобы быть уверенным, что атакующий не сможет занять всю доступную RAM.

Для того, чтобы монтирование выполнялось автоматически при загрузке системы, добавьте следующие записи в /etc/fstab :

Заполнение chroot

Сначала скопируйте простые файлы.

Теперь скопируйте нужные библиотеки. Используйте ldd, чтобы отобразить их и скопируйте все файлы в правильное место. Копирование предпочтительнее, чем создание жестких ссылок, потому, что даже если атакующий получит права записи в файлы, они не смогут уничтожить или изменить системные файлы вне chroot-окружения.

Для файлов, находящихся в /usr/lib , вы можете воспользоваться следующей командой:

Примечание: Не пытайтесь скопировать linux-vdso.so — это не настоящая библиотека и ее не существует в /usr/lib . Аналогично ld-linux-x86-64.so также будет отображена в /lib64 для 64-битной системы.

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

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

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

Если ваш сервер будет принимать входящие соединения на 80 порту (или любому другому порту в диапазоне 651), дайте исполнителю chroot права на соединение с этими портами без необходимости прав суперпользователя.

Отредактируйте nginx.service для запуска chroot

Перед редактированием юнит-файла nginx.service неплохо будет скопировать его в /etc/systemd/system/ , так как там юнит файлы имеют приоритет над теми, что в /usr/lib/systemd/system/ . Это значит, что обновление nginx не перезапишет ваш собственный файл .service.

Примечание: Я не уверен, нужно ли хранить pid-файл в chroot. Примечание: Обновление nginx с помощью pacman не обновит установленную в chroot копию. Вы должны вручную выполнять обновления, повторяя указанные выше шаги по переносу файлов. Не забудьте также обновить библиотеки, которые использует nginx.

Теперь вы можете спокойно удалить установленный вне chroot nginx.

Решение проблем

Валидация конфигурации

При доступе с локального IP перенаправляется на localhost

По умолчанию, nginx перенаправляет любые запросы на указанное в опции server_name имя.

Это из-за того, что сервер FastCGI не запущен или используемый сокет имеет неправильные права доступа.

В Archlinux, файлом настройки, упомянутом по ссылке выше, является /etc/php/php-fpm.conf .

При определённых обстоятельствах, fcgiwrap.socket может не запуститься правильно и создать бесполезный сокет юникс домена /run/fcgiwrap.sock .

Попробуйте остановить службу fcgiwrap.socket и удалить файл доменного юникс сокета по умолчанию.

Затем запустите fcgiwrap.service вместо него. Проверьте статус fcgiwrap.service и нового доменного юникс сокета /run/fcgiwrap.sock :

Если это сработало, отключите fcgiwrap.socket и включите fcgiwrap.service .

Ошибка: No input file specified

1. Скорее всего у вас не установлена переменная SCRIPT_FILENAME , содержащая полный путь до ваших скриптов. Если конфигурация nginx ( fastcgi_param SCRIPT_FILENAME ) правильная, то эта ошибка означает, что php не смог загрузить запрашиваемый скрипт. Часто это просто оказывается ошибкой прав доступа, и вы можете запустить php-cgi с правами root:

или вам следует создать группу и пользователя для запуска php-cgi:

2. Другой причиной может быть то, что задан неправильный аргумент root в секции location

\.php$ в nginx.conf . Убедитесь, что root указывает на ту же директорию, что и в location / на том же сервере. Либо вы можете просто задать абсолютный путь до корневого каталога, не определяя его в каких-либо location секциях.

3. Убедитесь, что переменная open_basedir в /etc/php/php.ini также содержит путь, который соответствует аргументу root в nginx.conf .

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

Ошибка: "File not found" в браузере или "Primary script unknown" в лог-файле

Убедитесь, что вы определили root и index в ваших директивах server или location :

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

Ошибка: chroot: '/usr/sbin/nginx' No such file or directory

Если у вас возникает эта ошибка при запуске демона nginx в chroot, скорее всего, это происходит из-за отсутствующих 64-битных библиотек в изолированном окружении.

Сначала создайте каталоги:

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

Альтернативный скрипт для systemd

На чистой systemd вы можете получить преимущества при использовании связки chroot и systemd [1]. На основе заданных пользователя и группы и pid:

Нет необходимости задавать расположение по умолчанию, nginx по умолчанию загружает -c /etc/nginx/nginx.conf , хотя вообще это хорошая идея.

Также можно запускать только ExecStart как chroot с параметром RootDirectoryStartOnly заданным как yes man systemd service или запустить его до точки монтирования в качестве эффективного или пути systemd.

Включите nginx.path и замените WantedBy=default.target на WantedBy=nginx.path in /etc/systemd/system/nginx.service .

Ссылка PIDFile в файле юнита позволяет systemd следить за процессом (необходим абсолютный путь). Если это нежелательно, вы можете изменить тип one-shoot по умолчанию и удалить ссылку из файла юнита.

В этом руководстве даётся начальное введение в 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.

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

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

Во-первых, создайте каталог /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 должна выглядеть следующим образом:

Чтобы применить новую конфигурацию, запустите 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 , который на данный момент отображает запросы с префиксом /images/ на файлы из каталога /data/images так, чтобы он подходил для запросов изображений с типичными расширениями файлов. Изменённый блок location выглядит следующим образом:

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

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

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

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

Этот сервер будет фильтровать запросы, оканчивающиеся на .jpg , .jpg или .jpg , и отображать их на каталог /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 использовал серверы Apache для нужд компании Рамблер. Сысоев пытался оптимизировать Apache под запросы крупных и быстро растущих сайтов, например, создал патч, сжимающий (регулирующий) ответы сервера. В большинстве случаев устранить недостатки Apache не удавалось, поэтому началась работа над Nginx.

В чем была проблема с Apache? Apache создает отдельные треды (thread) для каждого события, поэтому не подходит для решения проблемы С10К. При обработке большого количества соединений, веб-сервер начинает перегружать вычислительные мощности, что приводит к нарушениям в работе. В свою очередь, Nginx использует неблокирующие асинхронные алгоритмы обработки событий и стабильно справляется с обработкой более 10 000 рабочих процессов одновременно. Поэтому построенные на Nginx проекты куда меньше страдают от вызванных перегрузкой проблем, чем аналогичные решения на Apache.

Apache и Nginx: наглядное сравнение

Чтобы более подробно рассмотреть разницу между Apache и Nginx проведем тестирование скорости работы серверов при решении нескольких типовых задач.

Утилита ab имеет следующий синтаксис:

Из опций как правило указываются количество конкурентных запросов (потоков) -с и общее количество запросов -n, например:

- 100 общих запросов в 10 потоков.

С помощью Apache Benchmark были проведены сравнительные тесты быстродействия веб-сервера Apache и связки Nginx+PHP-FPM для трёх различных скриптов:

1. index.html - статичная веб-страница:

2. Простой php-скрипт phpinfo.php, выводящий информацию о настройках php на сервере:

3. “Тяжелый” php-скрипт speedtest.php, который исполняет алгоритм наивного поиска простых чисел, дополнительно усложненный алгоритмом работы через комплексные числа для искусственного увеличения нагрузки на вычислительные мощности сервера:

Результаты тестов представлены в таблице в формате количество запросов в секунду / время на обработку одного запроса:

Файл	Nginx	Apache
index.html	4373.21 / 45.733 мс	3582.10 / 55.833 мс
phpinfo.php	3424.28 / 58.406 мс	1253.39 / 79.784 мс
speedtest.php	0.19 / 8925.181 мс	0.25 / 7863.261 мс

Разница в скорости обработки запросов клиента связана с архитектурой веб-серверов. Apache для каждого нового соединения запускает отдельный процесс (thread), в то время когда Nginx обрабатывает новое соединение как событие (event) внутри уже запущенного рабочего процесса (worker). Также, разница объясняется тем, что Nginx при обработке php-скриптов пересылает их к серверу РHP-FPM, что также занимает определенное время, в то время, как Apache обрабатывает динамический контент самостоятельно. В итоге, Nginx намного лучше справляется со статичным контентом и простыми скриптами, а то время, как Apache быстрее обрабатывает ресурсоемкие скрипты, где философия "один клиент - один процесс" позволяет добиться лучшей производительности.

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

Первым делом установим пакет nginx из репозитория :

Чтобы проверить работоспособность сервера следует перейти по его IP-адресу. На экране должна появиться приветственная страница Nginx.

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

Настройка Nginx

Главный конфигурационный файл Nginx, находится по адресу /etc/nginx/nginx.conf. Его полное содержание должно выглядеть примерно следующим образом:

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

worker_processes отвечает за количество рабочих процессов. В новых версиях желательно установить для неё значение auto для автоматического определения оптимального количества.

worker_connections устанавливает максимальное количество одновременно возможных соединений. Их число можно приблизительно рассчитать по формуле 1 / <время выполнения задачи, cек.>. Как правило, стандартное значение 1024 является оптимальным и редактируется уже по результатам анализа нагрузки на сервер.

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

sendfile включает метод отправки данных sendfile, более эффективный чем стандартный.

Настройки кеширования

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

open_file_cache отвечает за максимальное количество файлов, которые могут хранится в кеше(при переполнении кеша удаляются минимально востребованные элементы) и задаёт временной промежуток, по истечение которого файл удаляется если к нему не было обращений, по умолчанию 60 секунд.

open_file_cache_valid регулирует период проверки информации о файле в кеше – оптимально стоит устанавливать несколько большее значение, чем в параметре inactive директивы open_file_cache max , чтобы после каждой проверки гарантированно удалялись все неиспользуемые файлы.

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

open_file_cache_errors запрещает или разрешает кеширование ошибок поиска файлов.

Сжатие

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

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

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

Применение изменений

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

Настройка виртуальных хостов

Файлы настроек виртуальных хостов находятся в папке /etc/nginx/sites-available. Изначально там находится файл стандартных настроек default, обеспечивающий работу сервера “из коробки”:

Для создания нового виртуального хоста скопируем файл default в ту же папку и переименуем его в example:

Подключение виртуального хоста

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

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

Директива listen определяет адрес и порт для IP или путь для UNIX-сокета, на которых сервер будет принимать запросы:

Можно указать адрес и порт, либо только адрес или только порт. Так же у директивы есть параметр default_server (до версии 0.8.1 назывался просто default), который позволяет сделать виртуальный хост сайтом по умолчанию. В таком случае на него будут перенаправлятся все запросы, не относящеся к другим виртуальным хостам или поступающие напрямую на IP-адрес сервера. По умолчанию эта опция включена в настройках стандартного хоста default, поэтому чтобы избежать ошибки (сервер по умолчанию должен быть только один) нужно удалить этот параметр из файла настроек default или отключить стандартно сконфигурированный сервер, удалив ссылку на него из папки sites-enabled. Все параметры директивы являются опциональными.

Директива root отвечает за корневой каталог сайта, создадим для тестового хоста example отдельный каталог командой:

И установим его в качестве корневого, изменив значение директивы в файле настроек:

Директива index определяет файлы, которые nginx будет искать в корневом каталоге сайта и использовать в качестве индекса, в неё нужно добавить значение index.php :

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

Директива server_name устанавливает доменное имя сайта:

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

и добавить следующее условие:

В конце для завершения настройки и применения новых параметров попросим Nginx перечитать файл конфигурации:

Проверка работы домена и субдоменов

для перенаправления с основного домена и строки

для демонстрации доступа с нескольких субдоменов. Механизм работы файла hosts не поддерживает маски, поэтому все субдомены, с которыми планируется работа необходимо перечислить в файле построчно.

Если же вы использовали не тестовый, а реально существующий домен – пропускайте этот пункт и настраивайте DNS-записи у регистратора домена.

2. Создадим в корневой директории сайта файл индекса index.html для главного домена:

и папку first, в которую положим файл индекса для субдомена:

Настройка PHP-FPM

Изначально nginx не способен исполнять динамические файлы - если в папку стандартно сконфигурированного виртуального хоста положить файл с расширением .php и попытаться получить к нему доступ по адресу //localhost/myfile.php то начнется его скачивание, а исполнение будет невозможно. Для того чтобы файлы с динамическим содержимым корректно выполнялись к Nginx нужно подключить бэкенд-обработчик php-fpm.

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

Сервис запустится автоматически в конце установки.

Для подключения обработчика php к настроенному нами виртуальному хосту раскомментируем в файле настроек example относящиеся к php-fpm строки и удалим лишние, приведя блок location

\.php$ к следующему виду:

Перезапустим веб-сервер для применения новых настроек:

После этого для теста работы php можно создать файл phpinfo.php следующего содержания:

и поместить его в корневые каталоги хоста example и стандартного хоста default (корневой каталог которого по умолчанию /usr/share/nginx/html) чтобы сравнить результаты.

На default хосте при попытке открыть phpinfo.php начинается скачивание файла:

В то время, как на хосте example с правильно подключенным php-fpm файл корректно выполнится:

Установка MySQL

Сервер баз данных MySQL устанавливается командой

В процессе установки необходимо указать пароль root пользователя MySQL

На все вопросы при установке отвечаем утвердительно.

После этого устанавливается phpmyadmin командой:

При установке будет предложено выбрать веб-сервер, с которым будет работать MySQL, опции Nginx по умолчанию нет, потому в этом меню нужно нажать клавишу TAB и кнопку OK без выбора какой-либо опции в списке.

На всплывающий вопрос о том, хотим ли мы использовать стандартный конфиг dbconfig-common отвечаем утвердительно, вводим придуманный ранее пароль для root пользователя MySQL.

По завершении установки создадим ссылку в корневом каталоге ранее настроенного виртуального хоста example для того чтобы веб-сервер мог корректно найти файлы phpmyadmin и работать с ними:

Далее следует включить модуль mcrypt который нужен для работы phpmyadmin и перезапустить PHP-FPM командами:

Сервер MySQL успешно установлен, phpmyadmin доступен по адресу виртуального хоста example.

Если phpmyadmin нужно подключить ещё к какому-либо виртуальному хосту нужно создать ещё одну ссылку на файлы phpmyadmin в том каталоге, который прописан в строке root файла настроек виртуального хоста - в том каталоге, где лежат файлы этого хоста, например, это каталог /usr/share/nginx/html для стандартно сконфигурированного виртуального хоста default. Для работы phpmyadmin к виртуальному хосту обязательно нужно подключить PHP-FPM или любой другой backend-сервер.

После этого можно перейти по адресу сконфигурированного виртуального хоста и найти страницу логина phpmyadmin по адресу <адрес_хоста>/phpmyadmin/

Перевод правил mod_rewrite в конфигурацию Nginx

rewrite регулярное_выражение замена [флаг] - основная директива модуля, если URL запроса соответствует указанному регулярному выражению, то он изменяется в соответствие со строкой замены. Флаг имеет несколько значений (возможно указать несколько флагов одновременно), наиболее используемое из которых last - после замены вся обработка текущего URL завершается, после чего ищется новый блок location , под который попадает измененный URL;
if (условие) < . >- обыкновенный условный оператор, позволяющий создавать ветвление в правилах замены;
break и return - используются для прерывания обработки текущего запроса, директива return позволяет вернуть клиенту код ошибки или URL.

Указанные директивы могут использоваться как в главном конфигурационном файле nginx.conf для влияния на все запросы ко всем виртуальным хостам, так и в файлах настроек отдельных хостов. Они могут устанавливаться в блоках server для указания каких-то общих правил замены, либо в блоках location для обработки только конкретных URL по заданной маске.

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

Заключение

Пакет LNMP установлен и готов к работе. Далее могут следовать этапы более тонкой настройки всего веб-сервера и виртуальных хостов под конкретные задачи, установка cms, организация защиты сайта и базы данных от несанкционированного проникновения настройка файлового хранилища или почтового сервера и множество других интересных задач. Более подробная информация по настройке доступна в официальной документации Nginx и MySQL.

Школа хостинга Редактор: Дмитрий Сокол 422 30 мин Аудио

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

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

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

Установка Nginx

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

$ sudo apt update

$ sudo apt install nginx

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

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

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

Mozilla SSL Configuration Generator

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

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

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

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

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

Запустить снова процесс работы 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

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

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

Затем добавьте секцию 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Выводы

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

Читайте также: