Привет! Сегодня мы поговорим о таком нужном понятии, как виртуальные хосты (Virtual Hosts) в web-сервере nginx. В качестве примера мы будем использовать операционную систему Ubuntu. Для других Linux-систем настройка будет выглядеть очень похоже. Эта статья-инструкция будет интересна, в основном, начинающим web-мастерам и администраторам, т.к. у них чаще всего возникает данный вопрос.

Виртуальный хост — это…

Для начала давайте дадим определение виртуальному хосту. Итак, виртуальный хост — это разделение адресного пространства web-сервера, например, по имени сайта, позволяющее запускать несколько web-сайтов/приложений на одном физическом сервере. Если говорить в терминологии документации nginx, виртуальный хост также называется «Server Block» , но для большего сходства с Apache я буду называть его единообразно, т.к. назначение у них одно и то же. И ещё одно соглашение — давайте то, что мы будем настраивать, для простоты называть сайтом.

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

Многие команды в этой инструкции требуют наличия у вашего пользователя прав sudoer’а на VPS. Поэтому, если у вас их нет, настроить виртуальные хосты у вас, к сожалению, вряд ли получится.

Предустановка

Сейчас я скажу вещь, которую необходимо знать каждому! Для того, чтоб настроить виртуальный хост в nginx, вам нужен установленный на вашей машине wеb-сервер nginx. Капитан Очевидность с нами! Если nginx у вас уже установлен, можете смело пропускать этот шаг и двигаться дальше по инструкции. Если же его у вас по каким-то причинам на машине всё ещё нет, введите в консоли команду:

Sudo apt-get install -y nginx

Опцию «-y» команде apt-get мы добавляем для того, чтоб не отвечать да-да-да на назойливые вопросы установщика, ведь мы уверены, что хотим поставить этот пакет и согласны с использованием занимаемого им места на диске. Если вы всё-таки не уверены, что со всем согласны, то не добавляйте эту опцию.

Создание директории сайта

Итак, прежде чем создавать виртуальный хост, давайте сделаем папку сайта, где разместим все файлики, с которыми будет работать наш web-сервер.

Путь к этой папке в конфигурации создаваемого хоста будет Document Root , своего рода контекстом, точкой изоляции, выше которой снаружи без предварительной настройки конфигурации подняться нельзя и относительно которой строятся пути до запрашиваемых файлов. С опцией «-p» у команды mkdir мы можем не заботиться о создании родительских директорий, они будут созданы автоматически:

Sudo mkdir -p /var/www/mysite.ru/public_html

Здесь мы используем реальный подтверждённый DNS домен с корректными записями, указывающими на нашу машину. Для создания виртуального хоста с незарегистрированным доменом, например, для локальной разработки, вам необходимо внести соответствующую запись в файле /etc/hosts. Подробнее об этом будет в конце статьи.

Права доступа

Сейчас права у нашей созданной папки есть только у root-пользователя. Мы должны дать права на директорию для нужного пользователя, чтоб не работать с ней постоянно в режиме супер-пользователя. Вы можете заменить пользователя «www-data», используемого ниже, на другого, но по умолчанию nginx работает от имени именно этого пользователя.

Sudo chown -R www-data:www-data /var/www/mysite.ru/public_html

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

Sudo chmod 755 /var/www

Мы подразумеваем, что работаем с VPS, на котором все пользователи ничего плохого не затевают или на котором есть только вы. Поэтому мы можем дать права 755 на папку /var/www. Если в вашем случае нельзя выдавать всем пользователям системы права на чтение этой директории, изучите вопрос с разграничением прав и настройте самостоятельно.

Теперь у вас всё с правами готово!

Создание страницы

Теперь нам необходимо разместить в нашей папке какие-нибудь статические файлы (HTML-страницы, картинки, скрипты, стили и т.д.), которые наш сервер будет раздавать. Давайте создадим HTML-страницу index.htm, которая будет на нашем сайте главной:

Sudo nano /var/www/mysite.ru/public_html/index.htm

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

Ура! Вы смогли настроить Virtual Host в nginx!

Сохраняем и выходим.

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

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

В nginx в директории /etc/nginx/sites-available есть шаблон для создаваемых конфигураций. Давайте скопируем его для нашего сайта:

Sudo cp /etc/nginx/sites-available/default /etc/nginx/sites-available/mysite.ru

