Nginx. Статический веб-сервер

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

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

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

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

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

1	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; } }

1 2 3 4 5 6 7 8 9 10 11

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

1	listen 8080

listen *:8080

1	listen *:8080

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

listen 192.168.0.1:8080

1	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 ... }

1 2 3 4 5 6 7 8 9 10 11 12 13

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

1	server_name example-1.com www.example-1.com www1.example-1.com

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

server_name example-1.com *.example-1.com

1	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/; }

1 2 3 4 5 6 7

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/; }

1 2 3

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

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

location ^~ /images/ { ... }

1 2 3

location ^~ /images/ {   ... }

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

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

1 2 3

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

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

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

1 2 3

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

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

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

# mkdir /var/www/myvhost

1	# mkdir /var/www/myvhost

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

# /etc/init.d/nginx restart

1	# /etc/init.d/nginx restart

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

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

• Гость • месяц назад

  Спасибо автору за статью. Но вот у меня че-та не получилось. В nginx.conf прописано include etc/sites-enabled/* В самой папке sites-enabled есть символьная ссылка на файл хоста Содержимое этого файла: server { listen 80; server_name domain.com 138.12.23.1; location / { root /etc/var/www/domain.com index index.html index.php } } Вроде всё просто но не идет. Почему? Подскажите что не так!?

  • ответить • поделиться
  • 
    Alexander Shepetko • месяц назад

    Перезапуске nginx происходит без ошибок? Каталог /etc/var/www/domain.com доступен для чтения пользователю, от имени которого запускается nginx? Что вы подразумеваете под "не идёт"?

    • ответить • поделиться
• 
  Дмитрий • год назад

  Все четко и грамотно изложено. Спасибо автору!

  • ответить • поделиться
• 
  Слава • год назад

  Спасибо огромное! Вы не представляете сколько я провёл времени в попытках настроить сервер! А тут всё ясно и по дело! Супер! Спасибо! Слава.