LXF95:Податливый Nginx

Перейти к: навигация, поиск

    ЧАСТЬ 2 Довольно теории – настало время пустить Nginx в дело.Валерия Комиссарова подскажет, как собрать его и настроить для работы в типовых ситуациях.

    Впрошлый раз мы познакомились с интересной разработкой под названием Nginx. Продукт создан нашим соотечествен- ником Игорем Сысоевым и представляет собой web-сервер, а также HTTP- и почтовый прокси-сервер. Мы детально рассмотрели особенности Nginx, его функциональность и принципы действия. Необходимая предварительная информация получена – перейдем к обсуждению процесса работы с Nginx: установки, настройки и использования.

Содержание 1 Nginx: инсталляция 2 На старт, внимание, марш! 3 Nginx как HTTP-сервер 4 Настройка Nginx как прокси-сервера 5 Заключение

Nginx: инсталляция

    Официальный сайт Nginx расположен на домашней странице его создателя, г-на Сысоева – [1], где всегда можно найти последнюю версию продукта, небольшой комплект документации, список произведенных изменений [2] и некоторую другую информацию. Текущая версия Nginx – 0.6.2 – находится в разделе «Скачать». Nginx работает только под UNIX-подобными системами (разновидности Linux, BSD, Solaris и др.), поэтому архив с дистрибутивом продукта запакован традиционным для них образом и имеет расширение .tar.gz. Доступны также пакеты RPM/DEB, ebuild’ы Gentoo и порты FreeBSD.
    В установке Nginx возможны два варианта развития событий: сборка из исходных текстов и установка из пакета. Первое происходит стандартным образом: ./configure, make и make install. Команда ./configure в данном случае принимает множество различных параметров – вот самые важные из них:

--with-http_ssl_module позволяет реализовать работу HTTP-сервера по протоколу HTTPS.
--without-http_proxy_module запрещает сборку прокси-модуля HTTP-сервера.
--without-http_gzip_module отменяет сборку модуля компрессии ответов HTTP-сервера. Полный список параметров можно найти на официальном сайте проекта или в выводе ./configure --help. Собрав Nginx, не спешите тут же его запускать: он еще не настроен и не знает, что нужно делать для решения нужных вам задач. Об этом мы сейчас и поговорим.

На старт, внимание, марш!

    Главный инструмент и помощник в настройке Nginx – конечно же, его конфигурационный файл, имя которого nginx.conf.
    Из чего он состоит? Из секций и директив (впрочем, деление условно), которые могут находиться как внутри секций, так и вне них (отметим, что расположение директивы внутри какой-либо секции еще не означает, что она обязательно не глобальная). По умолчанию (в стандартном файле конфигурации) часть директив закомментирована. В зависимости от стоящих перед вами задач, можно либо раскомментировать их, либо оставить все как есть.
    Чтобы правильно настроить Nginx, необходимо ответить на серьезный вопрос: для чего мы будем его использовать? Примерное определение можно найти, вспомнив материал первой статьи: Nginx хорош в качестве HTTP-сервера и прокси (как web, так и почтового). Вот и все. Но и HTTP-серверы бывают разные – с поддержкой PHP и без нее, поддерживающие SSL и нет, и т.д., и это следует учесть.
    Прежде чем переходить к рассмотрению процессов настройки каждого из выделенных нами направлений, скажем несколько слов о глобальных директивах конфигурационного файла Nginx.
    Глобальными эти директивы называются совсем не случайно. Они относится к работе всего Nginx в целом, а не к каким-то отдельным модулям. Так, директива worker_processes указывает максимальное количество рабочих процессов, user – группу и пользователя, от имени которого будут запускаться рабочие процессы, а include позволяет подключать другие файлы. На сегодняшний день директив такого типа у Nginx не так уж много – всего одиннадцать.
    Секции, которые могут находиться в файле конфигурации Nginx, относятся к модулям программы: ngx_http_core_module, ngx_http_access_module или любому другому.

Nginx как HTTP-сервер

    Допустим, вы хотите собрать незамысловатый web-сервер, использующийся для «отдачи» пользователям различного статического контента. Что необходимо сделать? В простейшем случае надо:

• Указать пользователя, от имени которого будет работать наш webсервер, в глобальной директиве user; количество рабочих процессов (директива worker_connections) и файл, куда будут записываться сообщения об ошибках (директива error_log). Также нужно указать тип передаваемых данных по умолчанию (директива default_type).

• Подумать над форматом записей log-файлов. Например, мож- но использовать такой формат записи, где будут отражены адрес пользователя, его браузер и т.п. Это делается с помощью директивы log_format.

• Помимо указания дополнительных параметров, относящихся к передаче данных (например, tcp_nodelay), нужно с помощью директи- вы listen указать порты, которые будет прослушивать наш web-сервер (т.е. ждать на них запросов от пользователей).

• С помощью секции location (модуль ngx_http_core_module) указать выбор нужных конфигураций в зависимости от URI запроса. В общем виде, файл конфигурации HTTP-сервера, «раздающего» статический контент, может выглядеть так, как показано ниже (указаны только основные директивы).
  

Подключаем входящий в дистрибутив Nginx файл соответствий расширений файлов MIME-типам:

http
{ include conf/mime.types;

    MIME-тип по умолчанию, например, text/plain. В нашем случае можно указать application/octet-stream. Стоит также обратить внимание на директивы модуля ngx_http_core_module, чьи имена содержат в себе «client»: client_body_buffer_size, client_body_timeout, client_max_body_ size и прочие – их назначение можно уточнить в документации:

default_type тип;

    Включение (on) следующей директивы позволяет осуществлять сжатие ответов сервера и «тянет» за собой нескольких сопутствующих директив: gzip_comp_level (уровень компрессии), gzip_buffers (буферы, используемые для сжатия). Советую включить, если ваш статический контент не является сжатым сам по себе:

gzip on/off;

    Разрешим Nginx использовать системный вызов sendfile(). Рекомендуется к использованию:

sendfile on/off;

    Включение или отключение алгоритма Нэгла (Nagle). См. man 7 tcp:

tcp_nodelay on/off;

    Время, по истечении которого keepalive-соединение будет разорвано сервером:

keepalive_timeout число;

    Следующее, что мы должны сделать – открыть секцию server. Укажем порт, прослушивающий Nginx, обычно 80:

server { listen номер порта;

    Директива, определяющая имя виртуального сервера: server_name имя; Если следующая директива находится в положении on, то в поле Content-Type заголовка ответа будет добавленa информация о коди- ровке, см. ngx_http_charset_module:

charset on/off;

    Данная секция (хотя корректнее ее называть все же директивой) определяет конфигурацию для всех запросов, удовлетворяющих указанному шаблону. Например, можно «приказать» Nginx обрабатывать те или иные запросы самостоятельно или, наоборот, передавать их back-end’у. Секции location – в сущности, главное в настройке Nginx как HTTP-сервера. Понятно, что нужно создать отдельную секцию (прости- те, директиву) location для обработки каждого типа запроса: } location шаблон URI запроса; Следуя указанным выше принципам, мы получим простейший, но зато корректно функционирующий web-сервер.

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

    Здесь многое идентично предыдущему случаю, но есть «усложне- ние»: директивы proxy_pass, proxy_connect_timeout, proxy_buffer_size и т.п. (модуль ngx_http_proxy_module). Как вы наверняка уже поняли, эти директивы нужно указывать в секции(-ях) location. Давайте попробуем собрать почтовый прокси-сервер: это самый интересный вариант. Чтобы все получилось, необходимо передать сценарию configure ключ --with-mail на этапе настройки исходных текстов. Принцип действия здесь прост: Nginx начинает работать с пользователем, «уточняет» корректность идентификационных данных у сервера авторизации, а затем приступает к передаче данных в оба «конца»: от пользователя к POP3/IMAP-серверу, координаты которого он получил у сервера авторизации, и обратно. Таким образом, нам потребу- ется указать порты, которые будет «слушать» Nginx, и задать адрес сервера авторизации (директива auth_http). Каким образом нужно отредактировать конфигурационный файл Nginx, чтобы он мог работать почтовым прокси-сервером? Давайте поступим вот как.
    Укажем URL HTTP-сервера авторизации:

нас интересуют модули ngx_mail_core_module,
ngx_mail_auth_http_module,
ngx_mail_proxy_module, ngx_mail_ssl_module.

mail { server_name имя;
auth_http URL-адрес;

    Далее можно привести список IMAP-расширений, отдаваемый кли- енту в ответ на команду CAPABILITY:

imap_capabilities список;

    Следующие директивы позволяют указать список POP3-расширений и задать расширенные методы аутентификации POP3-клиентов:

pop3_auth список;
pop3_capabilities список;

    То же самое можно сделать и для SMTP:

smtp_auth список;
smtp_capabilities список;

    Далее следует создать необходимое количество секций server, для каждой из которых указать директивы listen, protocol и т.д.
    Говоря о настройке Nginx, нельзя не упомянуть о виртуальных серверах. Они реализуются просто и изящно – путем создания требуемого количества секций server, в каждой из которых указываются «прослушиваемые» порты и имя виртуального сервера server_name (модуль ngx_http_core_module).
    Настроили? Можно запускать. Просто стартуем исполняемый файл Nginx от имени суперпользователя. Затем можно посмотреть список запущенных в системе процессов, и если все в порядке, увидеть про- цессы Nginx: главный (master) и несколько рабочих (worker). Как основ- ный, так и рабочие процессы поддерживают управление сигналами (например, SIGQUIT, SIGHUP, SIGWINCH и т.д.). С их помощью можно «заставить» Nginx заново обработать файл конфигурации, произвести ротацию журналов, обновить сервер и многое другое.

Заключение

    Некоторые читатели возмутятся: где же полные примеры конфигурационных файлов? Их нет; и это было сделано сознательно, т.к. идти по привычному пути не хотелось. А хотелось показать некий концептуальный подход к Nginx, не слишком «завязанный» на конкретные директивы и технические нюансы, и продемонстрировать, как профессионально и красиво построен Nginx с архитектурной точки зрения; насколько легко его настраивать и работать с ним. Можно отметить, что все директивы конфигурационного файла прекрасно рассорти- рованы по модулям; и те, и другие обладают удобными, интуитивно понятными названиями. Безусловно, Nginx еще есть куда развиваться. Его создатель навер- няка добавит в продукт немало примечательных функций; среди про- чих экспериментальных возможностей следует упомянуть модуль ngx_http_perl_module, реализующий встроенный интерпретатор Perl. Пожелаем проекту дальнейших успехов, а тем временем будем ждать первую версию продукта, и нормальную документацию к нему.