Конфигурация виртуального хоста

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

Sudo nano /etc/nginx/sites-available/mysite.ru

Нам нужно внести изменения в текущую конфигурацию. В результате для нашего простого случая должно получиться примерно следующее:

Server { listen 80; root /var/www/mysite.ru/public_html; index index.html index.htm; server_name mysite.ru www.mysite.ru; }

От вас здесь требуется правильно указать путь к папке со статикой сайта и имя сервера, по которому вы будете обращаться к своему сайту. Если путь вы укажете неверно или не укажете вовсе, то вы не сможете настроить виртуальный хост. В качестве server_name вы также можете задать IP-адрес или несколько имён через пробел, по которым будет доступен хост, как мы и сделали.

Всё, с этим файлом мы закончили. Сохраняйте его и закрывайте.

Активация виртуального хоста

В nginx есть папки sites-available и sites-enabled. В первой хранятся конфигурации ВСЕХ виртуальных хостов, которые могут быть на данном сервере, а в директории sites-enabled символические ссылки на активные. Никто не запрещает в sites-enabled размещать оригинал файла конфигурации, а не ссылку, но это будет менее удобно, т.к. в случае необходимости отключения придётся либо удалять файл (тогда будет проблематично включить обратно), либо перемещать его в другую директорию (тогда мы должны помнить, куда мы перенесли). Гораздо проще грохнуть символическую ссылку!

Поэтому, теперь, чтоб активировать наш виртуальный хост, нам нужно создать символическую ссылку между директорией sites-available, где лежит наш файл конфигурации, и sites-enabled. В Apache для этого есть специальная команда a2ensite. В nginx такой команды нет, поэтому выполним следующее:

Sudo ln -s /etc/nginx/sites-available/mysite.ru /etc/nginx/sites-enabled/mysite.ru

Чтобы избежать «conflicting server name error» и быть уверенным, что ваш сайт отдаёт нужную информацию, можно из числа активных хостов удалить дефолтный:

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

Перезагрузка

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

Sudo nginx -t

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

Если в ответ вы получили примерно следующее:

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

То всё у вас хорошо и вы можете смело перезапускать сервер командой:

Sudo service nginx restart

В противном случае вам надо посмотреть файл конфигурации хоста. Что-то вы там не так указали.

Настройка локальных хостов

Если вы указали в качестве server name IP-адрес, вы можете пропустить этот шаг, т.к. настройка локального хоста вам не нужен, ваш виртуальный хост будет работать и без него. Но, если вы хотите работать с вашим виртуальным хостом без реального доменного имени, вы можете настроить локальные хосты на вашей машине. Как я уже говорил выше, это очень удобно, например, при разработке. Я могу создать mysite.dev, и на нём будет крутиться локальная нестабильная версия сайта. Для MacOS и Linux-систем надо выполнить следующую команду:

Sudo nano /etc/hosts

Если вы работаете под Windows, то файл с локальных хостов должен лежать примерно по этому пути C:\Windows\System32\drivers\etc\hosts.

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

12.34.56.789 mysite.ru 12.34.56.789 www.mysite.ru

Теперь до тех пор, пока эта запись не будет удалена, обращения по адресу mysite.ru будут получать информацию о данном хосте из этого файлика и перенаправлять вас к вашему удаленному серверу. Если сервер развернут локально, нужно написать вместо «12.34.56.789» «127.0.0.1».

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

Результаты

Теперь мы можем посмотреть результаты наших трудов! Вводим в браузере адрес http://mysite.ru или http://www.mysite.ru и любуемся созданной нами главной страницей из index.htm. Оба адреса должны показывать нашу главную страницу. Вот и всё! Наш виртуальный хост прекрасно работает.

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

Неплохой начальной точкой для настройки nginx является конфиг, который идёт в комплекте с дистрибутивом, но очень многие возможности этого сервера в нём даже не упоминаются. Значительно более подробный пример есть на сайте Игоря Сысоева: sysoev.ru/nginx/docs/example.html . Однако, давайте лучше попробуем собрать с нуля свой конфиг, с бриджем и поэтессами. :)

Начнём с общих настроек. Сначала укажем пользователя, от имени которого будет работать nginx (от рута работать плохо, все знают:))

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

Worker_processes 2;

