Продолжая серию статей, посвящённую популярному веб-серверу Nginx, сегодня я на примере базовой конфигурации , поставляемой в комплекте с Debian 5.0 Lenny, хочу рассмотреть основы конфигурирования Nginx. Как было сказано в предыдущей статье, конфигурационный файл Nginx в Debian по умолчанию располагается в /etc/nginx/nginx.conf. Вообще, простота и понятность синтаксиса конфиг-файла Nginx, на мой взгляд, являются одной из сильных его сторон. Прежде чем двигаться дальше, давайте посмотрим и построчно разберём содержимое файла конфигурации Nginx, предлагаемое разработчиками дистрибутива.

Конфигурационный файл состоит из параметров, расположенных вне секций и из секций параметров, обрамлённых фигурными скобками. В приведённом выше примере вы можете увидеть две секции: events и http.

Опция user используется для того, чтобы сообщить серверу, чей UID/GID он должен использовать после старта, если был запущен от имени root. Если вы не определите значение этой опции, Nginx будет использовать nobody/nobody. Если же в вашей системе существует отдельная учётная запись для организации доступа к веб-содержимому, как это сделано во многих популярных дистрибутивах, то лучше использовать её. Само собой разумеется, крайне нежелательно разрешать работу веб-сервера от имени root — сие есть очень небезопасно. Вообще опция user принимает два параметра: первый — это имя учётной записи, второй — имя группы. Если имя группы не указать, то Nginx будет использовать в качестве имени группы значение имени пользователя. Таким образом, в приведённом выше примере, Nginx работает с UID и GID www-data.

Значение параметра worker_processes определяет количество запускаемых рабочих процессов Nginx. Увеличивать значение этого параметра есть смысл лишь в том случае, когда у вас Nginx работает на многопроцессорной системе либо в системе производится много операций ввода/вывода, что приводит к увеличению времени отклика рабочего процесса Nginx. Также значение этого параметра влияет на предел одновременных подключений, который определяется путём умножения значения этого параметра на значение параметра worker_connections в секции events.

Значение параметра error_log определяет местоположение файла протокола ошибок работы сервера и FastCGI, также уровень серьёзности сообщений, попадающих в этот протокол. Первым значением параметра error_log должен быть путь к файлу, а вторым, необязательным, — уровень. Уровень серьёзности может быть одним из (в порядке увеличения серьёзности): debug, info, notice, warn, error, crit. Также обратите внимание, что использование этого параметра разрешено не только в общей секции, а и в секциях http и server. По умолчанию значение параметра error_log различно в разных секциях. В общей секции — error, в секциях http и server — crit. При изменении значения этого параметра не забывайте, что снижение уровня серьёзности повлечёт за собой более интенсивный ввод-вывод со стороны сервера, что может негативно сказаться на производительности.

Значение параметра pid определяет местоположение файла, содержащего идентификатор процесса запущенного сервера. Используется внешними сценариями и программами при необходимости, поэтому менять или удалять его не стоит, если не знаете, что делаете.

В секции events настраивается подведение Nginx относительно сетевых соединений.

В конфигурации по умолчанию определён лишь один параметр, упоминавший выше — worker_connections. Как уже говорилось, значение этого параметра помноженное на значение параметра worker_processes определяет максимально возможное количество одновременных соединений к серверу.

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

При помощи опции default_type задаётся MIME-тип по умолчанию, коорый будет передавать сервер клиенту, если этот тип не удалось определить. Опцию default_type можно использовать в контексте секций http, server и location.

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

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

Включение опции tcp_nopush заставляет Nginx пытаться отправлять HTTP-заголовки в одном пакете. Имейте ввиду, что смысл в этой опции есть лишь тогда, когда включена опция sendfile. Опция tcp_nopush может применяться в контексте секций http, server и location.

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

Параметр tcp_nodelay влияет разрешает или запрещает использование сервером опции сокета TCP_NODELAY при работе с постоянными соединениями. Опция tcp_nodelay может применяться в контексте секций http, server и location.

Параметр gzip управляет включением/отключением сжатия сервером данных, передаваемых клиенту. Включение этой опции увеличивает нагрузку на центральный процессор системы, однако позволяет существенно сократить объём передаваемых данных. Опция gzip может применяться в контексте секций http, server и location.

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

Продолжая тему о веб-сервере Nginx, сегодня рассмотрим настройку виртуального хоста, обслуживающего сайт со статическим контентом. То бишь, никаких CGI, Perl, PHP и еже с ними. Все примеры, упоминающиеся в статье, относятся и проверялись на Debian Linux 5.0 Lenny. Владельцев других систем это никак не должно смущать, поскольку меняться могут только пути к файлам конфигурации, в то время как их содержимое применимо к любой системе, на которой работает Nginx.

 

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

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

То есть, из каталога /etc/nginx/sites-enabled считывается содержимое всех файлов и применяется к текущей конфигурации сервера. Заглянув в упомянутый каталог, вы увидите там один файл default, являющийся символической ссылкой на файл /etc/nginx/sites-available/default. Тоже очень удобный подход: вам вдруг понадобилось отключить какой-то виртуальный хост, вы просто удаляете символическую ссылку, а на заморачиваетесь с перемещением файла туда-сюда.

Для «чистоты эксперимента» предлагаю удалить поставляемую с дистрибутивом символическую ссылку /etc/nginx/sites-enabled/default и начать, так сказать, с чистого листа.

Создайте файл /etc/nginx/sites-available/myvhost со следующим содержимым:

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

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

Опцией listen мы сообщаем Nginx номер порта, на котором наш виртуальный сервер должен ожидать соединений. По умолчанию значение этой опции равно 80, и в приведённом примере значение определено лишь для наглядности. Также при помощи этой опции можно указать не только номер порта, но и адрес сетевого интерфейса, к которому нужно «прицепить» данный сервер. Например следующие два примера «вешают» сервер на все доступные в системе TCP/IP-интерфейсы, на порт 8080:

Следующий пример связывает виртуальный сервер с определённым сетевым интерфейсом с IP-адресом 192.168.0.1, ожидая входящих соединений на порту 8080:

Опция server_name определяет имя виртуального сервера, которое используется при анализе веб-сервером HTTP-заголовка Host, приходящего от клиента. Именно эта опция и реализует настройку виртуальных хостов, базирующихся на имени. Например, вот так будет выглядеть фрагмент конфигурации двух виртуальных хостов на одном сервере:

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

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

С параметром access_log мы знакомились в предыдущей статье. Значение этого параметра определяет месторасположение и формат лог-файла доступа к контенту сервера.

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

Например, если вам необходимо, чтобы при обнаружении в URI подстроки /images/, Nginx не обращался в корневой каталог сервера, а искал файлы в каталоге /mnt/server2/var/www/images/, можно определить следующие два location:

В приведённых выше примерах использования location используется поиск подстроки в строке URI. То есть, подстрока /images/ будет найдена как в http://server/images/, так и http://server/my/images/. Если вам необходимо, чтобы Nginx выполнял поиск точного соответствия, для этого можно воспользоваться символом '=', который и заставляет сервер вести поиск таким образом:

Также вы можете определить подстроку, с которой должен начинаться URI. Для этого используется конструкция из двух символов '^~':

Ну и регулярные выражения, само-собой, поддерживаются и дают большую гибкость при описании location. Следующий location будет соответствовать всем URI, содержащим в конце имена графических файлов (без учёта регистра):

То же самое, но с учётом регистра:

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

Опция root своим значением определяет путь к корню документов виртуального сервера на файловой системе.

При помощи опции index вы можете определить имена файлов индексных документов, которые будет «отдавать» клиентам Nginx, если был запрошен доступ к каталогу. Если в каталоге такого файла не окажется и для данного location отключена опция autoindex, то клиент в ответ получит HTTP-код 403, говорящий о том, что доступ запрещён.

