Contents hide

1.1 Этап 1: Создание dev, stage хостед-зон

1.2 Этап 2: Создание NS записей в основной hostedzone

Все началось с настройки externalDNS. Нужно было как то разделить основную hostedzone на две дополнительные для env, stage окружений, а основную использовать только для записей prod.

Идея состоит в тому чтоб для разных окружений использовались соответствующие зоны в Route53. Если говорить об кластерах кубернетес, тогда externalDNS в кластерах dev, stage, prod должен иметь доступ только к соответствующей хостед-зоне и полноценно ее администрировать (создавать и удалял записи).

Если кратко, то схема будет выглядеть так:

Prod окружение:
все записи с окончанием *.example.com будут принадлежать и создаваться в основной зоне (к которой закреплен домен).

Stage окружение:
тут аналогично, как и с дев, все записи с окончанием *.stage.example.com будут принадлежать и создаваться в stage хостед зоне.

Dev окружение:
записи с окончанием *.dev.example.com будут создаваться и принадлежать dev хостед зоне для дев окружения.

Главное помнить и беречь основную HostedZone. Если удалить NS записи в основной зоне (dev.example.com, stage.example.com) зоны не будут доступны, все записи в этих зонах не будут резолвиться. Правда все это легко можно восстановить создав новые записи.

В общем пошел искать информацию на просторах интернета. После некоторого времени поиска нашел подходящий вариант how-to-manage-route53-hosted-zones-in-a-multi-account-environment, такой подход используют в мульти-аккаунтном окружении. Когда для каждого окружения отдельней аккаунт AWS и соответственно hosterzone в каждом аккаунте свои, но используют они один домен. Данный вариант мне подходит, только у нас все будет на одном аккаунте.

Для реализации нужно следующее:

1. Создать основную hostedzone и закрепить за ней домен (если такая зона уже есть, создавать ее не нужно).

2. Создать две дополнительные зоны, для dev, stage окружений.

3. Создать в основной зоне NS записи дополнительных зон (dev.. stage..).

4. Проверить работоспособность.

Настройка

Этап 1: Создание dev, stage хостед-зон

Переходим в AWS Console > Route53 и создаем зону dev.example.com:

сохраняем, проверяем, зона создалась с двумя записями:

теперь создадим зону stage.example.com:

сохраняем, проверяем:

Хорошо, дефолтные записи создались, переходим к следующему этапу.

Этап 2: Создание NS записей в основной hostedzone

Переходим в основную зону example.com, создаем две записи с типом NS. Создание этих записей позволяет нам связать дополнительные зоны с основной и использовать один домен.

После создания у нас должно быть три записи NS, смотрим ниже на изображение:

1. example.com – NS основной зоны к которой закреплен домен.
2. dev.example.com – NS зоны дев окружения.
3. stage.example.com – NS зоны стейдж окружения.

все записи созданы. Осталось только проверить и убедиться что оно работает.

Этап 3: Проверка и тестирование

Что ж, для начала посмотрим с помощью dig какие NS будет нам отдавать, сначала dev:

$ dig NS dev.********.com +short
ns-1**0.awsdns-**.co.uk.
ns-**8.awsdns-**.com.
ns-**2.awsdns-**.net.
ns-1**3.awsdns-**.org.

после stage:

$ dig NS stage.********.com +short
ns-1**0.awsdns-**.co.uk.
ns-**8.awsdns-**.com.
ns-**2.awsdns-**.net.
ns-1**3.awsdns-**.org.

окей, каждая зона отдает нам свои NS.

Для теста создадим A запись в зоне dev.example.com. Ендпоинтом записи будет dev сайт запись которого раньше была в основной зоне example.com.

Переходим в Route53 > dev.example.com > Create Record > Define Simple Record:

жмем Define Simple Record:

Проверяем, нажимаем Create recodrs. Хорошо, запись создали, подождем немного и проверим.

Теперь с помощью curl проверим доступен ли сайт по доменному имени или нет:

$ curl -I https://dev.example.com
HTTP/1.1 200 OK Server: nginx/1.14.0 (Ubuntu)
Content-Type: text/html; charset=UTF-8
Connection: keep-alive 
Vary: Accept-Encoding 
Cache-Control: no-cache, private

отлично, работает.

Ссылки по теме

Click to rate this post!

[Total: 0 Average: 0]

view count: 234