N ginx произносится как «engine x» – это бесплатный высокопроизводительный HTTP и обратный прокси-сервер с , отвечающий за загрузку некоторых из крупнейших сайтов в Интернете. Он может использоваться как автономный веб-сервер и как обратный прокси-сервер для Apache и других веб-серверов.

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

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

Прежде чем вы начнете

Все команды должны быть выполнены от имени или root и должны работать в любом современном дистрибутиве Linux, таком как и CentOS 7 и Debian 9.

Запустить Nginx

Запуск Nginx довольно прост. Просто запустите следующую команду:

Sudo systemctl start nginx

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

Если вы используете дистрибутив Linux без systemd для запуска типа Nginx:

Sudo service start nginx

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

Sudo systemctl enable nginx

Остановить Nging

Stop Nginx быстро остановит все рабочие процессы Nginx, даже если есть открытые соединения.

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

Sudo systemctl stop nginx sudo service stop nginx

Перезапустите Nginx

Параметр restart – это быстрый способ остановить и запустить сервер Nginx.

Используйте одну из следующих команд для перезапуска Nginx:

Sudo systemctl restart nginx sudo service restart nginx

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

Перезагрузить Nginx

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

Опция перезагрузки загрузит новую конфигурацию, запустит новые рабочие процессы с новой конфигурацией и корректно завершит работу старых рабочих процессов.

Чтобы перезагрузить Nginx, используйте одну из следующих команд:

Sudo systemctl reload nginx sudo service reload nginx

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

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

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

Sudo nginx -t

Вывод будет выглядеть примерно так.

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

Если есть какие-либо ошибки, команда напечатает подробное сообщение.

Посмотреть статус Nginx

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

Sudo systemctl status nginx

Вывод будет выглядеть примерно так:

* nginx.service - nginx - high performance web server Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: enabled) Drop-In: /etc/systemd/system/nginx.service.d `-nofile.conf Active: active (running) since Mon 2019-04-22 10:21:22 MSK; 10h ago Docs: http://nginx.org/en/docs/ Process: 1113 ExecStart=/usr/sbin/nginx -c /etc/nginx/nginx.conf (code=exited, status=0/SUCCESS) Main PID: 1183 (nginx) Tasks: 4 Memory: 63.1M CPU: 3min 31.529s CGroup: /system.slice/nginx.service |-1183 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.con |-1184 nginx: worker process |-1185 nginx: worker process `-1186 nginx: worker processs

Проверьте версию Nginx

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

Вы можете проверить свою версию Nginx, запустив:

Sudo nginx -v nginx version: nginx/1.14.0 (Ubuntu)

Вариант -V будет выводить версию Nginx вместе с возможностью конфигурирования.

Sudo nginx -V

Заключение

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

Будем работать под учетной записью обычного пользователя с sudo правами. Так же вам понадобится установленный веб-сервер Nginx. При желании можно установить полностью LEMP (Linux, Nginx, MySQL и PHP). Чтобы установить Nginx достаточно выполнить следующую команду:

Sudo apt-get update sudo apt-get install nginx

Прежде чем продолжить читать статью, настоятельно рекомендуем выполнить вышеописанные условия. Для примера, мы настроим два домена на нашем сервере. Их имена - example.com, test.com. Если в наличии у вас нет двух свободных имен, то просто придумайте два, а позднее мы покажем как настроить ваш локальный сервер, чтобы проверить их работоспособность.

Шаг 1 - настройка новой корневой директории

По-умолчанию на вашем Nginx сервере активирован только один виртуальный хост. Он работает с документами по адресу: /usr/share/nginx/html . Мы изменим эту настройку, так как чаще всего приходится работать с каталогом /var/www . Nginx не использует эту директорию по-умолчанию, так как это противоречит политике Debian по использованию пакетов в каталоге /var/www .

Но так как мы простые пользователи, и с вопросами хранения пакетов редко сталкиваемся, проигнорируем эту политику и установим этот каталог в качестве корневого. Точнее говоря, каждый каталог внутри корневой директории должен соответствовать отдельному сайту. А все файлы сайта разместим в директории /var/www/site_name/html . Сначала создадим все необходимые подкаталоги. Для этого выполним следующую команду:

Sudo mkdir -p /var/www/example.com/html sudo mkdir -p /var/www/test.com/html

Флаг -р указывает оболочке, чтобы она создавала новые каталоги если их не существует в указанном пути. Теперь передадим права на этот каталог обычному пользователю. Воспользуемся переменной окружения $USER , чтобы не вводить имя своего аккаунта. После этих действий мы сможем создавать в каталоге /var/www/ файлы, а посетители сайта - нет.

Sudo chown -R $USER:$USER /var/www/example.com/html sudo chown -R $USER:$USER /var/www/test.com/html

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

Sudo chmod -R 755 /var/www

Мы полностью подготовили структуру для нашего сервера, можем двигаться дальше.

Шаг 2 - Создаём шаблон страницы для каждого сайта

Давайте создадим страницу, которая будет отображаться по-умолчанию при создании нового сайта. Создайте файл index.html в каталоге первого домена:

Nano /var/www/example.com/html/index.html

Внутри сделаем минимальное наполнение, чтобы понимать на каком сайте мы находимся. Вот примерное содержание:

Это виртуальный хост example.com!

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

Cp /var/www/example.com/html/index.html /var/www/test.com/html/

Внесём в него небольшие изменения:

Nano /var/www/test.com/html/index.html

Это виртуальный хост test.com!

Сохраните и закройте этот файл. Теперь мы будем видеть правильно ли настроены наши сайты.

