Совместное использование размещенной зоны в разных проектах

#google-cloud-platform #dns #domain-name #google-cloud-dns

#google-облачная платформа #dns #доменное имя #google-облако-dns

Вопрос:

Мне нужны предложения по запуску Google Cloud DNS для моих проектов. У меня есть 4 разных проекта с именами: experiments , test , stage и prod в GCP. На данный момент DNS for all размещены на route53 том, как мы AWS ранее использовали infra. Теперь мы переместили нашу инфраструктуру Google cloud , но DNS не перенесли, что я планирую перенести. Я ищу предложения по настройке peering или sharing среди проектов в GCP

В настоящее время у нас есть единый hosted-zone AWS вход, и все разные записи, относящиеся к конкретному проекту, являются наборами записей в размещенной зоне. Например, для hosted-zone «example.com «, у меня есть записи: expt.example.com stg.example.com и prd.example.com поскольку все они принадлежат к одной и той же размещенной зоне, а инфра из отдельных проектов вызывает их соответствующие записи. Таким образом, существует несколько таких записей в размещенной зоне. Помимо этого, есть некоторые записи, которые должны быть доступны для всех проектов. Пример: «common.example.com »

Мы также собираемся настроить DR-проекты для каждого из которых будут иметь свои собственные записи и общие записи по всей организации. Например, для experiments проекта в регионе R1 запись для expt.example.com должна разрешаться по R1 IP-адресу, а для региона R2 это должен быть другой IP-адрес. Но на случай, если нам придется выполнить сбой в определенной части приложения. Мы должны иметь доступ к записям других регионов.

Мои первоначальные мысли:

  1. установите hosted-zone с тем же именем в каждом проекте и скопируйте соответствующие записи для каждого проекта в качестве записи, установленной в нем. Для общих записей я могу либо создать новый проект, а затем выполнить DNS-пиринг со всеми этими проектами, либо поместить общие записи в общедоступную запись, которая будет доступна для всех них.
  2. Или создайте другую host-project , а затем добавьте в нее все другие проекты как a service-project , а затем предоставьте им доступ к соответствующим записям, как это происходит внутри aws .

Но я не знаю, как следует обращаться с DR, и есть ли лучший подход для выполнения вышеуказанной задачи? Любое предложение приветствуется. Я новичок в настройке DNS, поэтому, пожалуйста, простите мои ошибки.

Комментарии:

1. 1) Ваш вопрос слишком широк и в нем отсутствует одна четко определенная проблема с необходимыми деталями. 2) Разрешение имен в Google Cloud не поддерживает пиринг с помощью Route53. 3) Вам нужно будет настроить DNS с разделенным горизонтом. Вы упомянули, что вы новичок в DNS. Поскольку вы планируете переход на Google Cloud, переместите / скопируйте свои записи DNS и правильно настройте облачный DNS Google с использованием частных и общедоступных размещенных зон. Это намного проще, чем настройка пользовательского разрешения имен.

2. 4) Вместо того, чтобы полагаться на разрешение DNS-имен, рассмотрите возможность использования современного решения с помощью обнаружения служб. Такие продукты, как HashiCorp Consul, очень хороши для решения проблем вашего типа.

3. ПРИВЕТ, Джон, спасибо за ответ.. Я не пытаюсь подключиться к облачному DNS Google с помощью маршрута 53. Все проекты являются частью Google Cloud, поэтому пиринг будет осуществляться в рамках GCP и в рамках одной организации. Я хотел бы узнать о других вариантах discover services для экземпляров, отличных от kubernetes

4. Ваш вопрос слишком широк и в нем отсутствует одна четко определенная проблема с требуемыми деталями

5. ПРИВЕТ, Джон, я добавил информацию о том, что пиринг требуется в основном в проектах GCP. Не уверен, что еще я могу добавить, чтобы подробнее рассказать о требованиях. Я буду продолжать добавлять больше деталей, если узнаю, какая еще может быть релевантная информация, я надеюсь, это поможет читателям (в конечном счете мне).