Уточним, куда писать логи ошибок. Потом, для отдельных виртуальных серверов, этот параметр можно переопределить, так что в этот лог будут сыпаться только «глобальные» ошибки, например, связанные со стартом сервера.

Error_log /spool/logs/nginx/nginx.error_log notice; # уровень уведомлений "notice", конечно, можно менять

Теперь идёт очень интересная секция «events». В ней можно задать максимальное количество соединений, которые одновременно будет обрабатывать один процесс-воркер, и метод, который будет использоваться для получения асинхронных уведомлений о событиях в ОС. Конечно же, можно выбрать только те методы, которые доступны на вашей ОС и были включены при компиляции.

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

Модули работы с событиями:
- select и poll обычно медленнее и довольно сильно нагружают процессор, зато доступны практически везде, и работают практически всегда;
- kqueue и epoll - более эффективны, но доступны только во FreeBSD и Linux 2.6, соответственно;
- rtsig - довольно эффективный метод, и поддерживается даже очень старыми линуксами, но может вызывать проблемы при большом числе подключений;
- /dev/poll - насколько мне известно, работает в несколько более экзотических системах, типа соляриса, и в нём довольно эффективен;

Параметр worker_connections:
- Общее максимальное количество обслуживаемых клиентов будет равно worker_processes * worker_connections;
- Иногда могут сработать в положительную сторону даже самые экстремальные значения, вроде 128 процессов, по 128 коннектов на процесс, или 1 процесса, но с параметром worker_connections=16384. В последнем случае, впрочем, скорее всего понадобится тюнить ОС.

Events {
worker_connections 2048;
use kqueue; # У нас BSD:)
}

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

Http {
# Весь код ниже будет внутри этой секции %)
# ...
}

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

Системный вызов sendfile появился в Linux относительно недавно. Он позволяет отправить данные в сеть, минуя этап их копирования в адресное пространство приложения. Во многих случаях это существенно повышает производительность сервера, так что параметр sendfile лучше всегда включать.

Параметр keepalive_timeout отвечает за максимальное время поддержания keepalive-соединения, в случае, если пользователь по нему ничего не запрашивает. Обдумайте, как именно на вашем сайте посылаются запросы, и исправьте этот параметр. Для сайтов, активно использующих AJAX, соединение лучше держать подольше, для статических страничек, которые пользователи будут долго читать, соединение лучше разрывать пораньше. Учтите, что поддерживая неактивное keepalive-соединение, вы занимаете коннекшн, который мог бы использоваться по-другому. :)

Keepalive_timeout 15;

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

Proxy_buffers 8 64k;
proxy_intercept_errors on;
proxy_connect_timeout 1s;
proxy_read_timeout 3s;
proxy_send_timeout 3s;

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

# default virtual host
server {
listen 80 default;
server_name localhost;
deny all;
}

Далее может следовать одна (или несколько) секций «server». В каждой из них описывается виртуальный хост (чаще всего, name-based). Для владельцев множества сайтов на одном хостинге, или для хостеров здесь может быть что-то, типа директивы

