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

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

nginx -s сигнал

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

• stop - быстрое завершение
• - переоткрытие лог-файлов

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

nginx -s quit

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

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

nginx -s reload

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

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

kill -s QUIT 1628

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

ps -ax | grep nginx

Дополнительную информацию об отправке сигналов процессам 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 :

http {

Server {

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

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

location / {

Root /data/www;

Этот блок location задаёт “ / ” в качестве префикса, который сравнивается с URI из запроса. Для подходящих запросов добавлением URI к пути, указанному в директиве root , то есть, в данном случае, к /data/www , получается путь к запрашиваемому файлу в локальной файловой системе. Если есть совпадение с несколькими блоками location , nginx выбирает блок с самым длинным префиксом. В блоке 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 в ответ будет отправлен файл /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 выглядит следующим образом:

Root /data/images;

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

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

Nginx – это популярный и производительный веб-сервер и обратный прокси-сервер.

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

Примечание : Руководство выполнено на Ubuntu 12.04.

Иерархия каталогов Nginx

Nginx хранит конфигурационные файлы в каталоге /etc/nginx.

В этом каталоге находится ещё несколько каталогов и модульных конфигурационных файлов.

cd /etc/nginx
ls -F

conf.d/ koi-win naxsi.rules scgi_params uwsgi_params
fastcgi_params mime.types nginx.conf sites-available/ win-utf
koi-utf naxsi_core.rules proxy_params sites-enabled/

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

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

Почти все оставшиеся файлы хранятся в /etc/nginx, который содержит сведения о конфигурации конкретных процессов или дополнительных компонентов.

Главным конфигурационным файлом Nginx является nginx.conf.

Файл nginx.conf

Файл nginx.conf читает соответствующие конфигурационные файлы и объединяет их в единый файл конфигурации при запуске сервера.

Откройте файл:

sudo nano /etc/nginx/nginx.conf

user www-data;
worker_processes 4;
pid /var/run/nginx.pid;
events {
worker_connections 768;
# multi_accept on;
}
http {
. . .

Первые строки задают общие сведения о Nginx. Строка user www-data указывает пользователя, с помощью которого запускается сервер.

Директива pid указывает, где будут храниться PID процессов для внутреннего использования. Строка worker_processes определяет количество процессов, которое может одновременно поддерживать Nginx.

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

За общими сведениями о сервере следует раздел events. Он управляет обработкой соединений Nginx. За ним идёт блок http. Прежде чем продолжить ознакомление с конфигурациями веб-сервера, нужно понять, как отформатирован конфигурационный файл Nginx.

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

Конфигурационный файл Nginx делится на блоки.

Первый блок – events, за ним идёт http и начинается главная иерархия конфигураций.

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

Во время настройки Nginx важно помнить следующее правило: чем выше уровень конфигурации, тем больше блоков наследует эту конфигурацию; чем ниже уровень конфигурации, тем она «индивидуальнее». То есть, если параметр Х должен применяться в каждом блоке server, то такой параметр нужно поместить в блок http.

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

Например, чтобы настроить сжатие файлов, нужно установить такие параметры:

gzip on;
gzip_disable "msie6";

Это включит поддержку gzip для сжатия отправляемых клиенту данных и отключит gzip для Internet Explorer 6 (поскольку этот браузер не поддерживает сжатия данных).

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

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

Блок http в файле nginx.conf заканчивается так:

include /etc/nginx/conf.d/*.conf;
include /etc/nginx/sites-enabled/*;

Это говорит о том, что блоки server и location, которые определяют настройки конкретных сайтов и URL-адресов, будут храниться за пределами этого файла.

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

Закройте файл nginx.conf. Теперь нужно изучить настройки отдельных сайтов.

Виртуальные блоки Nginx

Блоки server в Nginx являются аналогом виртуальных хостов Apache (но для удобства их тоже принято называть виртуальными хостами). По сути, блоки server – это технические характеристики отдельных веб-сайтов, размещённых на одном сервере.

В каталоге sites-available можно найти файл блока server по умолчанию, который поставляется вместе с сервером. Этот файл содержит все необходимые данные для обслуживания сайта.

cd sites-available
sudo nano default

root /usr/share/nginx/www;
index index.html index.htm;
server_name localhost;
location / {

}
location /doc/ {

alias /usr/share/doc/;
autoindex on;
allow 127.0.0.1;
deny all;

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

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

server {
. . .
}

Этот блок размещён в файле nginx.conf ближе к концу блока http с помощью директивы include.

Директива root определяет каталог, в котором будет храниться контент сайта. В этом каталоге Nginx будет искать запрашиваемые пользователем файлы. По умолчанию это каталог /usr/share/nginx/www.

Обратите внимание: все строки заканчиваются точкой с запятой. Так Nginx отделяет одну директиву от другой. Если точки с запятой не будет, Nginx прочитает две директивы (или несколько директив) как одну директиву с дополнительными аргументами.

Директива index определяет файлы, которые будут использоваться в качестве индекса. Веб-сервер будет проверять файлы в порядке их перечисления. Если ни одна страница не была запрошена, блок server найдёт и вернёт файл index.html. Если он не сможет найти этот файл, он попытается обработать index.htm.

Директива server_name

Директива server_name содержит список доменных имен, которые будут обслуживаться этим блоком server. Количество доменов неограниченно; домены в списке следует разделять пробелами.

Символ звёздочки (*) в начале или конце домена задаёт имя с маской, где звёздочка соответствует части (или нескольким частям) имени. Например, имя *.example.com будет соответствовать именам forum.example.com и www.animals.example.com.

Если запрашиваемый url-адрес соответствует нескольким директивам server_name, он сначала ответит той, с которой совпадает полностью.

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

Имена сервера, которые используют регулярные выражения, начинаются с тильды (~). К сожалению, данная тема выходит за рамки данной статьи.

Блоки location

Строка location / указывает, что директивы в скобках будут применяться ко всем запрашиваемым ресурсам, которые не соответствуют никаким другим блокам location.

Такие блоки могут содержать uri путь (например /doc/). Чтобы установить полное соответствие между location и uri, используется символ =. Символ ~ устанавливает соответствие с регулярными выражениями.

Тильда включает чувствительный к регистру режим, а тильда со звёздочкой – регистронезависимый режим.

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

Если опция ^~ не используется, Nginx выберет наиболее близкое совпадение и выполнит поиск по регулярным выражениям, чтобы попробовать подобрать один из доступных шаблонов. Если он найдёт такое выражение, то он использует его. Если такого выражения нет, то сервер использует найденное ранее совпадение с URI.

В качестве заключения следует отметить, что Nginx предпочитает точные соответствия. Если таких соответствий нет, он ищет регулярное выражение, а затем выполняет поиск по URI. Чтобы изменить приоритетность поиска по URI, используйте комбинацию символов ^~.

Директива try_files

Директива try_files – очень полезный инструмент, который проверяет наличие файлов в заданном порядке и использует первый найденный файл для обработки запроса.

Это позволяет вам с помощью дополнительных параметров определить, как Nginx будет обслуживать запросы.

В конфигурационном файле по умолчанию есть строка:

try_files $uri $uri/ /index.html;

Это значит, что при поступлении запроса, обслуживаемого блоком location, Nginx сначала попробует обслужить uri как файл (такое поведение задаёт переменная $uri).

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

С помощью слэша в конце сервер проверяет существование каталога, например, $uri/.

Если ни один файл или каталог не найден, Nginx выполняет файл по умолчанию (в данном случае это index.html в root-каталоге блока server). Каждая директива try_files использует последний параметр в качестве запасного варианта, потому этот файл должен существовать в системе.

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

Например, если блок location / не может найти запрашиваемый ресурс, вместо файла index.html он может вернуть ошибку 404:

try_files $uri $uri/ =404;

Для этого нужно поставить знак равно и задать код ошибки в качестве последнего параметра (=404).

Дополнительные параметры

Директива alias позволяет Nginx обслуживать страницы блока location вне заданного каталога (например, вне root).

Например, файлы, запрашиваемые в /doc/, будут обслужены из /usr/share/doc/.

Директива autoindex on позволяет включает листинг директорий Nginx для заданной директивы location.

Строки allow и deny управляют доступом к каталогам.

Заключение

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

Разобравшись с конфигурациями Nginx и научившись работать с ними, вы получите все преимущества этого мощного и легковесного инструмента.

Tags: ,

Один из самых популярных веб-серверов

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

Иерархия каталогов

Все конфигурационные файлы сервера располагаются в каталоге /etc/nginx. Кроме того, внутри директории расположены еще несколько папок, а также модульные конфигурационные файлы.

cd /etc/nginx
ls -F
conf.d/ koi-win naxsi.rules scgi_params uwsgi_params
fastcgi_params mime.types nginx.conf sites-available/ win-utf
koi-utf naxsi_core.rules proxy_params sites-enabled/

Если вы пользовались Apache, то должны быть знакомы с каталогами sites-enabled и sites-available. Они и определяют конфигурацию сайтов. Созданные файлы хранятся в последнем каталоге. Папка sites-enabled нужна для хранения конфигураций только активированных страниц. Чтобы их связать, нужна символическая ссылка между папками. Конфигурации можно также хранить в каталоге conf.d. При этом, во время запуска Nginx каждый файл с расширением.conf будет читаться по новой. При написании конфигурационных файлов, набирайте код без ошибок и соблюдайте синтаксис. Все остальные файлы располагаются в /etc/nginx. Конфигуратор содержит сведения о конкретных процессах, а также дополнительных компонентах.

Главный конфигурационный файл Nginx - это nginx.conf.

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

sudo nano /etc/nginx/nginx.conf

На экране появятся вот такие строки:

user www-data;
worker_processes 4;
pid /var/run/nginx.pid;
events {
worker_connections 768;
# multi_accept on;
}
http {
. . .

Первая - это общие сведения о Nginx. Фраза user www-data указывает на пользователя, который запускает сервер. Директива pid показывает, где располагаются PID-процессы, предназначенные для внутреннего использования. Строчка worker_processes показывает сколько процессов может одновременно запускать Nginx. Кроме того, здесь можно указать логи (например, лог ошибок определяется за счет директивы error_log). Ниже располагается раздел events. Он нужен для обработки соединений сервера. После него располагается блок http.

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

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

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

gzip on;
gzip_disable "msie6";

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

Последними строками файла nginx.conf выступают:

include /etc/nginx/conf.d/*.conf;
include /etc/nginx/sites-enabled/*;

Они свидетельствуют о том, что блоки location и server хранятся вне данного файла. Они определяют настройки url-адресов и конкретных файлов. Такая структура необходима для поддерживания модульной структуры конфигураций. Внутри нее получится создавать новые директории, файлы для различный сайтов. Кроме того, похожие файлы вы сможете сгруппировать. После рассмотрения вы можете закрывать файл nginx.conf.

Виртуальные блоки

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

cd sites-available
sudo nano default
server {
root /usr/share/nginx/www;
index index.html index.htm;
server_name localhost;
location / {
try_files $uri $uri/ /index.html;
}
location /doc/ {
alias /usr/share/doc/;
autoindex on;
allow 127.0.0.1;
deny all;
}
}

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

Этот блок размещается с помощью директивы include в конце http, прописанном в файле nginx.conf. Посредством директивы root определяется каталог, где будет располагаться контент сайта. В нем программа и будет искать файлы, которые пользователь будет запрашивать. Путь такой по умолчанию: /usr/share/nginx/www. Nginx отделяет строчки или директивы одна от другой посредством точки с запятой. Если знак препинания не проставить, несколько строчек прочтуться как одна. Чтобы прописать правила, которые будут использоваться в качестве индекса, воспользуйтесь директивой index. Сервер проверит их в порядке перечисления. Если ни одна из имеющихся страничек не была запрошена пользователем, вернется index.html. Если его не будет, то сервер будет искать index.htm.

Правило server_name

Она включает в себя список доменных имен, которые должен будет обработать блок server. Их можно прописать любое количество, разделяя пробелами. Если поставить * в конце или начале домена, удастся задать имя с маской. Звездочка соответствует части имени. Если прописать *.com.ua, то сюда будут относиться все адреса указанной доменной зоны. Если адрес подходит под описание нескольких директив, то он ответит той, которой подходит полностью. При отсутствии совпадений ответ будет на самое длинное имя, у которого есть маска. В противном случае будет выполнено соответствие регулярным выражениям. Имена сервера, которые используют регулярные выражения, начинаются с тильды (~).

Location-блоки

Следующий на очереди у нас будет блок location. Он нужен для определения способа обработки определенных запросов. Если ресурсы не соответствуют никаким иным блокам location, то к ним будут применяться директивы, указанные в скобках. Эти блоки могут включать путь вроде /doc/. Для установления полного соответствия между uri и location, применяется знак =. Применяя тильду, получится задать соответствие регулярным выражениям. Вы также можете установить чувствительность к регистру, поставив ~. Если добавить звездочку, регистр не будет играть никакой роли.

Имейте ввиду: когда запрос будет полностью соответствовать блоку location, он будет использован, а поиск остановится. Когда совпадение неполное, URI будет сравниваться с параметрами директив location. Используется блок с сочетанием ^~, совпадающий с URI для выбора блока. Если данную опцию не задействовать, сервер выбирает оптимальное совпадение, а также произведет поиск с использованием регулярных выражений. Это необходимо для подбора одного из подходящих шаблонов. Если подходящее выражение будет найдено, оно будет использовано. В противном случае, применится предыдущее совпадение с URI. Однако имейте ввиду, что Nginx больше любит полные соответствия. Если их нет, начнется поиск регулярных выражений, а потом по URI. Паритетность поиска задается комбинацией символов ^~.

Правило try_files

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

try_files $uri $uri/ /index.html;

Что же она означает? Если поступает запрос, который обслуживается блоком location, сервер сначала попытается обработать uri как файл. Это обеспечивает переменная $uri. Когда соответствий ей не будет, uri будет обработан как каталог. Можно проверить его существование, задав слеш в конце: $uri/. Бывают ситуации, когда ни файл, ни каталог не будет найден. В таком случае загрузится файл по умолчанию - index.html. Правило try_files применяет последний параметр как запасной вариант. Именно поэтому данный файл должен быть в системе. Однако, если совпадений вообще не найдено, Nginx вернет страничку ошибки. Чтобы ее задать, пропишите = и код ошибки:

Дополнительные опции

Если применить правило alias, получится обслужить страницы блока location вне каталога root, например. Когда нужны файлы из doc, они будут запрошены из /usr/share/doc/. Кроме того, правило autoindеx on запускает листинг директорий сервера, для указанной директивы location. Если прописать строки deny и allow, получится изменить доступ к каталогам.

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

Nginx? Назначение, особенности, варианты настроек - это вещи, с которыми должен быть ознакомлен каждый веб-разработчик, чтобы тестировать свои наработки.

О nginx замолвим слово

Данный инструмент обладает одним главным и несколькими рабочими процессами. Первый занимается чтением и проверкой конфигурации. Также под его контролем находится управление рабочими процессами. Задача последних - обрабатывать поступающие запросы. В nginx применяется модель, что базируется на событиях. Также используются механизмы, зависимые от операционной системы, чтобы добиться эффективного распределения запросов непосредственно между рабочими процессами. Их количество всегда обозначено в конфигурационном файле. Значение может быть как фиксированным, так и устанавливаться автоматически, ориентируясь по числу процессорных ядер, с которыми можно работать. В nginx настройка системы и модулей проводится с помощью конфигурационного файла. Поэтому, если надо что-то изменить, то искать необходимо именно его. Обычно он находится в директиве /etc/nginx (но путь может меняться при использовании других систем) и имеет расширение.conf.

Запуск, перезагрузка и логи

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

nginx -s сигнал

В данном случае подставлять можно такие команды (должны поступать от пользователя, что запустил инструмент):

1. Stop. Используется для быстрого завершения работы.
2. Reload. Команда необходима, чтобы перезагрузить конфигурационный файл. Дело в том, что любые изменения не будут применены, пока файл работает. И чтобы они вступили в силу, необходима перезагрузка. Как только будет получен этот сигнал, главный процесс начнёт проверять правильность синтаксической составляющей конфигурационного файла и попробует применить имеющиеся там указания. В случае неудачи он откатит изменения и будет работать со старыми параметрами. Если всё произошло успешно, то будут запущены новые рабочие процессы, а старым будет отправлено требование завершиться.
3. Quit. Применяется для плавного завершения работы. Применяется, если необходимо подождать, пока закончат обслуживаться текущие запросы.
4. Reopen. Закрыть и открыть лог-файлы.

Использование утилит

Настройка процессов может осуществляться также с помощью средств Unix (в качестве примера будет рассмотрена утилита kill). Обычно они используют механизм отправки процессу сигнала напрямую с данными. Увязываются они с помощью ID. Эти данные хранятся в файле nginx.pid. Допустим, что нас интересует процесс №134. Тогда для плавного завершения нам необходимо отправить следующую информацию:

kill -s QUIT 1628

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

ps -ax | grep nginx

То есть, как видите, при использовании дополнительного инструментария указывается, что идёт именно его применение. А теперь давайте сконцентрируемся на том, как совершается nginx-настройка.

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

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

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

Это одна их самых важных задач, которая стоит перед конфигурацией nginx. Под раздачей статистического содержимого подразумевают изображения и HTML-страницы (не динамические). Допустим, что нам нужна разовая работа по настройке nix nginx кластера. Сложно ли это сделать? Нет, и давайте рассмотрим пример. Прежде чем приступать к нему, необходимо детализировать условия задачи. Так, зависимо от запросов, файлы будут идти из разных локальных каталогов. Так, в /data/www мы имеем HTML-документы. А в каталоге /data/images содержатся изображения. Оптимальная настройка nginx в данном случае требует редактирования конфигурационного файла, в котором необходимо настроить блок server внутри http. Для поддержки будет использоваться также два location.

Реализация: server

Итак, для начала нам необходимо создать сами каталоги и разместить в них файлы с необходимыми расширениями (в html необходимо добавить содержимое). Затем открываем конфигурационный файл. В нём по умолчанию уже есть несколько блоков server, которые в массе своей закомментированы. Чтобы добиться оптимального результата, этот процесс необходимо проделать по отношению ко всем составляющим по умолчанию. Затем добавляем новый блок server с помощью такого кода:

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

Реализация: location

Определяется внутри server:

Наличие знака «/» необходимо, чтобы сравнивать получаемые данные и смотреть, есть ли такой адрес из обработанного запроса здесь. Если никаких проблем нет, то указываем путь /data/www к необходимому файлу, что находится в данной локальной системе. Если совпадение есть с несколькими блоками, то выбирается тот, у которого самый длинный префикс. В приведённом примере его длина равняется единице, то есть использование будет исключительно в том случае, если нет «конкурентов». Теперь давайте его усовершенствуем:

location /images/ {

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

location /images/ {

Это рабочий вариант, который случает стандартный Этот сервер без проблем может быть доступный на локальном компьютере, если пройти по адресу: http://localhost/. Как же это всё будет работать?

Принцип функционирования примера

Итак, когда придут запросы, что начинаются с с /images, то сервером файлы из соответствующего каталога будут отправляться пользователю. При его отсутствии будет передана информация, указывающая на ошибку 404. Если проводится настройка nginx на локальном компьютере, то при запросе http://localhost/images/example.png нами будет получен файл, месторасположение которого /data/images/example.png. При указании одного символа «/» поиск будет проводиться в директории /data/www. Но мы только изменили конфигурацию. Чтобы она начала работать, её необходимо перезагрузить. Для этого используйте команду nginx -s reload. В случае когда нормальная работа не является возможной, то в файлах error.log и access.log, расположенных в директиве /usr/local/nginx/logs, вы сможете поискать причину неисправностей.

Создание простого прокси-сервера

Можно сказать относительно nginx - настройка данного объекта является одним из частых применений (и довольно легким, между прочим). Здесь используется принцип сервера, который принимает запрос, а потом осуществляет перенаправление их к необходимым сайтам. После этого ожидается ответ от них, который направляет их к тому, кто поставил задачу. Поэтому давайте рассмотрим пример создания базовой точки. Она будет заниматься обслуживанием запросов пользователей и предоставлять им изображения из локального каталога. Итак, к блоку http добавляем ещё один server с таким содержимым:

А теперь давайте для вас расшифрую: создаётся простой сервер. Он будет прослушивать Не указать listen, то сервер будет работать на 80-м. Отображаться будут все запросы в рамках локальной файловой системы, которые направлены на каталог /data/up1 (конечно, его перед этим необходимо будет создать). Для возможности проверки там необходимо поместить файл index.html. Благодаря размещению директивы root в контексте server мы сможем воспользоваться location при любых условиях (поскольку, таким образом, снимаются ограничения доступа). Теперь работаем над созданием прокси-сервера. Для его работы нам понадобится директива proxy_pass, для которой будут указаны протокол, имя, а также порт объекта как параметры (при локальном подключении это будет выглядеть как http://localhost:8080). Получится такой результат:

proxy_pass http://localhost:8080;

location /images/ {

Если вы рассматриваете код и анализируете его, то можете заметить, что второй блок location был изменён. Так, в данном случае он может работать с типичными расширениями изображений. Немного по-другому его можно было бы отобразить таким образом:

location ~ \.(gif|jpg|png)$ {

root /data/images;

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

proxy_pass http://localhost:8080/;

location ~ \.(gif|jpg|png)$ {

root /data/images;

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

|

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

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

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

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

Установка Nginx

Обновите индекс пакетов, а затем установите Nginx:

sudo apt-get update
sudo apt-get install nginx

Проверка состояния Nginx

Чтобы проверить состояние веб-сервера на текущей машине, введите:

sudo systemctl status nginx

Автозагрузка Nginx

По умолчанию сервис Nginx запускается автоматически. Если вы хотите изменить это поведение, введите:

sudo systemctl disable nginx

Чтобы снова добавить Nginx в автозагрузку, введите:

sudo systemctl enable nginx

Управление сервисом Nginx

Чтобы остановить сервер Nginx, введите следующую команду:

sudo systemctl stop nginx

Чтобы запустить сервер Nginx, введите:

sudo systemctl start nginx

Чтобы остановить сервис и запустить его снова, введите:

sudo systemctl restart nginx

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

sudo systemctl reload nginx

Создание корневого каталога для статического контента

При создании сайтов на Nginx разработчики часто используют виртуальные хосты (или блоки server) – это хосты, которые обслуживают отдельные сайты или домены. Для этого нужно создать document root, каталог верхнего уровня, который Nginx проверяет при обслуживании контента.

Команды в приведенном ниже блоке создадут новый корневой каталог, передадут права на него пользователю sudo и изменят права доступа к каждому подкаталогу в подкаталога в /var/www/.

sudo chown -R $USER:$USER /var/www/example.com/html
find /var/www -type d -exec chmod 775 {} \;

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

Помните, что права доступа должны меняться в соответствии с ситуацией.

Создание корневого каталога для динамических файлов

Если ваш сайт использует динамические модули типа PHP-FPM, вам может понадобиться передать права на некоторые файлы группе www-data. Если группе нужно право на запись в каталоге, передайте группе права собственности на каталог.

Предложенные ниже команды создают новый document root, передают его группе www-data и изменяют права на каждый подкаталог в /var/www.

sudo mkdir -p /var/www/example.com/html
sudo chown -R www-data:www-data /var/www/example.com
sudo find /var/www -type d -exec chmod 775 {} \;

Включение и отключение конфигурационных файлов

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

Для этого введите комнаду:

sudo ln -s /etc/nginx/sites-available/example.com /etc/nginx/sites-enabled/

После этого нужно перезагрузить Nginx, чтобы настройки обновились.

Устранение неполадок с хэш-таблицей

Nginx использует хэш-таблицы, чтобы быстро обрабатывать статические данные (имена серверов, MIME-типы). Если вы добавили несколько имен серверов, есть вероятность, что заданного размера хэша имени сервера будет не хватать, и при внесении изменений вы увидите ошибку server_names_hash_bucket_size. Ее можно устранить, отредактировав одно значение в файле /etc/nginx/nginx.conf.

Откройте этот файл:

sudo nano /etc/nginx/nginx.conf

Найдите в файле директиву server_names_hash_bucket_size. Удалите символ #, чтобы раскомментировать строку, и увеличьте значение директивы:

http {
. . .
server_names_hash_bucket_size 64 ;
. . .
}

Это увеличит размер хэш-таблиц имен серверов Nginx и позволит сервису обрабатывать все имена серверов, которые вы добавили. Сохраните и закройте файл, а затем перезапустите Nginx, чтобы обновить настройки.

Тестирование конфигурации

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

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

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

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

sudo systemctl restart nginx

Важные файлы и каталоги Nginx

Контент

Каталог /var/www/html хранит весь контент сайта (это корневой каталог сайта). Вы можете изменить стандартные настройки Nginx и указать другие каталоги в var/www.

Конфигурация сервера

• /etc/nginx/: конфигурационный каталог Nginx (здесь хранятся все конфигурационные файлы веб-сервера).
• /etc/nginx/nginx.conf: главный конфигурационный файл веб-сервера, в котором находятся все глобальные параметры.
• /etc/nginx/sites-available/default: виртуальный хост Nginx по умолчанию. Другие виртуальные хосты также должны храниться в каталоге sites-available (но они не будут работать без симлинка в sites-enabled).
• /etc/nginx/sites-enabled/: здесь хранятся файлы включенных виртуальных хостов. При запуске или перезагрузке Nginx читает конфигурационные файлы и ссылки в этом каталоге, чтобы собрать полную конфигурацию.

Логи

• /var/log/nginx/access.log: это лог, который регистрирует все запросы Nginx (если в конфигурации веб-сервера не сказано другого).
• /var/log/nginx/error.log: это лог ошибок.

Чтобы получить доступ к логам systemd процесса Nginx, запустите эту команду:

sudo journalctl -u nginx

Заключение

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

Tags: