Как настроить субдомен на AWS EC2 с помощью Route 53 и Nginx

Шаг за шагом с примером

Если у вас есть веб-сайт, размещенный на AWS EC2, и вы хотите создать для него поддомен, вы можете подумать, что вам нужно запустить еще один экземпляр EC2 и назначить ему другой IP-адрес. Однако есть более простой и экономичный способ сделать это: использовать записи CNAME на Route 53 и настроить nginx на вашем экземпляре EC2 для использования одного и того же IP-адреса.

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

Создать запись CNAME

Чтобы создать запись CNAME, которая сопоставляет ваш поддомен с вашим доменом, вам необходимо использовать консоль Amazon Route 53 или API.

Запись CNAME — это тип записи DNS, который позволяет направлять трафик к ресурсу, например веб-серверу, используя доменное имя вместо IP-адреса. Например, вы можете создать запись CNAME, которая сопоставляет blog.example.com с example.com, а затем настроить веб-сервер для обслуживания различных приложений на основе имени хоста.

Чтобы создать запись CNAME с помощью консоли Route 53, выполните следующие действия:

1. Войдите в Консоль управления AWS и откройте консоль Route 53 по адресу https://console.aws.amazon.com/route53/.
2. На панели навигации выберите Размещенные зоны.
3. На странице Размещенные зоны выберите имя размещенной зоны, в которой вы хотите создавать записи.
4. Выберите Создать запись.
5. Выберите Простая политика маршрутизации и введите следующие значения. :
— Имя записи: введите имя вашего субдомена, например blog.
— Тип записи: выберите CNAME.
— Значение: введите имя вашего домена, например, example.com.
6. Выберите Создать записи.

На следующем снимке экрана показан пример создания записи CNAME для subdomain.domain.com с помощью консоли Route 53:

Настроить Nginx

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

Чтобы настроить Nginx, нам нужно отредактировать файл nginx.conf, который обычно находится в каталоге /etc/nginx/ или /usr/local/nginx/. Вы можете использовать любой текстовый редактор по вашему выбору, например, nano, vim или emacs. Файл nginx.conf содержит различные директивы, управляющие поведением Nginx. Мы сосредоточимся на директивах server и location, которые определяют, как Nginx обрабатывает запросы для разных доменов и URL-адресов.

Файл nginx.conf должен выглядеть примерно так:

server {
  listen         80;
  server_name    www.domain.com domain.com;
  return 301 https://www.domain.com$request_uri;
}

server {
  listen         80;
  server_name    www.subdomain.domain.com subdomain.domain.com;
  return 301 https://www.subdomain.domain.com$request_uri;
}

server {
    server_name www.domain.com domain.com;

    listen 443 ssl;

    ssl_certificate <path/to/.crt>;
    ssl_certificate_key <path/to/.key>;

    location / {
        proxy_pass https://domain_app:8000;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto https; 
        proxy_set_header Host $host;
        proxy_redirect off;
    }
}


server {
    server_name www.subdomain.domain.com subdomain.domain.com;

    listen 443 ssl;

    ssl_certificate <path/to/.crt>;
    ssl_certificate_key <path/to/.key>;

    location / {
        proxy_pass https://subdomain_app:8001;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto https; 
        proxy_set_header Host $host;
        proxy_redirect off;
    }
}

Давайте разберем, что делает каждая директива:

