Чтобы снизить наши Azure затраты, мы стремимся удалить неиспользуемые ресурсы.
У нас есть служба приложений, являющаяся частью настройки менеджера traffi c, доступная, когда пользователи вводят x.com в своем браузере. Существуют две службы приложений:
eus-x-com.azurewebsites.net
wus-x-com.azurewebsites.net
Они добавляются в профиль менеджера traffi c, и когда они были добавлены в TM, они были настроены на использование пользовательских доменов для x.com
*. 1009 * DNS для
x.com указывает на
x-com.trafficmanager.net, имя конечной точки менеджера traffi c, которая управляет этими двумя сайтами.
Это означает, что теперь есть:
//sites under Traffic Manager control of x.com
EastUS App Service Plan 1
eus-x-com.azurewebsites.net (with custom domain x.com -> x-com.trafficmanager.net)
WestUS App Service Plan 1
wus-x-com.azurewebsites.net (with custom domain x.com -> x-com.trafficmanager.net)
//sites not assigned to a traffic manager
EastUS App Service Plan 2
y-com.azurewebsites.net (with custom domain y.com -> y-com.azurewebsites.net)
z-com.azurewebsites.net (with custom domain z.com -> z-com.azurewebsites.net)
Через несколько лет кажется, что eus-x-com.azurewebsites.net никогда не выходил из строя, и он мало используется, поэтому мы смотрим на то, чтобы в East US Service Plan 2 размещался один экземпляр x.com, плюс другие сайты, на которых он размещался, и избавление от него менеджера traffi c и плана обслуживания восток / запад 1, оставляя только план обслуживания 2
Идея заключалась в следующем:
- создать новый сервис приложений в EastUS App Service План 2 называется
x-com.azurewebsites.net - развернуть код, чтобы он работал,
- дать ему собственный домен x.com (то есть эквивалент добавления заголовка узла в IIS)
- изменить DNS так, чтобы он указывал на
x-com.azurewebsites.net, чтобы трафик c постепенно начинает появляться новое веб-приложение, когда DNS-серверы по всему миру обновляют - удаляют всю инфраструктуру TM в какой-то момент
Я сталкиваюсь с проблемой: даже если я могу подтвердить право собственности на домен DNS Я сталкиваюсь с ограничением, заключающимся в том, что две разные службы приложений, даже в разных планах служб приложений, не могут иметь одинаковые настройки настраиваемого домена, если они не являются частью настройки менеджера traffi c. Я получаю сообщение «Пользовательский домен x.com уже используется службой приложений eus-x-com.azurewebsites. net» при попытке добавить пользовательский домен с x.com к x-com.azurewebsites.net
Это немного раздражает, поскольку я не предвижу причин, по которым технически невозможно иметь один и тот же настраиваемый домен для двух служб приложений в разных планах, если все это (в старых терминах IIS) является заголовком / привязкой узла; какая служба приложения фактически используется, зависит от того, какой трафик IP-адреса c поступает на основе DNS. Настраиваемая привязка домена - это механизм маршрутизации, позволяющий узнать, какой службе приложения передать трафик c, когда он достигает IIS, на котором размещены несколько сайтов. Хотя я считаю разумным, что azure не позволяет нескольким службам приложений в одном и том же плане назначать один и тот же настраиваемый домен, я не могу понять, как логично запретить службам приложений в разных планах служб приложений использовать один и тот же параметр настраиваемого домена * 1042. *
Вместо этого я рассмотрел следующие действия:
- создайте новый сайт в сервисном плане EastUS App 2 с именем
x-com.azurewebsites.net - и разверните на нем код, чтобы он работал
- добавьте его в менеджер трафика c, чтобы я мог затем установить для него настраиваемый домен
x.com (поскольку разрешено повторное использование настраиваемых доменов, если сайты находятся в одном профиле менеджера трафика c ) - изменить DNS так, чтобы трафик c постепенно начинал приходить к новому веб-приложению напрямую, минуя TM
- , удаляя всю инфраструктуру TM в какой-то момент
Вот где у меня возникает другая проблема:
Две службы приложений в одном регионе (независимо от того, находятся ли они в другом плане обслуживания приложений) не могут принадлежать тот же траффи c профиль менеджера. Несмотря на то, что эти сайты находятся в разных тарифных планах приложений, эти планы находятся в одном регионе (EUS), и на портале появляется сообщение об ошибке:
Traffi c Конфигурация менеджера недопустима, поскольку или более доменов не принадлежат подписке «xxx»
Обсуждение на github от сотрудника MSFT говорит, что это фиктивное сообщение об ошибке, которое следует интерпретировать как «вы можете» две службы приложений в одном регионе не могут быть частью одной и той же TM ». Вы можете получить его, если один из них является внешней конечной точкой, но тогда он не добавит для вас пользовательский домен, и это единственное, что я хотел из добавления нового сайта в TM
. вместо этого я могу, вместо этого, отредактировать ТМ и изменить местоположение конечной точки на:
//existing setup
TM
east-us-x-endpoint -> eus-x-com.azurewebsites.net
west-us-x-endpoint -> wus-x-com.azurewebsites.net
//proposed setup
TM
east-us-x-endpoint -> x-com.azurewebsites.net //edit it to point to the new x-com
//delete the west US one
Я сделал это и отредактировал конечную точку для нацеливания на другую службу приложения. Хотя портал сообщает, что изменение было внесено, существуют проблемы:
- менеджер traffi c определенно все еще отправляет traffi c в старую службу приложений, потому что сайт работает, хотя новый Служба приложений еще не имеет кода
- остановка старой службы приложений
eus-x-com.azurewebsites.net (больше не настроенной ни в одной конечной точке TM) приводит к тому, что веб-сайт перестает работать с HTTP 503
Все могло бы сработать, если бы я уже не удалил нас на запад. Хотя это и не идеально, потому что это было медленнее (база данных в восточной части США), я, вероятно, мог бы удалить eus-x-com из TM и позволить wus-x-com взять нагрузку, затем добавить x-com (который находится в EUS) к TM и сделать его приоритетным 1, у него был бы собственный домен, все хорошо .. за исключением того, что больше нет западных настроек. Возможно, мне придется добавить его обратно
Я застрял; Мне в основном нужны две службы приложений в одном и том же регионе в разных тарифных планах, чтобы на некоторое время иметь один и тот же пользовательский домен, чтобы я мог переключиться на DNS и затем демонтировать одну из них. Или мне нужен другой способ настроить новый сервис приложений, чтобы он был готов принять трафик c, получить весь трафик c, чтобы начать переход к нему, а затем удалить старую настройку
Какие шаги могут Я взял, чтобы запустить новую службу приложений, дать ей собственный домен, а затем переключить DNS, чтобы весь трафик c перешел на новый сайт, не вызывая простоев?