Шаг 3 - создание файлов виртуальных хостов для каждого домена

Теперь у нас есть содержимое для каждого сайта, настало время создать виртуальный хосты (точнее в Nginx они называются server block, но мы будет пользоваться термином виртуальный хост). По-умолчанию, Nginx использует один виртуальный хост под названием default . Используем его в качестве шаблона для нашей конфигурации. Сначала проработаем настройку для первого домена, которую потом просто скопируем и внесем минимальные изменения для второго домена.

Создание первого файла виртуального хоста

Как я уже сказал, скопируем файл настройки default :

Sudo cp /etc/nginx/sites-available/default /etc/nginx/sites-available/example.com

Откроем этот файл с правами администратора:

Sudo nano /etc/nginx/sites-available/example.com

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

Server { listen 80 default_server; listen [::]:80 default_server ipv6only=on; root /usr/share/nginx/html; index index.html index.htm; server_name localhost; location / { try_files $uri $uri/ =404; } }

Для начала разберемся с директивой listen . Только одному блоку server мы можем установить значение default_server . Блок с таким значением будет обслуживать запросы, если не было найдено подходящего блока (блок - это всё что находится в server). Мы отключим эту директиву в виртуальном хосте default , чтобы использовать default_server на одном из наших доменов. Я оставлю эту функцию активированной для первого домена, но при желании вы можете её перенести на второй.

Следующее что мы сделаем - настроим корневой каталог при помощи директивы root . Она должна указывать на каталог, где лежат все документы вашего сайта:

Root /var/www/example.com/html;

Заметка : каждая инструкция Nginx должна заканчиваться символом “;”.

Server_name example.com www.example.com;

Server { listen 80 default_server; listen [::]:80 default_server ipv6only=on; root /var/www/example.com/html; index index.html index.htm; server_name example.com www.example.com; location / { try_files $uri $uri/ =404; } }

На этом базовая настройка окончена. Сохраните и закройте файл.

Создание второго виртуального хоста

Для этого просто скопируем файл настроек для первого сайта:

Sudo cp /etc/nginx/sites-available/example.com /etc/nginx/sites-available/test.com

Откройте этот файл с правами администратора

Sudo nano /etc/nginx/sites-available/test.com

В этом файле также начнем с директивы listen . Если опцию default_server вы оставили в первом файле, то здесь её следует удалить. Также необходимо убрать опцию ipv6only=on, так как её указывают только для одной комбинации адрес/порт:

Listen 80; listen [::]:80;

Установите корневой каталог для второго сайта:

Root /var/www/test.com/html;

Теперь укажем server_name для второго домена:

Server_name test.com www.test.com;

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

Server { listen 80; listen [::]:80; root /var/www/test.com/html; index index.html index.htm; server_name test.com www.test.com; location / { try_files $uri $uri/ =404; } }

Сохраните и закройте файл.

Шаг 4 - активация виртуальных хостов и перезапуск Nginx

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

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

Теперь Nginx обработает эти файлы. Но виртуальный хост default , также активирован, поэтому мы получим конфликт параметра default_server . Отключить эту настройку можно просто удалив ссылку на файл. Сам файл останется в каталоге sites-available , так что при необходимости мы всегда сможем вернуть его на место.

Sudo rm /etc/nginx/sites-enabled/default

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

Sudo nano /etc/nginx/nginx.conf

Надо снять комментарий с одной из строк:

Server_names_hash_bucket_size: 64;

Эта директива применяется когда задано большое число имён серверов, либо заданы необычно длинные имена. Например, если значение по умолчанию равно 32 и имя сервера задано как “too.long.server.name.example.org”, то nginx откажется запускаться и выдаст сообщение об ошибке:

Could not build the server_names_hash, you should increase server_names_hash_bucket_size: 32

Поэтому лучше увеличить это значение до 64. Теперь можно перезапустить веб сервер, чтобы изменения вступили в силу:

Sudo service nginx restart

Ваш сервер теперь должен обрабатывать запросы к обоим доменам.

Шаг 5 - Настройка локального файла hosts (дополнительно)

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

Обратите внимание, что эти изменения следует производить только на локальной машине, а не на VPS сервере. Вам понадобятся root права, также необходимо иметь право изменять системные файлы.

Если вы используете Mac или Linux систему, то исправления можно внести следующим образом:

Sudo nano /etc/hosts

Если же вы пользуетесь Windows, то инструкции по этой ОС вы найдете на официальном сайте производителя (или в google). Вам необходимо знать открытый IP адрес вашего сервера и доменные имена, которые вы хотите привязать к нему. Допустим мой адрес 111.111.111.111 , тогда мне надо добавить следующие строки в файл hosts:

127.0.0.1 localhost 127.0.0.1 guest-desktop 111.111.111.111 example.com 111.111.111.111 test.com

Таким образом мы перехватим все запросы к этим доменным именам и перенаправим их на наш сервер. Сохраните и закройте файл когда закончите.

Шаг 6 - Проверка

На данном этапе вы должны получить полностью рабочую настройку. Осталось только её проверить. Для этого перейдем в браузере по адресу: http://example.com { :target="_blank"} . Если оба сайта отображаются корректно, то вас можно поздравить с полной настройкой сервера Nginx. На этом этапе, если вы вносили изменения в файл hosts , то их следует удалить т.к. проверка прошла успешно и они уже не нужны. Чтобы открыть доступ к сайтам для интернет пользователей, придется приобрести доменные имена.

Заключение

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

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 и научившись работать с ними, вы получите все преимущества этого мощного и легковесного инструмента.

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.

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

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