• Директива listen указывает номер порта, на котором Nginx прослушивает входящие запросы. В нашем случае у нас есть две директивы listen для каждого блока сервера: одна для порта 80 (HTTP) и одна для порта 443 (HTTPS).
• Директива server_name указывает доменное имя или имена, на которые Nginx отвечает для каждого блока сервера. В нашем случае у нас есть две директивы server_name для каждого блока сервера: одна для версии с www и одна для версии без www нашего домена и поддомена.
• Директива return отправляет ответ перенаправления клиенту с указанным кодом состояния и URL-адресом. В нашем случае мы используем return 301 для перенаправления всех HTTP-запросов на HTTPS как для нашего домена, так и для поддомена (директива return 301 в NGINX используется для выполнения постоянного перенаправления. Она сообщает клиенту, что запрошенный ресурс был навсегда перемещен на новый местоположение и предоставляет новый URL-адрес. Клиент должен использовать новый URL-адрес для всех будущих запросов к этому ресурсу1).
• Директивы ssl_certificate и ssl_certificate_key указывают пути к SSL-сертификату и файлам ключей, которые Nginx использует для защиты HTTPS-соединения. Вам нужно заменить ‹path/to/.crt› и ‹path/to/.key› фактическими путями к вашему сертификату и файлам ключей.
• Директива location определяет, как Nginx обрабатывает запросы на разные URL-адреса в блоке сервера. В нашем случае у нас есть одна директива местоположения для каждого блока сервера: location /, которая соответствует любому URL-адресу, начинающемуся с косой черты (/).
• Блок местоположения в каждом блоке сервера настроен на прокси-запросы к указанным вышестоящим серверам приложений (domain_app:8000 и subdomain_app:8001) с использованием директивы proxy_pass. В среде Docker вы можете указать вышестоящий сервер в NGINX, используя имя службы контейнера. Это возможно, потому что Docker предоставляет внутренний преобразователь DNS, который может преобразовать имя службы контейнера в его IP-адрес. Чтобы контейнер NGINX мог разрешить имя службы контейнера приложений, оба контейнера должны быть подключены к одной и той же сети Docker. Этого можно добиться несколькими способами, в зависимости от того, как вы запускаете свои контейнеры. Если вы используете docker run для запуска своих контейнеров, вы можете создать пользовательскую сеть с помощью команды docker network create, а затем подключить к ней свои контейнеры, используя флаг --network при их запуске. Например:

# Create a user-defined network
docker network create my-network

# Start the app container and connect it to the network
docker run --name domain_app --network my-network ...

# Start the NGINX container and connect it to the network
docker run --name nginx --network my-network ...

Если вы используете docker-compose, вы можете определить пользовательскую сеть в файле docker-compose.yml и указать, что обе службы должны ее использовать. Например:

version: '3'
services:
  domain_app:
    ...
    networks:
      - my-network
  nginx:
    ...
    networks:
      - my-network
networks:
  my-network:

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

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

proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for

добавляет IP-адрес клиента в заголовок X-Forwarded-For, что полезно для ведения журнала и контроля доступа.

proxy_set_header X-Forwarded-Proto https

устанавливает для заголовка X-Forwarded-Proto значение https, что указывает на то, что запрос был сделан через защищенное соединение. Это полезно для приложений, которым необходимо знать, был ли запрос безопасным или нет.

proxy_set_header Host $host

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

proxy_redirect off

отключает любые перенаправления, выдаваемые вышестоящим сервером или приложением, что предотвращает любые конфликты с собственными перенаправлениями Nginx.

Краткое содержание

В этом сообщении блога мы узнали, как добавить поддомен, который использует тот же IP-адрес EC2, что и основной домен, но обслуживается другим приложением. Мы использовали AWS Route 53 для создания записи CNAME, которая сопоставляет субдомен с основным доменом, а затем мы изменили файл конфигурации nginx для обработки запросов для субдомена. Таким образом, мы можем размещать несколько приложений на одном экземпляре EC2 и использовать поддомены для доступа к ним.

Повышение уровня кодирования

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

• 👏 Хлопайте за историю и подписывайтесь на автора 👉
• 📰 Смотрите больше контента в публикации Level Up Coding
• 💰 Бесплатный курс собеседования по программированию ⇒ Просмотреть курс
• 🧠 Инструменты ИИ ⇒ Просмотреть сейчас

🔔 Подписывайтесь на нас: Twitter | ЛинкедИн | "Новостная рассылка"

🚀👉 Присоединяйтесь к коллективу талантов Level Up и найдите прекрасную работу