У меня есть приложение, работающее на Heroku в 2 регионах: ЕС и США. Скажем: myapp-eu.herokuapp.com и myapp-us.herokuapp.com.
Я хотел бы настроить DNS-адрес геолокации, который указывает пользователям на ближайший регион, когда они посещают наш сайт по адресу www.myapp.com.
До сих пор я использовал Amazon Route 53 для настройки 2 записей CNAME:
Но 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 в качестве своего настраиваемого исходного сервера и не настройте его на белый список заголовка Host из исходного запроса. Добавьте в белый список все необходимые заголовки. При желании отключите кеширование. CloudFront перепишет Host: заголовок из myapp.example.com на настроенное имя хоста сервера Origin, которое будет конечной точкой ЕС.
Затем, как и раньше, настройте Route 53, чтобы он возвращал CNAME конечной точки US Heroku для запросов из местоположений, которые должны поступать в конечную точку США, но возвращать CloudFront dxxxxxxxx.cloudfront.net CNAME для запросов из местоположений, которые должны поступать в конечную точку ЕС.
В любом случае вы будете платить за транспортировку трафика, отправляемого на конечную точку, который проходит через прокси или CloudFront, поэтому вы можете использовать это для конечной точки, которая, как вы ожидаете, получит меньший объем трафика ... так что вы можете захотеть транспонировать ЕС и США в приведенных выше примерах, которые произвольно предполагают, что США увидят больше трафика, поэтому он направляется напрямую.
Ни одно из этих решений не должно увеличивать время обработки запросов. Если вы выберете прокси-маршрут, вы, вероятно, обнаружите, что очень маленькая машина, такая как t2.micro или t2.nano, может обрабатывать больше трафика, чем вы могли ожидать, поскольку обработка минимальна.