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

Nginx — популярный быстрый веб-сервер, который помогает связать воедино компоненты приложения: файлы HTML, CSS и JavaScript, бэкенд одного или сразу нескольких сервисов. Он также используется для распределения нагрузки, кеширования HTTP и обратного проксирования.

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

1. Основные команды управления

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

Синтаксис простой:

nginx -s <сигнал>

Каким может быть сигнал:

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

Важно: команды выполняются под тем же пользователем, который запустил nginx.

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

nginx -s quit

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

nginx -s reload

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

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

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

Посмотреть ошибки можно в логах. Файлы access.log и error.log находятся в каталоге /usr/local/nginx/logs или /var/log/nginx.

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

nginx -T

Эта команда также выводит полную конфигурацию на экран. Удобно, если много вложенных блоков и нужно еще раз их проверить.

Подробнее о командах управления nginx читайте в документации.

Nginx воспринимает и сигналы, отправленные средствами Unix. Их можно направлять отдельным процессам по их идентификатору (ID). ID главного процесса по умолчанию прописывается в файле nginx.pid. Найти его можно в каталоге /usr/local/nginx/logs или /var/run.

Посмотреть список всех запущенных процессов nginx можно утилитой ps:

ps -ax | grep nginx

Для примера плавно завершим главный процесс с ID 1567, используя UNIX-утилиту kill:

kill -s QUIT 1567

Синтаксис сохраняется: мы также используем параметр -s, чтобы передать процессу сигнал о плавном завершении работы — QUIT.

Обратите внимание на курсы разработчиков от наших партнеров школы Robot Dreams и Mate Academy. Это идеальное начало вашего пути в IT.

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

У nginx — модульная структура. Каждый модуль настраивается директивами, которые указываются в файле nginx config.

Директивы бывают простыми и блочными.

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

Если у блочной директивы внутри фигурных скобок размещены другие директивы, то она становится контекстом. Примеры — events, http, server и location.

Есть основной контекст — main. Директивы, которые не помещены в другой контекст, считаются помещенными в контекст main. Например, это events и http. Директива server находится в контексте http, а location — в контексте server.

Вот простой пример конфигурации, который демонстрирует вложенность контекстов:

events {
  worker_connections  4096;  ## Default: 1024
}
http {
  server { # php/fastcgi
    listen       80;
    server_name  domain.com www.domain.com;
    access_log   logs/domain.access.log  main;
    root         html;
    location ~ \.php$ {
      fastcgi_pass   127.0.0.1:1025;
    }
  }
}

Как видите, в конфигурационном файле также можно оставлять комментарии. Для этого используется символ #.

3. Раздача статического контента

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

В качестве примера возьмем две папки: /data/www для хранения статических файлов и /data/images для хранения изображений. Создайте эти каталоги и положите в них несколько файлов. Например, пусть в /data/www будет файл main.html с любым содержимым, а в /data/images — изображения в разных форматах: gif, jpg, png.

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

Вот пример:

http {
server {
    location / {
        root /data/www;
    }

    location /images/ {
        root /data;
    }
}
    }

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

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

Директива server должна находиться в контексте http. Поэтому начинается все с такой конструкции:

http {
    server {
    }
}

Блоков server может быть несколько — ниже мы рассмотрим и такие примеры. В данном случае хватит одного. Внутри него расположены две директивы location с условиями перенаправления запроса и адресами каталогов. Вот они:

location / {
    root /data/www;
}
location /images/ {
    root /data;
}

Обратите внимание на параметры директив. В первом случае это префикс /, во втором — /images/. Это и есть условия перенаправления запроса.

• Nginx получает запрос.
• Сравнивает URI из запроса с имеющимися префиксами в location.
• Если есть совпадение, перенаправляет в указанный каталог.

Если nginx обнаруживает совпадение с несколькими блоками location, то выбирает тот, у кого самый длинный совпадающий префикс. Например, / — самый короткий возможный префикс. Он будет выбран только тогда, когда нет совпадений с другими префиксами.

