DNS-серверы геолокации Heroku и Amazon Route 53
У меня есть приложение, работающее на Heroku в 2 регионах, ЕС и США. Скажем: myapp-eu.herokuapp.com и myapp-us.herokuapp.com.
Я хотел бы настроить DNS-адрес геолокации, который указывает пользователям на ближайший регион, когда они посещают наш сайт www.myapp.com.
До сих пор я использовал Amazon Route 53 для настройки 2-х записей CNAME:
- www.myapp.com CNAME myapp-eu.herokuapp.com (если географическое положение - eu)
- www.myapp. com CNAME myapp-us.herokuapp.com (когда используется гео)
Но Heroku не принимает один и тот же CNAME для использования в двух разных приложениях.
Кто-нибудь успешно настроил географический DNS, который работает с Heroku, пожалуйста ?
Спасибо!
Я собирался опубликовать решение с помощью HAProxy, которое, как мне кажется, я уже давал здесь в качестве ответа (хотя поиск не дал его).
Это (или что-то в этом роде) аналогично, вы также можете использовать varnish или nginx) будет единственным жизнеспособным подходом, учитывая ограничение пространства имен глобального приложения Heroku, поскольку ни одна служба DNS не может делать то, что вы хотите - перезапись заголовка хоста не может быть выполнена только с помощью конфигурации DNS. Запрос должен будет пройти через какую-то систему, которая может переписывать заголовок на лету.
Однако вам понадобится только один прокси, а не два. Вот почему:
Если имя хоста myapp.example.com , то настройте развертывание Heroku в США так, чтобы оно просто ожидало это имя хоста.
Тогда не настраивайте развертывание ЕС для ожидания пользовательского имени хоста; вы будете использовать другое имя хоста myapp-eu.herokuapp.com .
Маршрут 53 должен быть настроен для возврата конечной точки Heroku в качестве ответа на запросы США и конечной точки прокси для запросов ЕС. Прокси-сервер перепишет заголовок хоста на myapp-eu.herokuapp.com и отправит запрос в конечную точку Heroku EU, но запросы из США будут идти напрямую в конечную точку Heroku US, которая будет ожидать имя хоста клиента. уже использует.
Вы также можете отказаться от прокси-сервера и использовать вместо него CloudFront. Обратите внимание, что это решение работает только с 2 пунктами назначения - в данном случае США и ЕС - из-за ограничений глобальной конфигурации CloudFront (для данного имени входящего хоста можно настроить только 1 раздачу CloudFront) ... но для этого решения 1 это все, что нам нужно. Один пункт назначения (США) использует прямое соединение и не требует перезаписи, в то время как другой пункт назначения (ЕС) прокси-сервер через CloudFront и получает перезапись.
Создайте распространение CloudFront. Настройте его на ожидание запросов для myapp.example.com . Настройте его на использование имени хоста конечной точки Heroku EU, myapp-eu.herokuapp.com в качестве настраиваемого исходного сервера, а не настраивайте на добавление заголовка хоста в белый список из оригинальный запрос. Добавьте в белый список все необходимые заголовки. При желании отключите кеширование. Затем CloudFront перепишет заголовок Host: из myapp.example.com в настроенное имя хоста сервера Origin, которое будет конечной точкой ЕС.
Затем, как и раньше, настройте Route 53, чтобы вернуть CNAME конечной точки Heroku в США для запросов из местоположений, которые должны поступать в конечную точку США, но для возврата CNAME CloudFront dxxxxxxxx.cloudfront.net CNAME для запросов из местоположений, которые должны поступать в конечную точку ЕС.
В любом случае вы будете платить за транспортировку трафика, отправляемого на конечную точку, который проходит через прокси или CloudFront, поэтому вы можете использовать это для конечной точки, которая, как вы ожидаете, получит меньший объем трафика. . таким образом, вы можете захотеть транспонировать ЕС и США в приведенных выше примерах, которые произвольно предполагают, что США увидят больше трафика, поэтому он направляет напрямую.
Ни одно из этих решений не должно увеличивать время приема-передачи запросов. Если вы выберете прокси-маршрут, вы, вероятно, обнаружите, что очень маленькая машина, такая как t2.micro или t2.nano, может обрабатывать больше трафика, чем вы могли ожидать, поскольку обработка минимальна.