Центр знаний DevOps
Центр знаний DevOps

Виртуальные хосты Nginx: Размещение нескольких веб-сайтов на одном сервере

Раскройте потенциал виртуальных хостов Nginx (блоков сервера) для эффективного размещения нескольких веб-сайтов или поддоменов на одном сервере. Это руководство представляет собой всеобъемлющий, пошаговый учебник, охватывающий настройку каталогов, создание файлов конфигурации, включение блоков сервера и тестирование Nginx. Изучите лучшие практики для поддоменов, блоков сервера по умолчанию, интеграции HTTPS и выделенного ведения логов. Практические примеры и основные советы по устранению неполадок помогут вам освоить хостинг нескольких сайтов на Nginx, оптимизировать использование ресурсов и упростить управление веб-сервером.

33 просмотров

Виртуальные хосты Nginx: размещение нескольких веб-сайтов на одном сервере

Современная веб-инфраструктура часто требует возможности обслуживать несколько веб-сайтов или веб-приложений с одного экземпляра сервера. Это не только оптимизирует использование ресурсов, но и упрощает управление, а также снижает эксплуатационные расходы. Nginx, известный своей высокой производительностью, стабильностью, богатым набором функций и низким потреблением ресурсов, достигает этого с помощью так называемых блоков сервера (server blocks), которые в мире Apache часто называют виртуальными хостами (virtual hosts).

В этом подробном руководстве мы расскажем вам о процессе настройки виртуальных хостов Nginx для эффективного управления и обслуживания нескольких отдельных доменных имен или субдоменов на одном сервере Nginx. Независимо от того, размещаете ли вы example.com и anothersite.org, или основной сайт с субдоменами, такими как blog.example.com и shop.example.com, освоение блоков сервера Nginx является фундаментальным навыком для любого системного администратора или разработчика. К концу этой статьи вы получите четкое представление и практические примеры для настройки вашего сервера Nginx для многосайтового хостинга.

Понимание блоков сервера Nginx (виртуальных хостов)

По своей сути, блок сервера Nginx — это директива конфигурации, определенная в файле конфигурации Nginx (nginx.conf или включенных файлах). Каждый блок server определяет конфигурацию для конкретного виртуального хоста, предписывая Nginx, как реагировать на запросы для определенного домена или набора доменов. Nginx использует директиву listen для указания IP-адреса и порта, который он должен прослушивать, и директиву server_name для идентификации доменных имен или хостов, на которые должен отвечать этот блок сервера.

Когда поступает запрос, Nginx проверяет заголовок Host HTTP-запроса и сравнивает его с директивами server_name настроенных блоков сервера. Затем он обслуживает контент, определенный в соответствующем блоке сервера. Если совпадений server_name не найдено, Nginx обычно обращается к блоку сервера по умолчанию (default server block) (первому блоку server или тому, который явно отмечен как default_server).

Предварительные требования

Прежде чем начать, убедитесь, что у вас есть следующее:

  1. Установленный Nginx: Nginx должен быть установлен и запущен на вашем сервере. Если нет, вы можете установить его с помощью системного менеджера пакетов (например, sudo apt update && sudo apt install nginx в Ubuntu/Debian, sudo yum install nginx в CentOS/RHEL).
  2. Доменные имена: Вам необходимо как минимум два доменных имени (например, example1.com и example2.com) или субдомена (например, blog.example.com и app.example.com), которые вы хотите разместить. DNS A/AAAA записи этих доменов должны указывать на публичный IP-адрес вашего сервера.
  3. Базовая структура каталогов: План того, где будут находиться файлы вашего веб-сайта. Распространенной практикой является /var/www/yourdomain.com/html.
  4. Права Sudo: Вам потребуется доступ sudo для изменения файлов конфигурации Nginx.

Пошаговое руководство по настройке

Давайте настроим два виртуальных хоста: example1.com и example2.com.

Шаг 1: Создание структуры каталогов для веб-сайтов

Сначала создайте корневые каталоги для каждого из ваших веб-сайтов. Здесь будут храниться их HTML, CSS, JavaScript и другие статические файлы. Распространенное местоположение — /var/www/.

sudo mkdir -p /var/www/example1.com/html
sudo mkdir -p /var/www/example2.com/html

# Установите права собственности для вашего пользователя (замените $USER на ваше имя пользователя), чтобы разрешить редактирование
sudo chown -R $USER:$USER /var/www/example1.com/html
sudo chown -R $USER:$USER /var/www/example2.com/html

# Установите права на чтение для веб-сервера
sudo chmod -R 755 /var/www

Затем создайте простой файл index.html в каждом каталоге для проверки настройки:

Для /var/www/example1.com/html/index.html:

<!-- /var/www/example1.com/html/index.html -->
<!DOCTYPE html>
<html>
<head>
    <title>Welcome to Example1.com!</title>
</head>
<body>
    <h1>Success! This is Example1.com.</h1>
    <p>This virtual host is working correctly.</p>
</body>
</html>

Для /var/www/example2.com/html/index.html:

<!-- /var/www/example2.com/html/index.html -->
<!DOCTYPE html>
<html>
<head>
    <title>Welcome to Example2.com!</title>
</head>
<body>
    <h1>Success! This is Example2.com.</h1>
    <p>This virtual host is also working!</p>
</body>
</html>

Шаг 2: Создание файлов конфигурации блоков сервера Nginx

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

Создайте новый файл конфигурации для example1.com:

sudo nano /etc/nginx/sites-available/example1.com.conf

Добавьте следующее содержимое:

# /etc/nginx/sites-available/example1.com.conf
server {
    listen 80;
    listen [::]:80;

    root /var/www/example1.com/html;
    index index.html index.htm index.nginx-debian.html;

    server_name example1.com www.example1.com;

    location / {
        try_files $uri $uri/ =404;
    }

    access_log /var/log/nginx/example1.com_access.log;
    error_log /var/log/nginx/example1.com_error.log;
}

Пояснение директив:

  • listen 80;: Nginx прослушивает порт 80 (стандартный HTTP). listen [::]:80; предназначен для IPv6.
  • root /var/www/example1.com/html;: Указывает корневой каталог документов для этого блока сервера. Nginx будет искать файлы внутри этого каталога.
  • index index.html ...;: Определяет файл по умолчанию, который Nginx должен обслуживать при запросе каталога (например, когда кто-то посещает example1.com/).
  • server_name example1.com www.example1.com;: Это критически важно. Он указывает Nginx отвечать на запросы для example1.com или www.example1.com, используя конфигурацию этого блока сервера.
  • location / { ... }: Блок, определяющий, как обрабатывать запросы для конкретных URI. try_files пытается обслужить файл напрямую ($uri), затем каталог ($uri/) и, наконец, возвращает ошибку 404 Not Found.
  • access_log и error_log: Определяют отдельные файлы журналов для этого конкретного сайта, что является хорошей практикой для упрощения отладки и аналитики.

Теперь создайте аналогичный файл конфигурации для example2.com:

sudo nano /etc/nginx/sites-available/example2.com.conf

Добавьте следующее содержимое:

# /etc/nginx/sites-available/example2.com.conf
server {
    listen 80;
    listen [::]:80;

    root /var/www/example2.com/html;
    index index.html index.htm index.nginx-debian.html;

    server_name example2.com www.example2.com;

    location / {
        try_files $uri $uri/ =404;
    }

    access_log /var/log/nginx/example2.com_access.log;
    error_log /var/log/nginx/example2.com_error.log;
}

Шаг 3: Включение блоков сервера

Чтобы включить эти конфигурации, создайте символические ссылки из каталога sites-available в каталог sites-enabled. Это указывает Nginx включать эти файлы при запуске.

sudo ln -s /etc/nginx/sites-available/example1.com.conf /etc/nginx/sites-enabled/
sudo ln -s /etc/nginx/sites-available/example2.com.conf /etc/nginx/sites-enabled/

Шаг 4: Тестирование конфигурации Nginx

Крайне важно проверить конфигурацию Nginx на наличие синтаксических ошибок перед перезагрузкой. Это предотвратит сбой перезапуска Nginx из-за опечатки.

sudo nginx -t

Вы должны увидеть примерно такой вывод, указывающий на успех:

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

Если вы видите какие-либо ошибки, исправьте их в соответствующих файлах конфигурации и снова запустите sudo nginx -t, пока проверка не будет пройдена.

Шаг 5: Перезапуск Nginx

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

sudo systemctl reload nginx
# Или, если reload не работает или для свежих установок:
sudo systemctl restart nginx

Шаг 6: Обновление DNS-записей

Убедитесь, что DNS A-записи для example1.com, www.example1.com, example2.com и www.example2.com указывают на IP-адрес вашего сервера Nginx. Без правильных записей DNS ваш браузер не будет знать, где найти ваши веб-сайты.

После завершения распространения DNS (что может занять от нескольких минут до нескольких часов) вы сможете посетить http://example1.com и http://example2.com в своем веб-браузере и увидеть соответствующие страницы index.html.

Расширенные сценарии и лучшие практики

Размещение субдоменов

Размещение субдоменов (например, blog.example.com, shop.example.com) работает точно так же, как размещение отдельных доменов. Вам просто нужно определить новый блок сервера с субдоменом в качестве server_name.

Пример для blog.example.com:

# /etc/nginx/sites-available/blog.example.com.conf
server {
    listen 80;
    listen [::]:80;

    root /var/www/blog.example.com/html;
    index index.html;

    server_name blog.example.com;

    location / {
        try_files $uri $uri/ =404;
    }
}

Не забудьте создать каталог (/var/www/blog.example.com/html), создать index.html, создать символическую ссылку и перезагрузить Nginx.

Блок сервера по умолчанию (The Default Server Block)

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

Как правило, первый блок server в вашем nginx.conf или sites-enabled неявно является блоком по умолчанию. Вы можете явно установить его, используя default_server:

server {
    listen 80 default_server;
    listen [::]:80 default_server;

    server_name _;
    # Подчеркивание `_` — это несуществующее доменное имя, которое никогда не совпадет с реальным запросом.
    # Вы также можете использовать localhost.

    root /var/www/default_site/html;
    index index.html;

    location / {
        return 444; # Вернуть ошибку 444, специфичную для Nginx (нет ответа) для неизвестных хостов
        # Или обслуживать общую целевую страницу:
        # try_files $uri $uri/ =404;
    }
}

Предупреждение: Если вы определяете блок default_server, убедитесь, что только один блок server на данном порту listen имеет флаг default_server, иначе Nginx запишет предупреждение в журнал.

Защита виртуальных хостов с помощью HTTPS (SSL/TLS)

Для production-веб-сайтов включение HTTPS является обязательным. Это включает в себя получение сертификата SSL/TLS (например, через Let's Encrypt с использованием Certbot) и настройку Nginx для прослушивания порта 443 с использованием сертификата.

Типичный блок сервера HTTPS выглядит следующим образом (после получения сертификатов):

server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;

    server_name example1.com www.example1.com;

    root /var/www/example1.com/html;
    index index.html;

    ssl_certificate /etc/letsencrypt/live/example1.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example1.com/privkey.pem;

    # Включите другие конфигурации SSL (шифры, протоколы и т. д.)
    include /etc/nginx/snippets/ssl-params.conf;
    include /etc/nginx/snippets/force-ssl.conf; # Опционально: перенаправляет HTTP на HTTPS

    location / {
        try_files $uri $uri/ =404;
    }
}

# Опционально: перенаправление HTTP на HTTPS для этого домена
server {
    listen 80;
    listen [::]:80;
    server_name example1.com www.example1.com;
    return 301 https://$host$request_uri;
}

Распространено использование отдельного блока сервера HTTP, единственной целью которого является перенаправление всего трафика на его аналог HTTPS.

Журналирование для каждого сайта

Как показано в примерах, выделение отдельных файлов access_log и error_log для каждого виртуального хоста является лучшей практикой. Это значительно упрощает отладку проблем и анализ трафика для отдельных веб-сайтов без необходимости просеивания объединенных журналов.

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

Для крупных развертываний рассмотрите возможность организации файлов конфигурации Nginx следующим образом:

  • nginx.conf: Основная конфигурация, включает conf.d/*.conf и sites-enabled/*.
  • conf.d/: Общие настройки для всего сервера (например, Gzip, кэширование).
  • snippets/: Повторно используемые фрагменты конфигурации Nginx (например, параметры SSL, общие блоки location).
  • sites-available/: Отдельные блоки server для каждого веб-сайта.
  • sites-enabled/: Символические ссылки на активные конфигурации в sites-available/.

Устранение распространенных проблем

  • Ошибка 403 Forbidden (Запрещено): Обычно это означает, что Nginx не имеет прав на чтение файлов или каталогов вашего веб-сайта. Тщательно проверьте права доступа к файлам и каталогам (например, sudo chmod -R 755 /var/www/yourdomain.com/html) и убедитесь, что пользователь Nginx, обычно www-data или nginx, может их читать.
  • Ошибка 404 Not Found (Не найдено): Убедитесь, что директива root в вашем блоке сервера указывает на правильный каталог и что ваш файл index.html существует в этом месте. Также убедитесь, что try_files настроен правильно.
  • Загружается неправильный сайт: Это часто указывает на проблему с директивой server_name. Убедитесь, что server_name точно соответствует доменному имени, к которому вы пытаетесь получить доступ (включая www. или субдомены). Также проверьте свои DNS-записи.
  • Сбой запуска/перезагрузки Nginx: Всегда используйте sudo nginx -t для проверки конфигурации перед попыткой перезагрузки или перезапуска Nginx. Сообщения об ошибках укажут строку и файл, где произошла синтаксическая ошибка.
  • Проблемы с DNS: Если вы можете получить доступ к своему сайту по IP-адресу, но не по доменному имени, это почти наверняка проблема с DNS. Используйте dig или nslookup, чтобы убедиться, что A-записи вашего домена указывают на правильный IP-адрес сервера.

Заключение

Виртуальные хосты Nginx (блоки сервера) предоставляют мощный и гибкий способ размещения нескольких веб-сайтов на одном сервере. Правильно настроив блоки server с соответствующими директивами listen, server_name, root и location, вы сможете эффективно управлять разнообразными веб-ресурсами. Такой подход не только экономит ресурсы, но и централизует администрирование сервера.

Благодаря базовым знаниям и практическим шагам, изложенным в этом руководстве, вы теперь готовы к настройке и управлению несколькими доменами на вашем сервере Nginx. Не забывайте всегда тестировать свои конфигурации, защищать свои сайты с помощью HTTPS и следовать передовым методам журналирования и структуры каталогов для создания надежной и удобной в обслуживании веб-среды. Отсюда вы можете продолжить изучение возможностей Nginx, таких как обратное проксирование, балансировка нагрузки и кэширование, для повышения производительности и надежности вашего веб-сервера.