Руководство для начинающих по nginx
Nginx — популярный быстрый веб-сервер, который помогает связать воедино компоненты приложения: файлы HTML, CSS и JavaScript, бэкенд одного или сразу нескольких сервисов. Он также используется для распределения нагрузки, кеширования HTTP и обратного проксирования.
Nginx везде настраивается одинаково. Поэтому не будем привязываться к конкретному дистрибутиву. Если вы еще не установили веб-сервер, перед чтением описания базовых настроек сделайте это по туториалу из официальной документации nginx.
1. Основные команды управления
Для запуска nginx нужно выполнить одноименный исполняемый файл. Управлять состоянием веб-сервера можно с помощью сигналов, указанных после параметра -s .
Синтаксис простой:
Каким может быть сигнал:
- stop — моментальное завершение.
- quit — постепенное завершение.
- reload — перезапуск конфигурационного файла.
- reopen — повторное открытие файлов с логами.
Важно: команды выполняются под тем же пользователем, который запустил nginx.
Например, вы хотите плавно завершить работу веб-сервера, чтобы процессы успели обработать все текущие запросы. Для этого нужно выполнить команду:
Другая ситуация: вы изменили конфигурацию веб-сервера и хотите применить изменения. Для этого не нужно его останавливать и запускать заново. Все гораздо проще — отправьте сигнал для перезагрузки:
После получения сигнала о перезапуске главный процесс смотрит, все ли в порядке с синтаксисом в измененном файле конфигурации. Если ошибок нет и конфигурацию удается применить, то главный процесс запускает новые рабочие процессы. Старые процессы получают сообщения о том, что им необходимо плавно завершиться.
Ключевой момент в перезапуске — плавность. Старые процессы не обрываются сразу после получения сообщений от главного процесса. Они продолжают обрабатывать текущие запросы, но больше не принимают новые. Когда все текущие запросы обслужены, старые рабочие процессы завершаются.
Если же при проверке конфигурационного файла главный процесс nginx обнаруживает ошибки, то он откатывает изменения и продолжает работать по старым правилам.
Посмотреть ошибки можно в логах. Файлы access.log и error.log находятся в каталоге /usr/local/nginx/logs или /var/log/nginx .
Протестировать конфигурацию можно командой:
Эта команда также выводит полную конфигурацию на экран. Удобно, если много вложенных блоков и нужно еще раз их проверить.
Подробнее о командах управления nginx читайте в документации.
Nginx воспринимает и сигналы, отправленные средствами Unix. Их можно направлять отдельным процессам по их идентификатору (ID). ID главного процесса по умолчанию прописывается в файле nginx.pid . Найти его можно в каталоге /usr/local/nginx/logs или /var/run .
Посмотреть список всех запущенных процессов nginx можно утилитой ps :
Для примера плавно завершим главный процесс с ID 1567, используя UNIX-утилиту kill :
Синтаксис сохраняется: мы также используем параметр -s , чтобы передать процессу сигнал о плавном завершении работы — QUIT .
2. Структура конфигурационного файла
У nginx — модульная структура. Каждый модуль настраивается директивами, которые указываются в файле nginx config.
Директивы бывают простыми и блочными.
- Простая директива — имя и параметры, разделенные пробелами, заканчивается точкой с запятой.
- Блочная директива — устроена так же, как простая, но после имени и параметров указываются фигурные скобки, внутри которых размещены дополнительные инструкции.
Если у блочной директивы внутри фигурных скобок размещены другие директивы, то она становится контекстом. Примеры — events , http , server и location .
Есть основной контекст — main . Директивы, которые не помещены в другой контекст, считаются помещенными в контекст main. Например, это events и http . Директива server находится в контексте http , а location — в контексте server .
Вот простой пример конфигурации, который демонстрирует вложенность контекстов:
Как видите, в конфигурационном файле также можно оставлять комментарии. Для этого используется символ # .
3. Раздача статического контента
С помощью nginx раздают статические файлы и изображения. Обычно они хранятся в разных папках. Это нужно отражать и в конфигурации, чтобы в зависимости от запроса веб-сервер знал, в какой каталог идти за запрошенным файлом.
В качестве примера возьмем две папки: /data/www для хранения статических файлов и /data/images для хранения изображений. Создайте эти каталоги и положите в них несколько файлов. Например, пусть в /data/www будет файл main.html с любым содержимым, а в /data/images — изображения в разных форматах: gif, jpg, png.
Конфигурация должна получиться очень простой: контекст http, внутри него — один server , в котором размещены две директивы location с нашими папками.
Как мы собрали такую конфигурацию и что здесь вообще происходит? Давайте разбираться с самого начала.
Когда вы откроете файл конфигурации nginx, то увидите несколько примеров использования директивы server . Можно отредактировать один из имеющихся блоков, но в обучающих целях лучше их закомментировать и написать конфигурацию с нуля.
Директива server должна находиться в контексте http . Поэтому начинается все с такой конструкции:
Блоков server может быть несколько — ниже мы рассмотрим и такие примеры. В данном случае хватит одного. Внутри него расположены две директивы location с условиями перенаправления запроса и адресами каталогов. Вот они:
Обратите внимание на параметры директив. В первом случае это префикс / , во втором — /images/ . Это и есть условия перенаправления запроса.
- Nginx получает запрос.
- Сравнивает URI из запроса с имеющимися префиксами в location .
- Если есть совпадение, перенаправляет в указанный каталог.
Если nginx обнаруживает совпадение с несколькими блоками location , то выбирает тот, у кого самый длинный совпадающий префикс. Например, / — самый короткий возможный префикс. Он будет выбран только тогда, когда нет совпадений с другими префиксами.
Еще раз посмотрим на конфигурацию nginx для раздачи статического контента:
В этих нескольких строках — работающий сервер, который доступен на локальной машине через порт 80. Он умеет принимать запросы и отправлять файлы в зависимости от URI. Например, когда пользователь запрашивает http://localhost/images/example.png , сервер идет в каталог data/images/ и возвращает файл example.png . Если такого файла нет, то возвращается ответ с ошибкой 404.
Чтобы применить конфигурацию, выполните перезагрузку nginx :
4. Настройка прокси-сервера
Еще одна распространенная ситуация — использование nginx в качестве прокси-сервера. Он принимает запросы от клиентов, передает их другим серверам, получает ответы и возвращает их пользователям.
В этом примере настроим прокси-сервер, который будет отдавать изображения из локального каталога, а остальные запросы пересылать на проксируемый сервер.
Чтобы создать проксируемый сервер, нужно добавить в файл конфигурации еще одну директиву server :
В этой конфигурации мы указали сервер, который слушает запросы через порт 8080 и обрабатывает запросы к каталогу /data/up . В этом каталоге размещены файлы — например, главная страница, main.html .
Теперь нужно настроить сервер, который будет выполнять функции прокси. Для этого используется директива proxy_pass :
Директива proxy_pass в качестве параметров получает протокол, имя и порт проксируемого сервера.
Обратите внимание на вторую директиву location . В качестве параметров мы передали ей примеры расширений файлов изображений. Сделано это с помощью регулярного выражения. Все подходящие запросы будут направляться в локальный каталог /data/images .
Директивы location обрабатываются по одному сценарию, который мы обсуждали выше. Сначала nginx проверяет префиксы блоков location . Он запоминает директиву с самым длинным подходящим префиксом. Затем nginx проверяет регулярные выражения. Если обнаружено совпадение, то выбирается соответствующий location . Если совпадения нет, запрос идет на location , который nginx запомнил ранее.
Например, пользователь запрашивает изображение /image.jpg . Nginx отправит запрос в каталог /data/images . Когда пользователь запросит файл /main.html , веб-сервер прокси-сервер направит его на проксируемый сервер с адресом http://localhost:8080/ .
Чтобы применить конфигурацию, выполните перезагрузку nginx :
5. Перенаправление на FastCGI-сервер
Веб-сервер nginx умеет перенаправлять запросы на FastCGI-серверы, на которых исполняются приложения, написанные на фреймворках и языках программирования.
Например, у нас есть FastCGI-сервер с приложением на PHP. Укажем это в конфигурации nginx . Для этого в location нужно использовать две директивы: fastcgi_pass и fastcgi_param .
Здесь все просто:
- в директиве fastcgi_pass указан адрес FastCGI-сервера — localhost:9090 .
- Директива fastcgi_param с параметром SCRIPT_FILENAME определяет имя скрипта.
- Директива fastcgi_param с параметром QUERY_STRING определяет параметры запроса.
При такой конфигурации все запросы, кроме запросов изображений, будут перенаправляться на localhost:9090 , где размещен FastCGI-сервер с приложением на PHP.
Чтобы применить конфигурацию, выполните перезагрузку nginx :
6. Преимущества nginx
Чаще всего nginx сравнивают с Apache. Однако это не всегда корректное сравнение. Опытные разработчики не выбирают что-то одно для всех своих проектов, а смотрят на то, насколько инструмент подходит для решения конкретной задачи. Но для этого надо знать его достоинства и недостатки.
Плюсы nginx:
- Высокая скорость обработки статического контента — до двух раз быстрее по сравнению с Apache. При работе с динамическим контентом производительность у обоих веб-серверов примерно одинаковая.
- Меньшая требовательность к объему оперативной памяти.
- Хорошая масштабируемость.
- Высокий уровень безопасности за счет отказа от динамического подключения модулей.
Некоторые плюсы оборачиваются минусами. Например, из-за отказа от динамического подключения модулей шифрование, проксирование и другие дополнительные функции приходится настраивать вручную. Еще один недостаток — слабая совместимость с Windows. Nginx изначально разработан для UNIX-систем, в другой среде он не показывает максимальную производительность.
Nginx и Apache можно использовать в связке. Например, nginx разворачивают перед Apache для выполнения функций реверс-прокси. Он обрабатывает статический контент, а если требуется, допустим, выполнение PHP-сценария, к работе присоединяется Apache. Результаты работы Apache передается сначала на nginx , а затем — конечному пользователю.
Заключение
Мы разобрались с основами nginx , научились собирать простую конфигурацию и управлять состоянием веб-сервера.
Узнать больше о том, как работает nginx, как он парсит конфиги, выбирает server , location и выдает нужный вам сайт — поможет это видео:
Nginx proxy pass, настройка проксирования запросов в nginx
Средствами Nginx можно настроить различные серверные конфигурации, часто возникает необходимость организовать проксирование, т.е. перенаправление запросов с одного адреса на другой, доменное имя в адресной строке браузера при этом должно оставаться прежним. В Nginx proxy pass является основной директивой, нужной для проксирования всегда, дополнительный функционал реализуется за счет других правил, прописывающихся в том же файле.
Настройка проксирования запросов в nginx с использованием директивы Nginx proxy pass
В примере рассматривается настройка проксирования запросов с subdomain.example.com на https://subdomain.example.ru/suf
На сервере, на котором настраивалось проксирование применяется Apache в качестве бэкенд сервера и Nginx в качестве фронтенд сервера. Проксирование реализовано на уровне фронтенда, т.е. до Apache запросы не доходят.
Содержание конфигурационного файла:
server <
server_name subdomain.example.com;
listen *:80;
proxy_read_timeout 200s;
access_log off;
include static.conf;
location / <
root /var/www/sites/subdomain.example.com;
proxy_pass https://subdomain.example.ru/suf;
proxy_set_header X-Forwarded-Host subdomain.example.com:80;
proxy_set_header X-Forwarded-Server subdomain.example.com;
proxy_set_header X-Forwarded-For https://subdomain.example.ru/suf;
static.conf здесь — отдельный файл в котором заданы настройки кэширования, также они могут задаваться в любом другом конфиге.
За счет приведенных ниже директив реализуется реверсивное проксирование запросов, это аналог ProxyPassReverse в Apache:
proxy_set_header X-Forwarded-Host subdomain.example.com:80;
proxy_set_header X-Forwarded-Server subdomain.example.com;
proxy_set_header X-Forwarded-For https://subdomain.example.ru/suf;
Добавив конфиг активируем его обычным способом — через создание симлинка
ln -s /etc/nginx/sites-availible/example.com /etc/nginx/sites-enabled
Проверяем конфигурацию веб-сервера
Если ошибок нет — даем команду на перечитывание конфигов
Директива nginx proxy redirect
Схожим образом можно настроить в конфигурационном файле nginx редирект с одного адреса на другой.
Применяя аналогичный конфигурационный файл, но с раскомментированный директивой proxy_redirect можно получить перенаправление, при этом адрес сайта в адресной строке браузера будет подменяться.
Очень часто используется простое проксирование на IP адрес из приватной сети
location / <
root /var/www/sites/example.com;
proxy_pass https://127.0.0.10;
С самой простой реализацией Nginx proxy pass, приведенной выше, запускаются проекты на NodeJS и фреймоворке Express. Изначально они стартуют на localhost и порту 3000
Настройка проксирования на примере связки nginx + Apache
При настройке окружения зачастую используют связку веб-серверов nginx+Apache. Как правило, запросы к статическим страницам nginx обрабатывает и отдает клиенту самостоятельно, а к динамическим — передает веб-серверу Apache, выступающим в качестве backend.
Рассмотрим пример настройки подобного проксирования на ОС Ubuntu.
На стороне nginx
Задача реализуема с помощью модуля ngx_http_proxy_module. Подробно о параметрах проксирования рассказано в документации.
В случае с Ubuntu, путь до конфигурационного файла следующий: /etc/nginx/nginx.conf .
В результате запросы, оканчивающиеся на .gif, .jpg или .png, будут обработаны nginx и направлены в директорию /data/images.
Все остальные запросы будут направлены на проксируемый сервер, который локально слушает порт 8080.
Передача заголовков на проксируемый сервер
При проксировании можно переопределять или добавлять значения заголовков запроса, которые передаются на backend. Если в заголовке — пустая строка, то это поле вообще не будет передаваться проксируемому серверу.
Директивы наследуются с предыдущего уровня при условии, что на данном уровне не описаны свои директивы proxy_set_header .
По умолчанию переопределяются только два поля:
proxy_set_header Host $proxy_host;
proxy_set_header Connection close;
Передаем на backend заголовки Host, IP и Cookie исходного запроса, поступившего на nginx, в неизменном виде:
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_pass_header Cookie;
ВАЖНО! Если включено кеширование, заголовки “If-Modified-Since”, “If-Unmodified-Since”, “If-None-Match”, “If-Match”, “Range” и “If-Range” исходного запроса не передаются на проксируемый сервер.
Кеширование результатов ответа backend
Кеширование позволяет сократить количество направляемых на backend запросов — nginx сохраняет результат обработки запроса веб-сервером Apache и при следующем обращении к той же странице отдаёт именно его.
По умолчанию кешируются только ответы с кодами 200, 301 и 302.
- proxy_cache — определяет, какой кеш использовать;
- proxy_cache_valid — позволяет задать время кеширования для разных кодов ответа;
- proxy_cache_key — используется для конкретных запросов;
Пример конфигурации, при которой все ответы от Apache кешируются на 1 час, а коды 404, 502 и 503 — на 1 минуту:
proxy_cache all;
proxy_cache_valid 404 502 503 1m;
proxy_cache_valid any 1h;
proxy_cache_key «$binary_remote_addr$request_method$uri»;
proxy_cache_valid 30m;
Настройка, при которой запросы одного метода с одного и того же IP к определенной странице будут отдаваться из кеша в течение 30 минут:
proxy_cache_key «$binary_remote_addr$request_method$uri»;
proxy_cache_valid 30m;
Итоговый файл конфигурации, включающий в себя все ранее описанные случаи:
server <
location / <
proxy_pass http://localhost:8080/;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_pass_header Cookie;
proxy_cache_valid 404 502 503 1m;
proxy_cache_valid any 1h;
proxy_cache_key «$binary_remote_addr$request_method$uri»;
proxy_cache_valid 30m;
>
Перед применением изменений желательно убедиться, что файл конфигурации не содержит ошибок, с помощью команды:
После чего, чтобы изменения вступили в силу, перезапустить сервис nginx:
systemctl restart nginx
На стороне Apache
По умолчанию веб-сервер Apache слушает 80-й порт, но в данной ситуации его использует nginx, и для Apache необходимо задать альтернативный порт. Новое значение порта должно совпадать с тем, что задано в конфигурационном файле nginx (в нашем случае это — 8080).
Конфигурационный файл Apache в большинстве случаев находится здесь:
ServerName domain.ru
ServerAlias www.domain.ru
DocumentRoot /var/www/domain.ru
. #другие параметры
Редактировать заголовки запроса/ответа позволяет модуль mod_headers, устанавливаемый при сборке Apache по умолчанию.
Так как ранее в конфигурационный файл nginx мы включили заголовок X-Real-IP, необходимо настроить Apache для обработки этого заголовка, чтобы получить реальное значение IP-адреса посетителя. Для этого используется модуль mod_remoteip. В версиях Apache >2.4 этот модуль присутствует по умолчанию, активировать его можно командой:
Если используется версия Apache ниже 2.4, необходимо установить и активировать модуль mod_rpaf: