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

• Запуск, остановка и перезагрузка конфигурации
• Структура файла конфигурации
• Обработка статического контента
• Настройка простого прокси-сервера
• Настройка проксирования FastCGI

Данное руководство предоставляет базовое введение в 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. Используйте следующий синтаксис:

nginx -s signal

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

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

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

nginx -s quit

Эта команда должна быть выполнена пользователем, который запустил nginx.

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

nginx -s reload

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

Сигнал также может быть отправлен процессам nginx с помощью утилит Unix, таких как утилита kill. В этом случае сигнал отправляется напрямую процессу с заданным идентификатором процесса. Идентификатор процесса мастер-процесса nginx по умолчанию записывается в nginx.pid в каталоге /usr/local/nginx/logs или /var/run. Например, если идентификатор мастер-процесса равен 1628, для отправки сигнала QUIT, вызывающего плавную остановку nginx, выполните:

kill -s QUIT 1628

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

ps -ax | grep nginx

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

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

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

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

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

Обработка статического контента

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

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

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

http {
    server {
    }
}

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

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

location / {
    root /data/www;
}

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

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

location /images/ {
    root /data;
}

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

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

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

    location /images/ {
        root /data;
    }
}

Это уже рабочая конфигурация сервера, который прослушивает стандартный порт 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 nginx отправит файл /data/www/some/example.html .

Для применения новой конфигурации, запустите nginx, если он ещё не запущен, или отправьте сигнал reload мастер-процессу nginx, выполнив:

nginx -s reload

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

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

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

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

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

server {
    listen 8080;
    root /data/up1;

    location / {
    }
}

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

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

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

    location /images/ {
        root /data;
    }
}

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

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

Параметр представляет собой регулярное выражение, сопоставляющее все URI, заканчивающиеся на .gif, .jpg, или .png. Регулярное выражение должно начинаться с ~. Соответствующие запросы будут сопоставлены с каталогом /data/images.

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

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

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

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

Этот сервер будет фильтровать запросы, заканчивающиеся на .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 используется для передачи параметров запроса. Результирующая конфигурация будет:

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;
    }
}

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