Еще раз посмотрим на конфигурацию nginx для раздачи статического контента:

http {
server {
    location / {
        root /data/www;
    }

    location /images/ {
        root /data;
    }
}
    }

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

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

nginx -s reload

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

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

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

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

server {
    listen 8080;
    root /data/up;

    location / {
    }
}

В этой конфигурации мы указали сервер, который слушает запросы через порт 8080 и обрабатывает запросы к каталогу /data/up. В этом каталоге размещены файлы — например, главная страница, main.html.

Теперь нужно настроить сервер, который будет выполнять функции прокси. Для этого используется директива proxy_pass:

server {
    location / {
        proxy_pass http://localhost:8080/;
    }

    location ~ \.(gif|jpg|png)$ {
        root /data/images;
    }
}

Директива proxy_pass в качестве параметров получает протокол, имя и порт проксируемого сервера.

Обратите внимание на вторую директиву location. В качестве параметров мы передали ей примеры расширений файлов изображений. Сделано это с помощью регулярного выражения. Все подходящие запросы будут направляться в локальный каталог /data/images.

Директивы location обрабатываются по одному сценарию, который мы обсуждали выше. Сначала nginx проверяет префиксы блоков location. Он запоминает директиву с самым длинным подходящим префиксом. Затем nginx проверяет регулярные выражения. Если обнаружено совпадение, то выбирается соответствующий location. Если совпадения нет, запрос идет на location, который nginx запомнил ранее.

Например, пользователь запрашивает изображение /image.jpg. Nginx отправит запрос в каталог /data/images. Когда пользователь запросит файл /main.html, веб-сервер прокси-сервер направит его на проксируемый сервер с адресом http://localhost:8080/.

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

nginx -s reload

5. Перенаправление на FastCGI-сервер

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

Например, у нас есть FastCGI-сервер с приложением на PHP. Укажем это в конфигурации nginx. Для этого в location нужно использовать две директивы: fastcgi_pass и fastcgi_param.

server {
    location / {
        fastcgi_pass  localhost:9000;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_param QUERY_STRING    $query_string;
    }

    location ~ \.(gif|jpg|png)$ {
        root /data/images;
    }
}

Здесь все просто:

• в директиве fastcgi_pass указан адрес FastCGI-сервера — localhost:9090.
• Директива fastcgi_param с параметром SCRIPT_FILENAME определяет имя скрипта.
• Директива fastcgi_param с параметром QUERY_STRING определяет параметры запроса.

При такой конфигурации все запросы, кроме запросов изображений, будут перенаправляться на localhost:9090, где размещен FastCGI-сервер с приложением на PHP.

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

nginx -s reload

6. Преимущества nginx

Чаще всего nginx сравнивают с Apache. Однако это не всегда корректное сравнение. Опытные разработчики не выбирают что-то одно для всех своих проектов, а смотрят на то, насколько инструмент подходит для решения конкретной задачи. Но для этого надо знать его достоинства и недостатки.

Плюсы nginx:

1. Высокая скорость обработки статического контента — до двух раз быстрее по сравнению с Apache. При работе с динамическим контентом производительность у обоих веб-серверов примерно одинаковая.
2. Меньшая требовательность к объему оперативной памяти.
3. Хорошая масштабируемость.
4. Высокий уровень безопасности за счет отказа от динамического подключения модулей.

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

Nginx и Apache можно использовать в связке. Например, nginx разворачивают перед Apache для выполнения функций реверс-прокси. Он обрабатывает статический контент, а если требуется, допустим, выполнение PHP-сценария, к работе присоединяется Apache. Результаты работы Apache передается сначала на nginx, а затем — конечному пользователю.

Заключение

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

Узнать больше о том, как работает nginx, как он парсит конфиги, выбирает server, location и выдает нужный вам сайт — поможет это видео: