Поиск по сайту:

Как настроить серверные блоки Nginx (виртуальные хосты) в Ubuntu 16.04


Введение

При использовании веб-сервера Nginx серверные блоки (аналогичные виртуальным хостам в Apache) могут использоваться для инкапсуляции деталей конфигурации и размещения более одного домена на одном сервере.

В этом руководстве мы обсудим, как настроить серверные блоки в Nginx на сервере Ubuntu 16.04.

Предпосылки

В этом руководстве мы будем использовать пользователя без полномочий root с привилегиями sudo. Если у вас нет такого настроенного пользователя, вы можете создать его, следуя нашему руководству по начальной настройке сервера Ubuntu 16.04.

Вам также потребуется установить Nginx на вашем сервере. Эта процедура описана в следующих руководствах:

  • Как установить Nginx в Ubuntu 16.04: используйте это руководство, чтобы настроить Nginx самостоятельно.
  • Как установить Linux, Nginx, MySQL, PHP (стек LEMP) в Ubuntu 16.04: используйте это руководство, если вы будете использовать Nginx в сочетании с MySQL и PHP.

Когда вы выполнили эти требования, вы можете продолжить работу с этим руководством.

Пример конфигурации

В демонстрационных целях мы собираемся настроить два домена с нашим сервером Nginx. В этом руководстве мы будем использовать доменные имена test.com.

Примечание. Для получения дополнительной информации о настройке домена с помощью DigitalOcean см. нашу документацию по продуктам «Домены и DNS».

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

Шаг 1 — Настройка новых корневых каталогов документов

По умолчанию в Nginx в Ubuntu 16.04 включен один серверный блок. Он настроен на обслуживание документов из каталога /var/www/html.

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

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

Нам нужно создать эти каталоги для каждого из наших сайтов. Флаг -p указывает mkdir создать все необходимые родительские каталоги по пути:

  1. sudo mkdir -p /var/www/example.com/html
  2. sudo mkdir -p /var/www/test.com/html

Теперь, когда у нас есть наши каталоги, мы передадим право собственности на веб-каталоги нашей обычной учетной записи пользователя. Это позволит нам писать им без sudo.

Примечание. В зависимости от ваших потребностей вам может потребоваться снова настроить разрешения или владельца папок, чтобы предоставить определенный доступ пользователю www-data. Например, динамические сайты часто нуждаются в этом. Конкретные требования к разрешениям и владению полностью зависят от вашей конфигурации. Следуйте рекомендациям для конкретной технологии, которую вы используете.

Мы можем использовать переменную окружения $USER, чтобы назначить владельца учетной записи, в которую мы сейчас вошли (убедитесь, что вы не вошли в систему как root). Это позволит нам легко создавать или редактировать содержимое в этом каталоге:

  1. sudo chown -R $USER:$USER /var/www/example.com/html
  2. sudo chown -R $USER:$USER /var/www/test.com/html

Разрешения наших корневых веб-сайтов уже должны быть правильными, если вы не изменили значение umask, но мы можем убедиться, набрав:

  1. sudo chmod -R 755 /var/www

Наша структура каталогов теперь настроена, и мы можем двигаться дальше.

Шаг 2 — Создание образцов страниц для каждого сайта

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

Создайте файл index.html в своем первом домене:

  1. nano /var/www/example.com/html/index.html

Внутри файла мы создадим действительно простой файл, который указывает, к какому сайту мы обращаемся в данный момент. Это будет выглядеть так:

<html>
    <head>
        <title>Welcome to Example.com!</title>
    </head>
    <body>
        <h1>Success! The example.com server block is working!</h1>
    </body>
</html>

Сохраните и закройте файл, когда закончите. Чтобы сделать это в nano, нажмите CTRL+o, чтобы записать файл, затем CTRL+x, чтобы выйти.

Поскольку файл для нашего второго сайта в основном будет таким же, мы можем скопировать его в наш второй корень документа следующим образом:

  1. cp /var/www/example.com/html/index.html /var/www/test.com/html/

Теперь мы можем открыть новый файл в нашем редакторе:

  1. nano /var/www/test.com/html/index.html

Измените его так, чтобы он ссылался на наш второй домен:

<html>
    <head>
        <title>Welcome to Test.com!</title>
    </head>
    <body>
        <h1>Success!  The test.com server block is working!</h1>
    </body>
</html>

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

Шаг 3 — Создание файлов блоков сервера для каждого домена

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

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

Создание первого файла блока сервера

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

  1. sudo cp /etc/nginx/sites-available/default /etc/nginx/sites-available/example.com

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

  1. sudo nano /etc/nginx/sites-available/example.com

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

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

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

        server_name _;

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

Во-первых, нам нужно взглянуть на директивы listen. Только один из наших серверных блоков на сервере может иметь включенную опцию default_server. Это указывает, какой блок должен обслуживать запрос, если запрошенный server_name не соответствует ни одному из доступных серверных блоков. Это не должно происходить очень часто в реальных сценариях, поскольку посетители будут получать доступ к вашему сайту через ваше доменное имя.

Вы можете назначить один из ваших сайтов «по умолчанию», включив параметр default_server в директиву listen, или вы можете оставить блок сервера по умолчанию включенным, что будет обслуживать содержимое каталога /var/www/html, если запрошенный хост не может быть найден.

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

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

        . . .
}

Примечание. Вы можете проверить, включена ли опция default_server только в одном активном файле, набрав:

  1. grep -R default_server /etc/nginx/sites-enabled/

Если совпадения будут найдены без комментариев более чем в файле (показано в крайнем левом столбце), Nginx сообщит о недопустимой конфигурации.

Следующее, что нам нужно настроить, — это корень документа, указанный в директиве root. Укажите его на созданный вами корень документа сайта:

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

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

}

Затем нам нужно изменить server_name, чтобы он соответствовал запросам для нашего первого домена. Мы можем дополнительно добавить любые псевдонимы, которые мы хотим сопоставить. Мы добавим псевдоним www.example.com для демонстрации.

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

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

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

        server_name example.com www.example.com;

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

Это все, что нам нужно для базовой конфигурации. Сохраните и закройте файл, чтобы выйти.

Создание файла второго блока сервера

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

  1. sudo cp /etc/nginx/sites-available/example.com /etc/nginx/sites-available/test.com

Откройте новый файл с правами sudo в вашем редакторе:

  1. sudo nano /etc/nginx/sites-available/test.com

Опять же, убедитесь, что вы не используете параметр default_server для директивы listen в этом файле, если вы уже использовали его в другом месте. Настройте директиву root, чтобы она указывала на корень документа вашего второго домена, и настройте server_name, чтобы он соответствовал доменному имени вашего второго сайта (не забудьте указать все псевдонимы).

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

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

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

        server_name test.com www.test.com;

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

Когда вы закончите, сохраните и закройте файл.

Шаг 4 — Включение блокировки сервера и перезапуск Nginx

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

Мы можем создать эти ссылки, набрав:

  1. sudo ln -s /etc/nginx/sites-available/example.com /etc/nginx/sites-enabled/
  2. sudo ln -s /etc/nginx/sites-available/test.com /etc/nginx/sites-enabled/

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

  • example.com: будет отвечать на запросы example.com и www.example.com
  • test.com: будет отвечать на запросы test.com и www.test.com
  • по умолчанию: будет отвечать на любые запросы к порту 80, которые не соответствуют двум другим блокам.

Чтобы избежать возможной проблемы с памятью хэш-контейнера, которая может возникнуть из-за добавления дополнительных имен серверов, мы также скорректируем одно значение в нашем файле /etc/nginx/nginx.conf. Откройте файл сейчас:

  1. sudo nano /etc/nginx/nginx.conf

В файле найдите директиву server_names_hash_bucket_size. Удалите символ #, чтобы раскомментировать строку:

http {
    . . .

    server_names_hash_bucket_size 64;

    . . .
}

Сохраните и закройте файл, когда закончите.

Затем проверьте, чтобы убедиться, что ни в одном из ваших файлов Nginx нет синтаксических ошибок:

  1. sudo nginx -t

Если проблем не обнаружено, перезапустите Nginx, чтобы изменения вступили в силу:

  1. sudo systemctl restart nginx

Теперь Nginx должен обслуживать оба ваших доменных имени.

Шаг 5 — Изменение файла локальных хостов для тестирования (необязательно)

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

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

Примечание. Убедитесь, что во время этих шагов вы работаете на локальном компьютере, а не на удаленном сервере. Для этого вам потребуется root-доступ, членство в административной группе или иная возможность редактировать системные файлы.

Если вы находитесь дома на компьютере Mac или Linux, вы можете отредактировать нужный файл, набрав:

  1. sudo nano /etc/hosts

Если вы работаете в Windows, вы можете найти инструкции по изменению файла hosts здесь.

Вам нужно знать общедоступный IP-адрес вашего сервера и домены, которые вы хотите направить на сервер. Если предположить, что общедоступный IP-адрес моего сервера — 203.0.113.5, строки, которые я добавлю в свой файл, будут выглядеть примерно так:

127.0.0.1   localhost
. . .

203.0.113.5 example.com www.example.com
203.0.113.5 test.com www.test.com

Это перехватит любые запросы для example.com и test.com и отправит их на ваш сервер, что нам и нужно, если мы на самом деле не владеем доменами, которые мы используют.

Сохраните и закройте файл, когда закончите.

Шаг 6 — Проверка ваших результатов

Теперь, когда вы все настроили, вы должны проверить правильность работы ваших серверных блоков. Вы можете сделать это, посетив домены в своем веб-браузере:

http://example.com

Вы должны увидеть страницу, которая выглядит следующим образом:

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

http://test.com

Если оба этих сайта работают, вы успешно настроили два независимых блока серверов с Nginx.

На этом этапе, если вы изменили файл hosts на локальном компьютере для проверки, вы, вероятно, захотите удалить добавленные строки.

Если вам нужен доступ к вашему серверу по доменному имени для общедоступного сайта, вы, вероятно, захотите приобрести доменное имя для каждого из ваших сайтов.

Заключение

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