Свяжите доменное имя с приложением

Введение

Приложение уже отвечает на HTTP-запросы, но пользователям нужно имя. Создайте размещённую зону Route 53 и запись A, получите реальный ответ DNS и используйте возвращённый адрес для доступа к подготовленному приложению.

Сначала завершите AWS Foundations. Эта независимая VM предоставляет настроенный доступ AWS CLI, сервер запросов DNS и отдельную эталонную зону. Личный аккаунт AWS и покупка домена не нужны. Просматривайте записи в AWS View сверху и выполняйте команды в Terminal снизу. Учебное имя заканчивается на .test; регистрация и делегирование публичного домена не выполняются.

Связь с сертификацией

Обзор лабораторной работы

Создайте имя приложения

На этом шаге создайте размещённую зону и запись A для подготовленного приложения.

DNS преобразует имена в информацию, например IP-адреса. Размещённая зона хранит записи домена. Запись A связывает имя с IPv4-адресом; она не запускает приложение и не устанавливает соединение.

Домен — labex-n01.test, имя приложения — app.labex-n01.test. Приложение слушает 127.0.0.1 на HTTP-порту 8081. Этот loopback-адрес обозначает саму VM, поэтому запросы остаются в учебной среде.

Создайте зону:

cd /home/labex/project
ZONE_ID=$(aws route53 create-hosted-zone \
  --name labex-n01.test \
  --caller-reference labex-n01-application \
  --query HostedZone.Id \
  --output text)

$(...) сохраняет вывод в переменной оболочки ZONE_ID. --query выбирает ID зоны, а --output text позволяет использовать его как аргумент. CallerReference различает запросы создания. Не закрывайте Terminal, чтобы сохранить переменную.

Изменение записи задаётся в JSON. Here-document с кавычками записывает буквальный текст в record.json. TTL в секундах указывает, как долго DNS-кэши могут повторно использовать ответ. Этот сервер непосредственно возвращает авторитетный ответ; рекурсивный кэш здесь не измеряется.

cat > record.json <<'JSON'
{
  "Changes": [{
    "Action": "CREATE",
    "ResourceRecordSet": {
      "Name": "app.labex-n01.test",
      "Type": "A",
      "TTL": 60,
      "ResourceRecords": [{"Value": "127.0.0.1"}]
    }
  }]
}
JSON

Примените изменение к своей зоне. file:// читает локальный JSON-файл:

aws route53 change-resource-record-sets \
  --hosted-zone-id "$ZONE_ID" \
  --change-batch file://record.json

Ответ идентифицирует изменение и подтверждает конфигурацию; на следующем шаге вы проверите реальный ответ DNS. Посмотрите сохранённую запись:

aws route53 list-resource-record-sets \
  --hosted-zone-id "$ZONE_ID" \
  --query "ResourceRecordSets[?Type=='A']"

Найдите имя приложения, A, TTL 60 и 127.0.0.1. AWS View показывает запись в вашей зоне рядом с независимой эталонной зоной. Не изменяйте эталон. Выполните проверку перед продолжением.

Запросите DNS и откройте приложение

На этом шаге различайте корректный ответ DNS, отсутствующее имя и успешный HTTP-запрос.

dig запрашивает DNS. @127.0.0.1 выбирает подготовленный сервер, а -p 1053 — учебный порт. +norecurse запрашивает авторитетный ответ без рекурсивного поиска. Это явно проверяет сервер, не меняя системный резолвер VM.

dig +norecurse @127.0.0.1 -p 1053 app.labex-n01.test A

Ожидайте status: NOERROR и запись ANSWER с именем, TTL 60, типом A и адресом 127.0.0.1. Ответ основан на вашей реальной записи Route 53. Сравните его с именем, которое вы не создавали:

dig +norecurse @127.0.0.1 -p 1053 missing.labex-n01.test A

Ожидайте status: NXDOMAIN без ответа. Обмен DNS завершён и сообщает, что имя отсутствует; это не ошибка подключения к серверу. AWS View показывает последний реальный запрос и число ответов.

Теперь сохраните адрес. +short выводит только ответ:

APP_IP=$(dig +norecurse @127.0.0.1 -p 1053 app.labex-n01.test A +short)
printf '%s\n' "$APP_IP"

curl выполняет HTTP-запрос. --resolve использует полученный адрес для точного имени и порта этого запроса. Он не регистрирует домен и не изменяет системный DNS.

curl --fail --noproxy '*' \
  --resolve "app.labex-n01.test:8081:${APP_IP}" \
  http://app.labex-n01.test:8081/

Ожидаемый результат:

Delivery application ready

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

Удалите только зону приложения

На этом шаге удалите свою запись и размещённую зону, затем убедитесь, что имя больше не разрешается.

Обычно нельзя удалить зону, в которой остаются записи приложения. Изменение DELETE должно совпадать с именем, типом, TTL и значением записи. Запишите ту же запись с действием удаления:

cat > delete-record.json <<'JSON'
{
  "Changes": [{
    "Action": "DELETE",
    "ResourceRecordSet": {
      "Name": "app.labex-n01.test",
      "Type": "A",
      "TTL": 60,
      "ResourceRecords": [{"Value": "127.0.0.1"}]
    }
  }]
}
JSON

Примените удаление, затем удалите опустевшую зону приложения:

aws route53 change-resource-record-sets \
  --hosted-zone-id "$ZONE_ID" \
  --change-batch file://delete-record.json
aws route53 delete-hosted-zone \
  --id "$ZONE_ID"

Ещё раз запросите удалённое имя:

dig +norecurse @127.0.0.1 -p 1053 app.labex-n01.test A

Ожидайте NXDOMAIN. Подготовленное приложение является отдельным ресурсом и может продолжать работать: удаление DNS убирает связь имени, а не приложение. AWS View должен сохранить только эталонную зону. Выполните проверку очистки.

Резюме

Вы создали размещённую зону и запись A, прочитали реальные ответы DNS, открыли приложение по полученному адресу и удалили только свои DNS-ресурсы. Вы различили конфигурацию записей, разрешение имён и доступность приложения. Далее изучите, как CloudFront доставляет содержимое из ограниченного источника S3.