Include /spool/users/nginx/*.conf;

Остальные, скорее всего опишут свой виртуальный хост прямо в основном конфиге.

Server {
listen 80;

# Обратите внимание, в директиве server_name можно указать несколько имён одновременно.
server_name myserver.ru myserver.com;
access_log /spool/logs/nginx/myserver.access_log timed;
error_log /spool/logs/nginx/myserver.error_log warn;
# ...

Установим кодировку для отдачи по-умолчанию.

Charset utf-8;

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

Client_max_body_size 1m;

Включим для сервера SSI и попросим для SSI-переменных резервировать не более 1 килобайта.

Ssi on;
ssi_value_length 1024;

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

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

Способ хранения файлов конфигурации

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

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

Include /etc/nginx/sites-enabled/*;

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

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

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

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

Server { listen 80; server_name myvhost; access_log /var/log/nginx/myvhost.log; location / { root /var/www/myvhost/; index index.htm index.html; autoindex on; } }

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

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

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

Listen 8080 listen *:8080

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

Listen 192.168.0.1:8080

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

Server { ... listen 80; server_name example-1.com ... } server { ... listen 80; server_name example-2.com ... }

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

Server_name example-1.com www.example-1.com www1.example-1.com

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

Server_name example-1.com *.example-1.com

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

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

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

Location / { root /var/www/myvhost/; } location /images/ { root /mnt/server2/var/www/; }

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

Location = /images/ { root /mnt/server2/var/www/; }

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

Location ^~ /images/ { ... }

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

Location ~* \.(gif|jpg|jpeg)$ { ... }

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

Location ~ \.(gif|jpg|jpeg)$ { ... }

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

1. Выполняется поиск правила, начинающегося с "=" . Как только такое правило будет найдено, дальнейший поиск будет прекращён.
2. Выполняется поиск «обычных» правил, т. е. не регулярных выражений. Если среди них будет найдено правило, начинающееся с "^~" , дальнейший поиск будет прекращён.
3. Обрабатываются регулярные выражения в том порядке, в котором они встречаются в файле конфигурации.
4. Если будет найдено соответствие по п. 3, то будет использоваться именно этот location, в противном случае будет использоваться location, найденный в п. 2.

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

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

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

Перезапуск сервера

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

# ln -s /etc/nginx/sites-available/myvhost /etc/nginx/sites-enabled/myvhost

# mkdir /var/www/myvhost

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

# /etc/init.d/nginx restart

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

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

И другие). Текущая версия, 0.6.x, рассматривается как стабильная с точки зрения надежности, а релизы из ветки 0.7 считаются нестабильными. При этом важно заметить, что функциональность некоторых модулей будет меняться, вследствие чего могут меняться и директивы, поэтому обратной совместимости в nginx до версии 1.0.0 не гарантируется.

Чем же nginx так хорош и почему его так любят администраторы высоконагруженных проектов? Почему бы просто не использовать Apache?

Почему Apache - плохо?

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

1. Последовательная. Сервер открывает слушающий сокет и ждет, когда появится соединение (во время ожидания он находится в заблокированном состоянии). Когда приходит соединение, сервер обрабатывает его в том же контексте, закрывает соединение и снова ждет соединения. Очевидно, это далеко не самый лучший способ, особенно когда работа с клиентом ведется достаточно долго и подключений много. Кроме того, у последовательной модели есть еще много недостатков (например, невозможность использования нескольких процессоров), и в реальных условиях она практически не используется.
2. Многопроцессная (многопоточная). Сервер открывает слушающий сокет. Когда приходит соединение, он принимает его, после чего создает (или берет из пула заранее созданных) новый процесс или поток, который может сколь угодно долго работать с соединением, а по окончании работы завершиться или вернуться в пул. Главный поток тем временем готов принять новое соединение. Это наиболее популярная модель, потому что она относительно просто реализуется, позволяет выполнять сложные и долгие вычисления для каждого клиента и использовать все доступные процессоры. Пример ее использования - Web-сервер Apache. Однако у этого подхода есть и недостатки: при большом количестве одновременных подключений создается очень много потоков (или, что еще хуже, процессов), и операционная система тратит много ресурсов на переключения контекста. Особенно плохо, когда клиенты очень медленно принимают контент. Получаются сотни потоков или процессов, занятых только отправкой данных медленным клиентам, что создает дополнительную нагрузку на планировщик ОС, увеличивает число прерываний и потребляет достаточно много памяти.
3. Неблокируемые сокеты/конечный автомат. Сервер работает в рамках одного потока, но использует неблокируемые сокеты и механизм поллинга. Т.е. сервер на каждой итерации бесконечного цикла выбирает из всех сокетов тот, что готов для приема/отправки данных с помощью вызова select(). После того, как сокет выбран, сервер отправляет на него данные или читает их, но не ждет подтверждения, а переходит в начальное состояние и ждет события на другом сокете или же обрабатывает следующий, в котором событие произошло во время обработки предыдущего. Данная модель очень эффективно использует процессор и память, но достаточно сложна в реализации. Кроме того, в рамках этой модели обработка события на сокете должна происходить очень быстро - иначе в очереди будет скапливаться много событий, и в конце концов она переполнится. Именно по такой модели работает nginx. Кроме того, он позволяет запускать несколько рабочих процессов (так называемых workers), т.е. может использовать несколько процессоров.

Итак, представим следующую ситуацию: на HTTP-сервер с каналом в 1 Гбит/с подключается 200 клиентов с каналом по 256 Кбит/с:

Что происходит в случае Apache? Создается 200 потоков/процессов, которые относительно быстро генерируют контент (это могут быть как динамические страницы, так и статические файлы, читаемые с диска), но медленно отдают его клиентам. Операционная система вынуждена справляться с кучей потоков и блокировок ввода/вывода.

Nginx в такой ситуации затрачивает на каждый коннект на порядок меньше ресурсов ОС и памяти. Однако тут выявляется ограничение сетевой модели nginx: он не может генерировать динамический контент внутри себя, т.к. это приведет к блокировкам внутри nginx. Естественно, решение есть: nginx умеет проксировать такие запросы (на генерирование контента) на любой другой веб-сервер (например, все тот же Apache) или на FastCGI-сервер.

Рассмотрим механизм работы связки nginx в качестве «главного» сервера и Apache в качестве сервера для генерации динамического контента:

Nginx принимает соединение от клиента и читает от него весь запрос. Тут следует отметить, что пока nginx не прочитал весь запрос, он не отдает его на «обработку». Из-за этого обычно «ломаются» практически все индикаторы прогресса закачки файлов - впрочем, существует возможность починить их с помощью стороннего модуля upload_progress (это потребует модификации приложения).

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

Такая схема называется фронтэнд + бэкенд (frontend + backend) и применяется очень часто.

Установка

Т.к. nginx только начинает завоевывать популярность, имеются некоторые проблемы с бинарными пакетами, так что будьте готовы к тому, что его придется компилировать самостоятельно. С этим обычно не возникает проблем, надо лишь внимательно прочитать вывод команды./configure —help и выбрать необходимые вам опции компиляции, например такие:

./configure \
—prefix=/opt/nginx-0.6.x \ # префикс установки
—conf-path=/etc/nginx/nginx.conf \ # расположение конфигурационного файла
—pid-path=/var/run/nginx.pid \ # … и pid-файла
—user=nginx \ # имя пользователя под которым будет запускаться nginx
—with-http_ssl_module —with-http_gzip_static_module —with-http_stub_status_module \ # список нужных
—without-http_ssi_module —without-http_userid_module —without-http_autoindex_module —without-http_geo_module —without-http_referer_module —without-http_memcached_module —without-http_limit_zone_module # … и не нужных модулей

После конфигурирования стоит запустить стандартный make && make install, после чего можно пользоваться nginx.

Кроме того в Gentoo вы можете воспользоваться ebuild’ом из стандартного дерева портов; в RHEL/CentOS репозиторием epel (в нем расположени nginx 0.6.x) или srpm для версии 0.7, который можно скачать отсюда: http://blogs.mail.ru/community/nginx ; в Debian можно воспользоваться пакетом nginx из ветки unstable.

Конфигурационный файл

Конфигурационный файл nginx очень удобен и интуитивно понятен. Называется он обычно nginx.conf и распологается в $prefix/conf/ если расположение не было переопределено при компиляции. Я люблю класть его в /etc/nginx/, также делают и разработчики всех пакетов упомянутых выше.

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

user nginx; # имя пользователя, с правами которого будет запускаться nginx
worker_processes 1; # количество рабочих процессов
events {
<…> # в этом блоке указывается механизм поллинга который будет использоваться (см. ниже) и максимальное количество возможных подключений
}

Http {
<глобальные директивы http-сервера, например настройки таймаутов и т.п.>;
<почти все из них можно переопределить для отдельного виртуального хоста или локейшена>;

# описание серверов (это то что в apache называется VirtualHost)
server {
# адрес и имя сервера
listen *:80;
server_name aaa.bbb;

<Директивы сервера. Здесь обычно указывают расположение докуменов (root), редиректы и переопределяют глобальные настройки>;

# а вот так можно определить location, для которого можно также переопределить практически все директивы указаные на более глобальных уровнях
location /abcd/ {
<директивы>;
}
# Кроме того, можно сделать location по регулярному выражению, например так:
location ~ \.php$ {
<директивы>;
}
}

# другой сервер
server {
listen *:80;
server_name ccc.bbb;

<директивы>
}
}

Обратите внимание на то, что каждая директива должна оканчиваться точкой с запятой.
Обратное проксирование и FastCGI

Итак, выше мы рассмотрели преимущества схемы frontend + backend, разобрались с установкой, структурой и синтаксисом конфигурационного файла, рассмотрим тепеть как реализовать обратное проксирование в nginx.

А очень просто! Например так:

location / {
proxy_pass http://1.2.3.4:8080;
}

В этом примере все запросы попадающие в location / будут проксироваться на сервер 1.2.3.4 порт 8080. Это может быть как apache, так и любой другой http-сервер.

Однако тут есть несколько тонкостей, связанных с тем, что приложение будет считать, что, во-первых, все запросы приходят к нему с одного IP-адреса (что может быть расценено, например, как попытка DDoS-атаки или подбора пароля), а во-вторых, считать, что оно запущено на хосте 1.2.3.4 и порту 8080 (соответственно, генерировать неправильные редиректы и абсолютные ссылки). Чтобы избежать этих проблем без необходимости переписывания приложения, мне кажется удобной следующая конфигурация:
Nginx слушает внешний интерфейс на порту 80.

Если бэкенд (допустим, Apache) расположен на том же хосте, что и nginx, то он «слушает» порт 80 на 127.0.0.1 или другом внутреннем IP-адресе.

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

server {
listen 4.3.2.1:80;
# устанавливаем заголовок Host и X-Real-IP: к каждому запросу отправляемому на backend
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header Host $host:$proxy_port;
# или «proxy_set_header Host $host;», если приложение будет дописывать:80 ко всем ссылкам
}

Для того, чтобы приложение различало IP-адреса посетителей, нужно либо поставить модуль mod_extract_forwarded (если оно исполняется сервером Apache), либо модифицировать приложение так, чтобы оно брало информацию о IP-адресе пользователя из HTTP-заголовка X-Real-IP.

Другой вариант бэкенд - это использование FastCGI . В этом случае конфигурация nginx будет выглядеть примерно так:

server {
<…>

# location, в который будут попадать запросы на php-скрипты
location ~ .php$ {
fastcgi_pass 127.0.0.1:8888; # определяем адрес и порт fastcgi-сервера,
fastcgi_index index.php; # …индексный файл

# и некоторые параметры, которые нужно передать серверу fastcgi, чтобы он понял какой скрипт и с какими параметрами выполнять:
fastcgi_param SCRIPT_FILENAME /usr/www/html$fastcgi_script_name; # имя скрипта
fastcgi_param QUERY_STRING $query_string; # строка запроса
# и параметры запроса:
fastcgi_param REQUEST_METHOD $request_method;
fastcgi_param CONTENT_TYPE $content_type;
fastcgi_param CONTENT_LENGTH $content_length;
}

# благодяря тому что локейшены с регулярными выражениями обладают большим «приоритетом», сюда будут попадать все не-php запросы.

location / {
root /var/www/html/
}

Статика

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

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

server {
listen *:80;
server_name myserver.com;

Location / {
proxy_pass


«>http://127.0.0.1:80;

}

# предположим что все статичные файлы лежат в /files
location /files/ {
root /var/www/html/; # указываем путь на фс
expires 14d; # добавляем заголовок Expires:
error_page 404 = @back; # а если файл не найден, отправляем его в именованный локейшн @back
}

# запросы из /files, для которых не было найдено файла отправляем на backend, а он может либо сгенерировать нужный файл, либо показать красивое сообщение об ошибке
location @back {
proxy_pass
» title=»http://127.0.0.1:80;

«>http://127.0.0.1:80;

}

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

location ~* ^.+\.(jpg|jpeg|gif|png|ico|css|zip|tgz|gz|rar|bz2|doc|xls|exe|pdf|ppt|txt|tar|wav|bmp|rtf|js)$ {
# аналогично тому что выше, только в этот location будут попадать все запросы оканчивающиеся на одно из указаных суффиксов
root /var/www/html/;
error_page 404 = @back;
}

К сожалению, в nginx не реализована асинхронная работа с файлами. Иными словами, nginx worker блокируется на операциях ввода-вывода. Так что если у вас очень много статических файлов и, в особенности, если они читаются с разных дисков, лучше увеличивать количество рабочих процессов (до числа, которое в 2-3 раза больше, чем суммарное число головок на диске). Это, конечно, ведет к увеличению нагрузки на ОС, но в целом производительность увеличивается. Для работы с типичным количеством статики (не очень большое количество сравнительно небольших файлов: CSS, JavaScript, изображения) вполне хватает одного-двух рабочих процессов.

To be continued

Ссылки

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