Опция autoindex настраивает поведение Nginx в случае, если в каталоге не найден запрашиваемый индексный файл. Если значением опции autoindex, как примере выше, является 'on', то сервер вернёт клиенту содержимое каталога в виде HTML-списка файлов. По умолчанию autoindex отключён, и будьте осторожны с ней, чтобы ненароком не вывесить на всеобщее обозрение критически-важную информацию.

Теперь, когда конфигурационный файл готов, необходимо сделать на него символическую ссылку из каталога /etc/nginx/sites-enabled/, чтобы при перезапуске Nginx подключил его содержимое в свою конфигурацию:

Далее, создайте каталог, определённый в качестве корня документов сервера параметром root:

Осталось перезапустить сервер:

И, если все настройки были выполнены без ошибок, вы сможете подключиться к вашему первому виртуальному серверу Nginx при помощи веб-браузера и увидеть пустой индекс файлов корневого каталога сервера. Попробуйте разместить пару статических html-файлов в каталоге /var/www/myshost и затем получить доступ к ним из вашего браузера.

В следующей статье мы рассмотрим конфигурацию SSL-сервера в Nginx.

В прошлый раз мы с вами разбирались с основами настройки Nginx в качестве сервера статического контента. Развивая начатую тему, сегодня мы рассмотрим настройку поддержки SSL в Nginx, т. е. научим наш сервер отдавать контент по защищённому HTTPS-соединению.

 

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

Ещё раз напоминаю на всякий случай: все примеры, приводимые в этой серии статей, применимы к Debian 5 «Lenny». То есть в вашем дистрибутиве Linux/UNIX могут отличаться пути к файлам конфигурации и init-сценариям. В остальном всё должно быть точно так же. В любом случае, вы всегда можете задать вопрос в комментариях или же попытаться разобраться самостоятельно.

Для работы HTTPS (который попросту говоря является HTTP, «завёрнутым» в SSL) на стороне сервера требуется наличие закрытого ключа шифрования, а также SSL (X.509) сертификата, содержащего в том числе открытый ключ, передаваемый клиенту в процессе работы протокола. Если у вас есть сертификат выпущенный для вас специально вы можете использовать его. Я же в этой статье буду использовать ключ и self-signed сертификат сгенерированные самостоятельно.

Для генерации X.509-сертификата и закрытого ключа шифрования понадобится установленный пакет openssl. В системе он, как правило, присутствует по умолчанию, однако если это не так, вы можете установить его традиционным в Debian способом:

Теперь создайте каталог, в котором будут храниться сертификат и ключ:

Перейдите в созданный каталог и создайте ключ и сертификат при помощи команды:

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

Теперь, когда все необходимые компоненты для организации работы SSL в вашем Nginx готовы, можно приступать к настройке самого Nginx. Создайте новый файл конфигурации, в каталоге /etc/nginx/sites-available с именем, например, secured и следующим содержимым:

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

Обратите внимание на значение параметра listen равное 443. Оно является таким потому, что веб-браузеры при использовании HTTPS-протокола по умолчанию будут пытаться соединяться именно на порт 443. Оправдаем их ожидания ;)

Установка значения опции ssl равным on включает в работу модуль сервера http_ssl_module (кстати, если вы собирали Nginx из исходных кодов, обратите внимание, чтобы вы собрали его с этим модулем, иначе SSL работать не будет).

При помощи опции ssl_certificate Nginx узнаёт о том, где хранится SSL-сертификат.

Значением параметра ssl_certificate_key опрделеяется местоположение файла закрытого ключа.

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

Теперь создайте root-каталог для хранения контента сервера и разместите там что-нибудь, вроде файла index.html с каким-нибудь содержимым.

Осталось «включить» наш новый безопасный виртуальный хост:

И перезапустить сервер:

Теперь попробуйте подключиться из вашего любимого браузера к вашему серверу по HTTPS-протоколу. Как правило, браузеры «гавкают» на сертификат, который невозможно проверить. Это логично, поскольку мы используем selfsigned-сертификат, не удостоверенный ни одним CA. В случае, если вы располагаете сертификатом выпущенным специально для вашего домена и подписанного центром сертификации, такого сообщения от вашего браузера вы получить, само-собой, не должны.