Руководство для начинающих
В этом руководстве даётся начальное введение в nginx и описываются некоторые простые задачи, которые могут быть решены с его помощью. Предполагается, что nginx уже установлен на компьютере читателя. Если нет, см. Установка nginx. В этом руководстве описывается, как запустить и остановить nginx и перезагрузить его конфигурацию, объясняется, как устроен конфигурационный файл, и описывается, как настроить nginx для раздачи статического содержимого, как настроить прокси-сервер на nginx, и как связать nginx с приложением FastCGI.
У nginx есть один главный и несколько рабочих процессов. Основная задача главного процесса — чтение и проверка конфигурации и управление рабочими процессами. Рабочие процессы выполняют фактическую обработку запросов. nginx использует модель, основанную на событиях, и зависящие от операционной системы механизмы для эффективного распределения запросов между рабочими процессами. Количество рабочих процессов задаётся в конфигурационном файле и может быть фиксированным для данной конфигурации или автоматически устанавливаться равным числу доступных процессорных ядер (см. worker_processes).
Запуск, остановка, перезагрузка конфигурации
Где сигнал может быть одним из нижеследующих:
Например, чтобы остановить процессы nginx с ожиданием окончания обслуживания текущих запросов рабочими процессами, можно выполнить следующую команду:
Команда должна быть выполнена под тем же пользователем, под которым был запущен nginx.
Изменения, сделанные в конфигурационном файле, не будут применены, пока команда перезагрузить конфигурацию не будет вручную отправлена nginx’у или он не будет перезапущен. Для перезагрузки конфигурации выполните:
Получив сигнал, главный процесс проверяет правильность синтаксиса нового конфигурационного файла и пытается применить конфигурацию, содержащуюся в нём. Если это ему удаётся, главный процесс запускает новые рабочие процессы и отправляет сообщения старым рабочим процессам с требованием завершиться. В противном случае, главный процесс откатывает изменения и продолжает работать со старой конфигурацией. Старые рабочие процессы, получив команду завершиться, прекращают принимать новые запросы и продолжают обслуживать текущие запросы до тех пор, пока все такие запросы не будут обслужены. После этого старые рабочие процессы завершаются.
Дополнительную информацию об отправке сигналов процессам nginx можно найти в Управление nginx.
Структура конфигурационного файла
nginx состоит из модулей, которые настраиваются директивами, указанными в конфигурационном файле. Директивы делятся на простые и блочные. Простая директива состоит из имени и параметров, разделённых пробелами, и оканчивается точкой с запятой ( ; ). Блочная директива устроена так же, как и простая директива, но вместо точки с запятой после имени и параметров следует набор дополнительных инструкций, помещённых внутри фигурных скобок ( < и >). Если у блочной директивы внутри фигурных скобок можно задавать другие директивы, то она называется контекстом (примеры: events, http, server и location).
Часть строки после символа # считается комментарием.
Раздача статического содержимого
Во-первых, создайте каталог /data/www и положите в него файл index.html с любым текстовым содержанием, а также создайте каталог /data/images и положите в него несколько файлов с изображениями.
В блок server добавьте блок location следующего вида:
Далее, добавьте второй блок location :
Он будет давать совпадение с запросами, начинающимися с /images/ ( location / для них тоже подходит, но указанный там префикс короче).
Итоговая конфигурация блока server должна выглядеть следующим образом:
Чтобы применить новую конфигурацию, запустите nginx, если он ещё не запущен, или отправьте сигнал reload главному процессу nginx, выполнив:
Настройка простого прокси-сервера
Одним из частых применений nginx является использование его в качестве прокси-сервера, то есть сервера, который принимает запросы, перенаправляет их на проксируемые сервера, получает ответы от них и отправляет их клиенту.
Мы настроим базовый прокси-сервер, который будет обслуживать запросы изображений из локального каталога и отправлять все остальные запросы на проксируемый сервер. В этом примере оба сервера будут работать в рамках одного экземпляра nginx.
Во-первых, создайте проксируемый сервер, добавив ещё один блок server в конфигурационный файл nginx со следующим содержимым:
Далее, используйте конфигурацию сервера из предыдущего раздела и видоизмените её, превратив в конфигурацию прокси-сервера. В первый блок location добавьте директиву proxy_pass, указав протокол, имя и порт проксируемого сервера в качестве параметра (в нашем случае это http://localhost:8080 ):
Итоговая конфигурация прокси-сервера выглядит следующим образом:
Чтобы применить новую конфигурацию, отправьте сигнал reload nginx’у, как описывалось в предыдущих разделах.
Существует множество других директив для дальнейшей настройки прокси-соединения.
Настройка проксирования FastCGI
nginx можно использовать для перенаправления запросов на FastCGI-серверы. На них могут исполняться приложения, созданные с использованием разнообразных фреймворков и языков программирования, например, PHP.
Настройка веб-сервера Nginx
Nginx – это популярный и производительный веб-сервер и обратный прокси-сервер.
У Nginx много преимуществ, однако его настройки достаточно сложные и не всегда понятны новичкам. Данное руководство поможет разобраться с основными параметрами, синтаксисом и конфигурационными файлами Nginx.
Примечание: Руководство выполнено на Ubuntu 12.04.
Иерархия каталогов Nginx
Nginx хранит конфигурационные файлы в каталоге /etc/nginx.
В этом каталоге находится ещё несколько каталогов и модульных конфигурационных файлов.
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.
Почти все оставшиеся файлы хранятся в /etc/nginx, который содержит сведения о конфигурации конкретных процессов или дополнительных компонентов.
Главным конфигурационным файлом Nginx является nginx.conf.
Файл nginx.conf
Файл nginx.conf читает соответствующие конфигурационные файлы и объединяет их в единый файл конфигурации при запуске сервера.
sudo nano /etc/nginx/nginx.conf
Первые строки задают общие сведения о 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 / <
alias /usr/share/doc/;
autoindex on;
allow 127.0.0.1;
deny all;
Файл по умолчанию очень хорошо закомментирован, но в примере выше комментарии опущены для простоты и удобства.
Блок 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 / указывает, что директивы в скобках будут применяться ко всем запрашиваемым ресурсам, которые не соответствуют никаким другим блокам location.
Такие блоки могут содержать uri путь (например /doc/). Чтобы установить полное соответствие между location и uri, используется символ =. Символ
устанавливает соответствие с регулярными выражениями.
Тильда включает чувствительный к регистру режим, а тильда со звёздочкой – регистронезависимый режим.
Если запрос полностью соответствует блоку location, то сервер останавливает поиск и использует такой блок. Если сервер не находит полностью подходящего блока location, он сравнивает URI с параметрами директив location. Nginx выберет блок, в котором используется сочетание символов ^
и который совпадает с URI.
не используется, Nginx выберет наиболее близкое совпадение и выполнит поиск по регулярным выражениям, чтобы попробовать подобрать один из доступных шаблонов. Если он найдёт такое выражение, то он использует его. Если такого выражения нет, то сервер использует найденное ранее совпадение с URI.
В качестве заключения следует отметить, что Nginx предпочитает точные соответствия. Если таких соответствий нет, он ищет регулярное выражение, а затем выполняет поиск по URI. Чтобы изменить приоритетность поиска по URI, используйте комбинацию символов ^
Директива try_files
Директива try_files – очень полезный инструмент, который проверяет наличие файлов в заданном порядке и использует первый найденный файл для обработки запроса.
Это позволяет вам с помощью дополнительных параметров определить, как Nginx будет обслуживать запросы.
В конфигурационном файле по умолчанию есть строка:
Если ни один файл или каталог не найден, Nginx выполняет файл по умолчанию (в данном случае это index.html в root-каталоге блока server). Каждая директива try_files использует последний параметр в качестве запасного варианта, потому этот файл должен существовать в системе.
В случае, если веб-сервер не обнаружил совпадений в предыдущих параметрах, он может вернуть страницу ошибки. Для этого используется знак равно и код ошибки.
Например, если блок location / не может найти запрашиваемый ресурс, вместо файла index.html он может вернуть ошибку 404:
Для этого нужно поставить знак равно и задать код ошибки в качестве последнего параметра (=404).
Дополнительные параметры
Директива alias позволяет Nginx обслуживать страницы блока location вне заданного каталога (например, вне root).
Например, файлы, запрашиваемые в /doc/, будут обслужены из /usr/share/doc/.
Директива autoindex on позволяет включает листинг директорий Nginx для заданной директивы location.
Строки allow и deny управляют доступом к каталогам.
Заключение
Веб-сервер Nginx является многофункциональным и очень производительным средством, однако его терминология и параметры могут показаться запутанными.
Разобравшись с конфигурациями Nginx и научившись работать с ними, вы получите все преимущества этого мощного и легковесного инструмента.
Conf d nginx для чего
Настройка веб-сервера Nginx
Один из самых популярных веб-серверов
Nginx пользуется большой популярностью среди пользователей веб- и прокси-серверов благодаря своей производительности. Сервер имеет много преимуществ, но настроить его будет сложно для новичка. Мы хотим вам помочь разобраться с конфигурационными файлами, синтаксисом, а также настройкой основных параметров Nginx.
Иерархия каталогов
Все конфигурационные файлы сервера располагаются в каталоге /etc/nginx. Кроме того, внутри директории расположены еще несколько папок, а также модульные конфигурационные файлы.
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/
Главный конфигурационный файл Nginx – это nginx.conf.
Он считывает все конфигурационные файлы, объединяя их в один, запрашиваемый при запуске сервера. Откройте файл с помощью:
На экране появятся вот такие строки:
Первая – это общие сведения о Nginx. Фраза user www-data указывает на пользователя, который запускает сервер. Директива pid показывает, где располагаются PID-процессы, предназначенные для внутреннего использования. Строчка worker_processes показывает сколько процессов может одновременно запускать Nginx. Кроме того, здесь можно указать логи (например, лог ошибок определяется за счет директивы error_log). Ниже располагается раздел events. Он нужен для обработки соединений сервера. После него располагается блок http.
Структура конфигурационного файла Nginx
Понимание структуры форматирования файла поможет вам лучше разобраться с конфигурацией веб-сервера. Она делится на структурные блоки. Детали конфигурации блока http разделены на уровни посредством закрытых блоков. Они наследуют свойства из родительского, т.е. того, в котором располагаются. Данный блок хранит большую часть конфигураций сервера. Они делятся на блоки server, внутри которых расположены location.
Когда вы настраиваете сервер Nginx, помните, что чем ниже располагается блок конфигурации, тем меньше элементов будут наследовать свойства и наоборот. В файле присутствует большое количество опций, меняющих работу сервера. Вы можете установить сжатие файлов отправляющихся клиенту, например. Для этого пропишите параметры:
Имейте ввиду, что один и тот же параметр может принимать разные значения в различных блоках. Сначала задайте его вверху, в потом переопределите параметр на нужном уровне. Если последнее действие не выполнить, программа задаст значения в автоматическом режиме.
Последними строками файла 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 располагаются настройки, заключенные в фигурные скобки:
Этот блок размещается с помощью директивы 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
Это весьма полезный инструмент, способный проверять наличие файлов в установленном порядке. Он применяет первый соответствующий критериям для обработки запроса. Вы можете использовать дополнительные параметры, чтобы задать, каким образом сервер обслужит запросы. В конфигураторе есть вот такая строка по умолчанию:
Дополнительные опции
Если применить правило alias, получится обслужить страницы блока location вне каталога root, например. Когда нужны файлы из doc, они будут запрошены из /usr/share/doc/. Кроме того, правило autoindеx on запускает листинг директорий сервера, для указанной директивы location. Если прописать строки deny и allow, получится изменить доступ к каталогам.
В качестве заключения стоит сказать, что Nginx – это очень мощный многофункциональный инструмент. Но чтобы разобраться хорошо с принципом его работы, потребуются время и усилия. Если понять работу конфигураций, вы сможете в полной мере наслаждаться всеми возможностями программы.
Установка и настройка nginx
В данной статье описана установка и настройка высокопроизводительного современного веб-сервера nginx на примере облачной платформы Selectel. Все действия актуальны для ОС Ubuntu 20.04 LTS 64-bit.
Nginx — это веб-сервер с открытым исходным кодом, созданный работать под высокой нагрузкой, чаще всего используемый для отдачи статического контента, например, html страниц, медиафайлов, документов, архивов, картинок и т.д.
Подготовка сервера
Для начала установим сам сервер. После прохождения регистрации, необходимо войти в панель управления. Далее в меню «Облачная платформа» — «Создать сервер».
Откроется оснастка создания сервера, где необходимо задать понятное для дальнейшей работы имя сервера, в примере это «WebSrv01». Регион и зону можно оставить без изменения. Для выбора операционной системы необходимо нажать кнопку «Выбрать другой источник».
Откроется меню «Выбор источника».
В поле «Операционные системы», выбираем Ubuntu, в левом поле появится список всех доступных образов операционных систем на базе данной ОС, выбираем «Ubuntu 20.04 LTS 64-bit» и нажимаем кнопку «Выбрать».
Перемещаемся вниз по странице. В нашем примере используется только «Локальный диск», флажок установлен, в поле «Сетевые диски» нажимаем кнопку «Удалить диск».
В поле «Сеть», поскольку это наш первый сервер выбираем «Приватная подсеть + 1 плавающий IP», после выбора значение в поле сменится на «Новый плавающий IP адрес».
Необходимо скопировать «Пароль для root», он понадобиться для первоначальной настройки сервера через SSH протокол.
Нажимаем кнопку «Создать», сервер будет доступен примерно через 1 минуту. Переходим в меню «Облачная платформа» — «Серверы».
В списке появится сервер с именем, что задали ранее, его IP адрес, который будем использовать для удаленного подключения, на скриншоте в области с цифрой 3, статус сервера ALIVE, означает готовность сервера. Подключаемся к серверу, используя любой SSH-клиент.
Проведем небольшую первоначальную настройку сервера. Обновим информацию о доступных пакетах из подключенных репозиториев:
Создадим непривилегированного пользователя, в нашем случае webuser:
Появится интерактивный диалог, в ходе которого необходимо будет задать пароль (New password), подтвердить его (Retype new password), остальные пункты можно не заполнять, просто нажимая ENTER. В последнем вопросе Is the information correct? [Y/n] необходимо нажать Y и нажать ENTER.
Добавляем пользователя webuser в группу sudo для повышения привилегий:
Открываем конфигурационный файл SSH-сервера:
В открывшемся текстовом файле ищем строку #Port 22 и удаляем в начале строки символ комментария #, стандартный номер порта 22 рекомендуется сменить в целях безопасности, пускай это будет 22100. В конечном итоге строка должна выглядеть следующим образом:
Переходим к строке PermitRootLogin yes, меняем значение на no, тем самым запретив вход пользователя root напрямую:
Находясь в редакторе, нажимаем комбинацию клавиш Ctrl+O, внизу появится строка подтверждения: File Name to Write: /etc/ssh/sshd_config, нажимаем ENTER для сохранения изменений, затем Ctrl+X для выхода из редактора.
После изменений файла конфигурации SSH сервера, необходимо выполнить его перезапуск для того, чтобы изменения вступили в силу:
Установка nginx
Установка сервера nginx может быть выполнена как непосредственно на машину, так и в виде docker контейнера. У каждого метода есть свои преимущества и недостатки, описание которых выходит за рамки данной статьи. Мы посмотрим оба варианта.
Начнем с непосредственной установки на сервер:
Будет задан вопрос: Do you want to continue? [Y/n]
Нажимаем Y, затем ENTER.
Дожидаемся окончания процесса установки.
Разрешим автозапуск сервера:
Если в ответ получили «enabled», значит nginx успешно добавлен в автозагрузку.
Запуск nginx
Стартуем наш веб-сервер:
Если в статусе присутствует строка Active: active (running), значит сервер работает. Также в этом можно убедиться, набрав в адресной строке браузера IP адрес сервера, будет отображено приветственное сообщение от nginx, которое выглядит так:
Nginx в Docker
Для установки Docker, нужно подготовить систему. Устанавливаем необходимые пакеты:
Будет задан вопрос: Do you want to continue? [Y/n]
Нажимаем Y, затем ENTER.
Добавляем GPG ключ официального репозитория Docker в систему:
В следующей строке появится надпись OK, добавляем репозиторий Docker:
Теперь необходимо обновить информацию о пакетах:
Проверим, что установка Docker будет происходить из его репозитория:
В ответ должны получить много строк, среди которых должен присутствовать адрес репозитория, добавленный ранее, в нашем примере это:
Будет задан вопрос: Do you want to continue? [Y/n]
Нажимаем Y, затем ENTER.
Дожидаемся окончания процесса установки. После docker будет автоматически запущен и добавлен в автозагрузку. Проверим:
В выводе команды должна присутствовать строка Active: active (running), значит процесс-демон работает.
В ответе увидели «enabled», значит docker успешно добавлен в автозагрузку. На этом установка Docker завершена, переходим к запуску в контейнере веб-сервера nginx.
Создадим проект и его структуру папок в домашнем каталоге нашего пользователя webuser:
Устанавливаем и запускаем nginx в Docker одной командой:
Docker скачает официальный образ nginx с Docker Hub, сконфигурирует и запустит контейнер.
Проверяем, работает ли контейнер:
Вывод команды должен быть примерно следующим:
Стоит обратить внимание на столбец NAMES, где обнаруживаем имя созданного ранее контейнера nginx_myproject, колонка STATUS, в которой отображается состояние контейнера, в данном случае он работает уже 7 часов. Если набрать в адресной строке браузера IP адрес сервера и через двоеточие порт, используемый контейнером 8080, т.е. конструкцию вида 123.123.123.123:8080, то в ответ получим:
Мы научились запускать веб-сервер nginx в контейнере!
Проброс портов, папок, а так же многий другой функционал, предоставляемый контейнеризацией, должен быть использован исходя из поставленных задач, разнообразие которых выходит за рамки данной статьи. Дальнейшее описание работы с nginx рассматривается в рамках работы непосредственно на сервере, без контейнеризации.
Иерархия каталогов nginx
Администрирование сервера nginx в основном заключается в настройке и поддержке его файлов конфигурации, которые находятся в папке /etc/nginx. Рассмотрим подробнее:
Настройка nginx
Рассмотрим главный конфигурационный файл nginx — /etc/nginx/nginx.conf. По умолчанию он выглядит следующим образом:
Конфигурационный файл состоит из директив. О них и пойдет речь дальше.
Директивы
Существует два вида директив – простые и блочные. Простая директива состоит из имени и параметров, разделённых пробелами, и в конце строки ставится точкой с запятой (;). Блочная директива устроена так же, как и простая директива, но вместо точки с запятой после имени и параметров следует набор дополнительных инструкций, помещённых внутри фигурных скобок ( <и >). Рассмотрим те, которые пригодятся нам для примера:
Переменные в nginx
В конфигурационных файлах nginx допустимо пользоваться встроенными переменными. Преимущественно это переменные, представляющие собой поля заголовка запроса клиента, такие как $remote_addr, $server_name. Все переменные начинаются со знака $, с полным перечнем можно ознакомиться в документации, на официальном сайте.
Установка и настройка php-fpm
Для работы веб приложений, написанных на языке PHP необходимо установить php-fpm в качестве бэкэнда:
Будет задан вопрос: Do you want to continue? [Y/n]
Нажимаем Y, затем ENTER.
После установки сервис будет автоматически запущен и добавлен в автозагрузку. Создаем файл пула для конкретного сайта sampledomain.ru:
Создаем следующую конфигурацию:
Нажимаем комбинацию клавиш Ctrl+O, внизу появится строка подтверждения: File Name to Write: /etc/php/7.4/fpm/pool.d/sampledomain.ru.conf, нажимаем ENTER для сохранения изменений, затем Ctrl+X для выхода из редактора.
Перезагружаем сервис php-fpm, чтобы он мог перечитать файлы конфигураций:
Проверяем, что сервис перезапустился корректно и наша новая конфигурация sampledomain.ru обслуживается:
О том, что сервис запущен, свидетельствует наличие строки Active: active (running), чуть ниже список обслуживаемых конфигураций в виде дерева, где можно увидеть php-fpm: pool sampledomain.ru, значит все работает.
Конфигурация nginx
Структура директорий веб проекта будет размещена в домашней папке пользователя webuser, это облегчит дальнейшую унификацию конфигурационных файлов и масштабируемость. Например, когда возникает необходимость на одном сервере разместить несколько сайтов, у каждого из них свой владелец. В таком случае создается новый пользователь, пусть будет webuser2, аналогично в его папке разворачивается такая же структура каталогов.
У нас имеется главный конфигурационный файл, содержимое которого оставляем неизменным для примера. Создадим файл виртуального хоста:
Заполняем его следующим содержимым:
Нажимаем комбинацию клавиш Ctrl+O, внизу появится строка подтверждения: File Name to Write: /etc/nginx/sites-available/sampledomain.ru.conf, нажимаем ENTER для сохранения изменений, затем Ctrl+X для выхода из редактора.
Создаем символическую ссылку на данный виртуальный хост из директории /etc/nginx/sites-available в директорию /etc/nginx/sites-enabled, чтобы nginx его обслуживал:
Необходимо создать структуру каталогов веб проекта:
Создаем файл для тестирования работы связки nginx и php-fpm:
Задаем владельца каталогов и находящихся внутри файлов:
Добавляем пользователя www-data в группу webuser:
Конфиги написаны, директории созданы, перезапускаем nginx для того, чтобы он перечитал файлы конфигураций:
Переходим в браузере по адресу http://sampledomain.ru и должны увидеть такую картину:
Все настроили правильно.
Команды nginx
Рассмотрим несколько команд, которые полезно знать администратору. После внесения изменений в конфигурационные файлы сервера, рекомендуется провести их синтаксический контроль:
Если все хорошо, в результате получим сообщение:
В случае обнаружения ошибок, сервер уведомит об этом. Чтобы узнать используемую версию сервера, нужно ввести:
Можно получить расширенную информацию об nginx – его версию, параметры конфигурации сборки:
Когда существует необходимость оперативно, но аккуратно перезапустить веб-сервер, чтобы пользователи на данный момент, работающие с ним, не потеряли соединение, но в то же время, вновь подключившиеся уже работали с учетом последних изменений конфигурации. В таком случае, вместо restart необходимо использовать команду reload:
Настройка SSL сертификата
Получение SSL сертификата необходимо для использования протокола HTTPS. Данный протокол защищает соединение между сервером и клиентом, особенно критично для чувствительных данных, таких как логины, пароли, данные по банковским картам, переписка и так далее. Последние несколько лет поисковые системы наиболее лояльны к сайтам, использующих данный протокол, есть прекрасная возможность получить ssl сертификат бесплатно от Let’s Encrypt, устанавливаем его клиент certbot из официального репозитория:
Будет задан вопрос: Do you want to continue? [Y/n]
Нажимаем Y, затем ENTER.
Запрашиваем сертификат у Certbot:
Появится вопрос о передаче вашего адреса электронной почты компании партнеру: (Y)es/(N)o:
Жмем Y, потом ENTER.
Сертификат успешно получен, если появилось сообщение:
Сертификат действителен 90 дней. Теперь необходимо позаботиться об автоматическом продлении сертификатов, открываем файл:
Приводим его к следующему виду:
Нажимаем комбинацию клавиш Ctrl+O, внизу появится строка подтверждения: File Name to Write: /etc/cron.d/certbot, нажимаем ENTER для сохранения изменений, затем Ctrl+X для выхода из редактора.
Дважды в день будет происходить проверка необходимости обновления сертификатов на сервере, если какому-либо осталось 30 дней и меньше до истечения срока действия – он будет обновлен, а nginx перезагружен.
Протестируем процесс обновления без внесения изменений:
Ждем около полминуты, на экран будет выведен подробный отчет. Если присутствует строка Congratulations, all renewals succeeded – значит все настроено правильно. Если когда-либо в процессе обновления произойдет сбой – Let’s Encrypt уведомит о приближающимся конце срока действия сертификата по электронной почте, указанной при первом запросе.
Редирект с http на https
После получения сертификата необходимо прописать директивы в файл конфигурации виртуального хоста, отвечающие за поддержку SSL. Сразу же реализуем перенаправление всех запросов, приходящих на 80-й порт к порту 443, т.е. с http протокола на https. Открываем файл:
Приводим его к следующему виду:
Нажимаем комбинацию клавиш Ctrl+O, внизу появится строка подтверждения: File Name to Write: /etc/nginx/sites-available/sampledomain.ru.conf, нажимаем ENTER для сохранения изменений, затем Ctrl+X для выхода из редактора.
Теперь в браузере при попытке перехода по адресу http://sampledomain.ru будет выполнено перенаправление на https://sampledomain.ru
Кэширование в nginx
Основная задача кэширования – это минимизация времени доступа к данным. Nginx умеет работать с несколькими видами кэширования: на стороне сервера, на стороне клиента. Серверное кэширование может иметь самую разнообразную конфигурацию, в зависимости от архитектуры проекта. Поэтому в нашем частном случае рассмотрим кэширование на стороне клиента (браузера) для статического контента.
Открываем файл нашего тестового виртуального хоста:
Находим location, указывающий на отдачу статического контента и добавляем директиву expires:
Как обычно сохраняем результат Ctrl+O, подтверждаем нажатием ENTER, выходим из редактора Ctrl+X. В данном случае файлы, расширения которых соответствуют приведенным выше, будут храниться в браузере клиента, только после истечения суток – они будут запрошены повторно.
Кэширование позволяет значительно уменьшить время доставки контента и его объем, снизить нагрузку на сервер, а значит, ваш сайт сможет работать значительно быстрее и принять больше посетителей.
Мониторинг nginx
В nginx существует стандартная возможность мониторинга работы сервера, выясним доступность модуля в нашей сборке:
Если в ответ получили with-http_stub_status_module – модуль доступен. Рассмотрим включение мониторинга на примере виртуального хоста, открываем файл:
Добавляем location /nginx_status, в итоге файл выглядит следующим образом:
Сохраняем результат Ctrl+O, подтверждаем нажатием ENTER, выходим из редактора Ctrl+X. Перезапускаем веб-сервер:
В браузере при переходе по адресу sampledomain.ru/nginx_status будет представлена статистика работы сервера:
Также статистику можно получить из командной строки:
Не рекомендуется статистику выставлять на всеобщее обозрение, ниже рассмотрим вопросы безопасности и ограничений доступа.
Проксирование запросов
Nginx умеет проксировать запросы на другие сервера, понадобиться это для масштабирования и защиты back-end серверов. В качестве примера, запустим back-end сервер apache в контейнере:
Дожидаемся процесса скачивания образа, контейнер запуститься автоматически, убеждаемся, что среди запущенных контейнеров присутствует backend_apache:
Открываем файл виртуального хоста:
Изменим блок location / так, чтобы при обращении к sampledomain.ru запрос был передан веб-серверу apache, работающему в контейнере:
Сохраняем результат Ctrl+O, подтверждаем нажатием ENTER, выходим из редактора Ctrl+X. Перезапускаем веб-сервер:
Директива proxy_pass задает протокол, адрес и порт проксируемого ресурса, proxy_set_header директивы настраивают заголовки запросов, передают проксируемому ресурсу информацию о соединении.
Если перейти в браузере по адресу http://sampledomain.ru, можно увидеть «It works!», отдаваемый ранее созданным контейнером с apache.
Балансировка нагрузки
Для улучшения отказоустойчивости, масштабируемости, уменьшения время отклика, распределения полезной нагрузки придумали балансировщики нагрузок. На примере посмотрим, как приспособить для этого nginx.
Открываем файл виртуального хоста:
Над блоком server добавляем следующее:
Также вносим изменения в блок location /:
Сохраняем результат Ctrl+O, подтверждаем нажатием ENTER, выходим из редактора Ctrl+X. Перезапускаем веб-сервер:
Директива upstream перечисляет все back-end сервера, между которыми следует распределить нагрузку. В блоке location / изменился параметр директивы proxy_pass на http://backends, где backends – имя, которое присвоили группе серверов директивы upstream.
Ранее мы запустили два контейнера: первый с nginx на порту 8080, второй с apache на порту 8081. Теперь перейдя в браузере по ссылке http://sampledomain.ru и несколько раз обновляя страницу можно наблюдать чередование ответов «It works!» и «Hello from NGINX in Docker!», значит балансировка работает.
Существует несколько методов балансировки:
round-robin – используется по умолчанию, нагрузка распределяется равномерно между серверами с учетом веса.
least_conn – запросы поступают к менее загруженным серверам.
ip_hash — запросы распределяются по серверам на основе IP-адресов клиентов, т.е. запросы одного и того же клиента будут всегда передаваться на один и тот же сервер, пример:
Если в группе серверов некоторые производительнее остальных, то следует воспользоваться механизмом весов. Это условная единица, которая позволяет направлять наибольшую нагрузку на одни сервера и ограждать от нее другие.
Разберем на примере:
В данной конфигурации, из 7 запросов, 5 будет обработано сервером 127.0.0.1:8080, а 2 машиной 127.0.0.1:8081
Безопасность nginx
В данном разделе мы рассмотрим общие принципы обеспечения безопасности как сервера в целом, так и отдельных его ресурсов.
HTTP аутентификация
Для защиты определенных ресурсов сайта, например, таких как панель администратора, статистика, каталоги с файлами для внутреннего использования, иногда может потребоваться дополнительная мера – от пользователя потребуется ввести логин и пароль.
Установим утилиту для генерации хешированных паролей:
Будет задан вопрос: Do you want to continue? [Y/n]
Нажимаем Y, затем ENTER.
Теперь создадим файл, в котором будет содержаться список логинов и паролей пользователей:
Добавим пользователя user:
Будет предложено ввести пароль, вводимые символы не отображаются, это нормально, после нажать ENTER:
Ввести повторно тот же пароль:
Появление ответа Adding password for user user означает, что все сделано верно. Точно так же можно добавить других пользователей. Чтобы сменить пароль пользователя user – нужно повторно ввести предыдущую команду, данные в файле будут обновлены.
В примере будем защищать доступ к нашему виртуальному хосту, а конкретно к статистике работы сервера, открываем файл конфигурации:
Редактируем location /nginx_status следующим образом:
Сохраняем результат Ctrl+O, подтверждаем нажатием ENTER, выходим из редактора Ctrl+X. Перезапускаем nginx:
Теперь при переходе в раздел просмотра статистики sampledomain.ru/nginx_status необходимо будет сначала ввести логин и пароль для доступа к разделу, в противном случае сервер выдаст ошибку: 401 Authorization Required.
Авторизацию по паролю рекомендуется использовать исключительно для служебных целей и совместно с протоколом https, иначе данные передаются в открытом виде.
Ограничение доступа по IP адресу
В качестве примера отредактируем тренировочный виртуальный хост:
Рассмотрим блок location /nginx_status, приведем его к виду:
Сохраняем результат Ctrl+O, подтверждаем нажатием ENTER, выходим из редактора Ctrl+X. Перезапускаем nginx:
В данном примере разрешен доступ для компьютеров из сети 192.168.0.0 с маской подсети 255.255.255.0 (/24) и хоста с адресом 192.168.1.1. Для всех остальных доступ закрыт.
Комбинация ограничений
Рассмотрим ситуацию, когда имеется предприятие, с внутренней сетью 192.168.0.0/24, и сотрудники из нее должны беспрепятственно попадать в нужный раздел, но в то же время необходимо предоставить доступ снаружи, используя авторизацию по логину и паролю. Тогда location /nginx_status принимает следующий вид:
Сфокусируем внимание на директиве satisfy. В данном случае она имеет параметр any, что означает предоставление доступа при выполнении хотя бы одного из условий. При смене параметра на all – сотрудникам предприятия будет разрешен доступ только из внутренней сети с аутентификацией по логину и паролю.
Предотвращение DDoS атак
DDoS — это распределенная атака отказа в обслуживании, происходит с нескольких IP адресов, направлена на ухудшение или полное отсутствие доступности сервера за счёт огромного количества запросов. Чаще всего, это происки недобросовестных конкурентов, реже из хулиганских побуждений. В nginx предусмотрен механизм, позволяющий, если не полностью подавить атаку, то как минимум смягчить ее влияние на работу системы.
Возможно ограничить скорость приема входящих запросов в единицу времени с одного IP адреса. Так же можно ограничить количество одновременных подключений с одного IP адреса. Обе техники посмотрим на примере файла конфигурации виртуального хоста, открываем:
Доводим до следующего состояния:
Сохраняем результат Ctrl+O, подтверждаем нажатием ENTER, выходим из редактора Ctrl+X. Перезапускаем nginx:
.php$, ссылающаяся на зону разделяемой памяти, задающая лимит на количество соединений с одного IP адреса, в данном случае 10.
Следует внимательно отнестись к настройке подобных значений, поскольку полезные и оптимальные значения для одного проекта, могут быть неприемлемы в другом.
Ошибки nginx
В работе любых систем, а особенно на этапе пуско-наладочных работ, возникают ошибки, в данном разделе рассмотрим наиболее распространенные и методы их устранения.
502 bad gateway
Эта ошибка говорит о том, что back-end, обрабатывающий запрос от nginx – перестал отвечать. Произойти это могло также по нескольким причинам. Во-первых, back-end мог упасть полностью и для восстановления его необходимо запустить. Во-вторых, если nginx и back-end сервер находятся на физически разных машинах – между ними могла банально пропасть связь. Для проверки необходимо воспользоваться командой ping. Так же, возможно, часть процессов php-fpm перегружены или не хватает их количества для обслуживания всех клиентов, тогда эта ошибка будет иметь «плавающий» характер. Открываем файл:
Если действительно проблема в нехватке процессов — стоит «покрутить» следующие настройки:
504 Gateway Time-out
Одна из причин возникновения ошибки – превышение времени ожидания ответа от сервера, например от php-fpm. Такое случается, когда скрипты php долго выполняются или зависли. Если обработка запроса требует большего времени – увеличим время ожидания на передачу запроса fastcgi_send_timeout и получение ответа fastcgi_read_timeout, редактируем блок location
Сохраняем результат Ctrl+O, подтверждаем нажатием ENTER, выходим из редактора Ctrl+X. Перезапускаем nginx:
413 Request Entity Too Large
Ошибка возникает, когда на сервер загружается файл, превышающий значение директивы client_max_body_size, по умолчанию – 1 Мб. Добавим в блок server:
В примере максимально допустимый размер тела запроса клиента увеличен до 50 Мб. При повторном возникновении ошибки – снова увеличить. Не забываем сохраняться и после изменений – перезапускать nginx:
Искать причины возникновения тех или иных ошибок правильнее всего в логах, которые находятся в папке /var/log/nginx/. Однако, у начинающего администратора возникают сложности с интерпретацией, содержащейся в них информации.
В таком случае можно посоветовать определить строку, где содержится сообщение об ошибке, выделить текст сообщения и вбить его в поисковую систему. Как правило, в сети найдется огромное количество ресурсов с описанием решения тех или иных сложностей.
