Руководство. Создание высокодоступного приложения с несколькими регионами в Служба приложений Azure

Высокий уровень доступности и отказоустойчивость являются ключевыми компонентами хорошо спроектированного решения. Надежная конфигурация включает план аварийного реагирования на непредвиденные сбои, чтобы сократить время простоя и обеспечить автоматическое выполнение систем.

При развертывании приложения в облаке вы выбираете регион в этом облаке для базы инфраструктуры приложений. Если вы развертываете приложение только в одном регионе, а этот регион становится недоступным, приложение также недоступно. Отсутствие доступности может быть неприемлемым в соответствии с условиями соглашения об уровне обслуживания приложения (SLA). Чтобы обеспечить доступность, разверните приложение и его службы в нескольких регионах в облаке.

В этом руководстве описывается развертывание высокодоступного веб-приложения с несколькими регионами. Процедура реализует простой сценарий, состоящий из веб-приложения и Azure Front Door. Вы можете расширить основные понятия для поддержки других шаблонов инфраструктуры. Например, если приложение подключается к службе базы данных Azure или к хранилищу, см. статью Активная георепликация для баз данных SQL и служба хранилища Azure резервирование. См. эталонную архитектуру для более подробного сценария в шаблоне надёжного веб-приложения для .NET.

Изучив это руководство, вы:

Создание идентичных приложений App Service в отдельных регионах
Создание Azure Front Door с ограничениями доступа для блокировки общедоступного доступа к Службе приложений

Предварительные требования

Если у вас нет учетной записи Azure, создайте учетную запись free перед началом работы.

Чтобы завершить это руководство:

Используйте среду Bash в Azure Cloud Shell. Для получения дополнительной информации см. Начало работы с Azure Cloud Shell.
Если вы предпочитаете локально запускать справочные команды CLI, установите Azure CLI. Если вы работаете на Windows или macOS, попробуйте запустить Azure CLI в контейнере Docker. Дополнительные сведения см. в разделе Как запустить Azure CLI в контейнере Docker.
- Если вы используете локальную установку, войдите в Azure CLI с помощью команды az login. Чтобы выполнить аутентификацию, следуйте инструкциям в окне терминала. Другие параметры входа см. в разделе Аутентификация в Azure с помощью Azure CLI.
- При появлении запроса установите расширение Azure CLI при первом использовании. Дополнительные сведения о расширениях см. в разделе Использование расширений и управление ими с помощью Azure CLI.
- Выполните команду az version, чтобы узнать установленную версию и зависимые библиотеки. Чтобы обновиться до последней версии, выполните команду az upgrade.

Просмотр архитектуры сценария

На следующей схеме архитектуры показана инфраструктура, созданная в этом руководстве. Он состоит из двух идентичных приложений App Service в отдельных регионах. Первое веб-приложение находится в активном регионе. Это основное приложение, ответственное за обработку входящего трафика. Второе приложение находится в резервном регионе и ожидает доступности основного приложения. Azure Front Door пытается маршрутизировать трафик к основному веб-приложению. Если основной регион недоступен, трафик направляется в резервный веб-сайт. На схеме точка представляет маршрутизацию трафика на основе состояния региона. Ограничения доступа настроены так, чтобы блокировать прямой доступ к приложениям из Интернета.

Схема, демонстрирующая архитектуру службы приложений с несколькими регионами.

Azure предоставляет различные варианты балансировки нагрузки и маршрутизации трафика. Azure Front Door выбран для этого руководства, поскольку он предназначен для веб-приложений, доступных из Интернета и размещенных на Служба приложений Azure, которые развернуты в нескольких регионах. Если конфигурация отличается от примера в этом руководстве, см. статью "Выбор решения для балансировки нагрузки" для вашего сценария.

Сценарий в этом руководстве обеспечивает следующее поведение:

Идентичные приложения App Service развернуты в двух отдельных регионах.
Общедоступный трафик, отправляемый непосредственно в веб-приложения, блокируется.
Azure Front Door направляет трафик в активное приложение в основном регионе.
Резервное приложение в дополнительном регионе доступно для обслуживания трафика по мере необходимости.

Создайте группу ресурсов

Для работы с этим руководством требуется два экземпляра веб-приложения, выполняющегося в разных регионах Azure.

Просмотрите доступные пары регионов и выберите два парных региона для веб-приложений.

В этом руководстве два региона называются <primary-region> (eastus) и <standby-region> (westus).

Создайте группу ресурсов для всех ресурсов, настроенных в этом руководстве. В этом учебном пособии создается группа ресурсов в расположении <primary-region>.

az group create --name <resource-group> --location <primary-region>

Замените следующие <placeholder> значения параметров сведениями для собственных ресурсов:

Параметр	Значение	Описание	Пример
`--name`	`<resource-group>`	Группа ресурсов, содержащая объекты, созданные в этом учебном пособии.	`zava-resource-group`
`--location`	`<primary-region>`	Расположение региона для группы ресурсов. В этом руководстве используется то же расположение региона для группы ресурсов и основного веб-приложения.	`eastus`

В фактической реализации используйте отдельные группы ресурсов для каждого региона или ресурса. Разделение позволяет изолировать ресурсы в ситуации аварийного восстановления.

Дополнительные сведения см. в справочнике команд az group create.

Создание двух планов службы приложений

Создайте два плана службы приложений, по одному для каждого веб-приложения. Создайте каждый план в регионе, где вы планируете создавать соответствующее приложение.

Для этой команды используется пара регионов , выбранная ранее. Используйте активный регион для основного веб-приложения и пассивного региона для резервного веб-приложения.

Выполните следующую команду, чтобы создать план службы приложений для основного веб-приложения и снова запустите команду, чтобы создать план для резервного приложения.

az appservice plan create --name <app-service-plan> --resource-group <resource-group> --is-linux --location `<region>`

Замените следующие <placeholder> значения параметров сведениями для собственных ресурсов:

Параметр	Значение	Описание	Пример
`--name`	`<app-service-plan>`	Имя плана службы приложений для веб-приложения. Каждый экземпляр плана должен иметь уникальное имя.	`zava-primary-plan` `zava-standby-plan`
`--resource-group`	`<resource-group>`	Группа ресурсов, содержащая объекты, созданные в этом учебном пособии.	`zava-resource-group`
`--location`	`<region>`	Расположение региона для веб-приложения.	— основное веб-приложение, активный регион `eastus` — резервное веб-приложение, пассивный регион `westus`

Дополнительные сведения см. в справочнике az appservice plan create.

Создание двух приложений

Создайте два веб-приложения службы приложений. Поместите каждое приложение в соответствующий план службы приложений и соответствующий регион.

Определите языковую --runtime версию веб-приложений.

Для списка доступных сред выполнения можно выполнить следующую команду:
```
az webapp list-runtimes
```
Если вы планируете использовать пример приложения Node.js, описанного в этом руководстве, задайте для <language-version> значение NODE:24-lts.

Создайте два веб-приложения. Выполните следующую команду, чтобы создать основное веб-приложение и снова запустите команду, чтобы создать резервное приложение.

az webapp create --name <web-app-name> --resource-group <resource-group> --plan <app-service-plan> --runtime <language-version>

Замените следующие <placeholder> значения параметров сведениями для собственных ресурсов:

Параметр	Значение	Описание	Пример
`--name`	`<web-app-name>`	имя веб-приложения. Каждое приложение должно иметь глобально уникальное имя. Допустимые символы: `a-z`, `0-9`и `-`.	`zava-primary-app` `zava-standby-app`
`--resource-group`	`<resource-group>`	Группа ресурсов, содержащая объекты, созданные в этом учебном пособии.	`zava-resource-group`
`--name`	`<app-service-plan>`	Имя плана службы приложений для веб-приложения.	`zava-primary-plan` `zava-standby-plan`
`--runtime`	`<language-version>`	Версия языка среды выполнения для веб-приложения.	`NODE:24-lts`

Дополнительные сведения см. в справочнике по команде az webapp create.

Определите defaultHostName значение для каждого веб-приложения. Формат имени узла .<web-app-name>.azurewebsites.net

Проверьте выходные данные команды для каждого веб-приложения и найдите значение или выполните следующую команду для каждого веб-приложения:

az webapp show --name <web-app-name> --resource-group <resource-group> --query "hostNames"

Замените следующие <placeholder> значения параметров сведениями для собственных ресурсов:

Параметр	Значение	Описание	Пример
`--name`	`<web-app-name>`	имя веб-приложения.	`zava-primary-app` `zava-standby-app`
`--resource-group`	`<resource-group>`	Группа ресурсов, содержащая объекты, созданные в этом учебном пособии.	`zava-resource-group`

На портале Azure имя узла для каждого приложения отображается на странице веб-приложения Overview.

Запишите значения имени узла для последующего использования. Имена узлов используются для определения внутренних адресов для развертывания Azure Front Door.

Убедитесь, что вы можете получить доступ к новым веб-приложениям.
1. В браузере введите имя узла для основного веб-приложения, например zava-primary-app.azurewebsites.net.
  
  После успешного завершения подключения отображается следующее сообщение:
2. Повторите тест с именем узла для резервного веб-приложения.

Настройка Azure Front Door

Развертывание с несколькими регионами может использовать конфигурацию "активный—активный" или "активный-пассивный". Основной регион активен, а резервный регион является пассивным.

Конфигурация active-active распределяет запросы по нескольким активным регионам.
Конфигурация "активный-пассивный" поддерживает запуск экземпляров в резервном (пассивном) регионе, но не направляет трафик туда, если основной (активный) регион не перестает функционировать.

Azure Front Door позволяет включить обе конфигурации. Дополнительные сведения о разработке приложений с высокой доступностью и отказоустойчивостью см. в контрольном списке проектирования для надежности.

Создание профиля

Создайте экземпляр Azure Front Door Premium для маршрутизации трафика в веб-приложения.

Просмотрите сравнение уровней Azure Front Door и выберите уровень для развертывания.

В этом руководстве используется Azure Front Door Premium (Premium_AzureFrontDoor).

Если вы предпочитаете развертывать Azure Front Door standard, помните, что уровень "Стандартный" не поддерживает развертывание управляемых правил с помощью политики WAF.

Выполните следующую команду, чтобы создать профиль:

az afd profile create --profile-name <front-door-profile> --resource-group <resource-group> --sku <front-door-tier>

Замените следующие <placeholder> значения параметров сведениями для собственных ресурсов:

Параметр	Значение	Описание	Пример
`--profile-name`	`<front-door-profile>`	Имя профиля Azure Front Door. Имя должно быть уникальным в пределах группы ресурсов.	`zava-profile`
`--resource-group`	`<resource-group>`	Группа ресурсов, содержащая объекты, созданные в этом учебном пособии.	`zava-resource-group`
`--sku`	`<front-door-tier>`	Номер SKU уровня Azure Front Door для развертывания.	`Premium_AzureFrontDoor` (рекомендуется) `Standard_AzureFrontDoor`

Дополнительные сведения см. в справочнике по команде az afd profile create .

Добавление конечной точки

Создайте конечную точку в профиле. После создания первой конечной точки можно создать несколько конечных точек в профиле.

az afd endpoint create --resource-group <resource-group> --endpoint-name <front-door-endpoint> --profile-name <front-door-profile> --enabled-state Enabled

Замените следующие <placeholder> значения параметров сведениями для собственных ресурсов:

Параметр	Значение	Описание	Пример
`--resource-group`	`<resource-group>`	Группа ресурсов, содержащая объекты, созданные в этом учебном пособии.	`zava-resource-group`
`--endpoint-name`	`<front-door-endpoint>`	Имя конечной точки подключения в профиле Azure Front Door. Это имя должно быть глобально уникальным.	`zava-endpoint`
`--profile-name`	`<front-door-profile>`	Имя профиля Azure Front Door.	`zava-profile`

Дополнительные сведения см. в руководстве по команде az afd endpoint create.

Создание группы источников

При развертывании в Azure Front Door необходимо, чтобы источник служил в качестве конечной точки для серверной части веб-приложения. Дополнительные сведения см. в разделе Origins и группы источников в Azure Front Door. Источники хранятся в группе источников.

Создайте группу источников в профиле Azure Front Door, чтобы содержать источники для двух веб-приложений.

az afd origin-group create --resource-group <resource-group> --origin-group-name <front-door-origin-group> --profile-name <front-door-profile> \
   --probe-request-type <probe-request> \
   --probe-protocol <probe-protocol> \
   --probe-interval-in-seconds <probe-interval> \
   --probe-path <probe-path> \
   --sample-size <sample-size> \
   --successful-samples-required <required-samples> \
   --additional-latency-in-milliseconds <extra-latency>

Замените следующие <placeholder> значения параметров сведениями для собственных ресурсов:

Параметр	Значение	Описание	Пример
`--resource-group`	`<resource-group>`	Группа ресурсов, содержащая объекты, созданные в этом учебном пособии.	`zava-resource-group`
`--origin-group-name`	`<front-door-origin-group>`	Имя группы источника Azure Front Door. Это имя должно быть глобально уникальным.	`zava-origin-group`
`--profile-name`	`<front-door-profile>`	Имя профиля Azure Front Door.	`zava-profile`
`--probe-request-type`	`<probe-request>`	Тип запроса проверки состояния.	`GET`
`--probe-protocol`	`<probe-protocol>`	Протокол, используемый для пробы работоспособности.	`Http`
`--probe-interval-in-seconds`	`<probe-interval>`	Число секунд между выполнением проб работоспособности.	60
`--probe-path`	`<probe-path>`	Путь относительно источника, который используется для определения работоспособности источника.	`/` (обратная косая черта)
`--sample-size`	`<sample-size>`	Количество выборок, рассматриваемых при балансировке нагрузки.	4
`--successful-samples-required`	`<required-samples>`	Количество выборок в рамках периода выборки, которые должны быть успешными.	3
`--additional-latency-in-milliseconds`	`<extra-latency>`	Дополнительное время задержки в миллисекундах для зондов, чтобы попасть в сегмент с минимальной задержкой.	50

Дополнительные сведения см. в справочнике по команде az afd origin-group create.

Добавление источников в группу источников

Добавьте источник для каждого веб-приложения в группу источников Azure Front Door.

Добавьте источник для основного веб-приложения. Задайте для параметра --priority значение 1, которое сообщает Azure Front Door, что это приложение является основным получателем трафика.

az afd origin create --resource-group <resource-group> --host-name <web-app-name>.azurewebsites.net --profile-name <front-door-profile> \
   --origin-group-name <front-door-origin-group> \
   --origin-name <web-app-origin-name> \
   --origin-host-header <web-app-name>.azurewebsites.net \
   --priority <origin-priority> --weight <origin-weight> --enabled-state <origin-state> \
   --http-port <origin-port> --https-port <origin-secure-port>

Замените следующие <placeholder> значения параметров сведениями для собственных ресурсов:

Параметр	Значение	Описание	Пример
`--resource-group`	`<resource-group>`	Группа ресурсов, содержащая объекты, созданные в этом учебном пособии.	`zava-resource-group`
`--host-name`	`<web-app-name>.azurewebsites.net`	Имя узла для вашего основного веб-приложения. Имя узла объединяет имя веб-приложения, например `zava-primary-app` с идентификатором `azurewebsites.net`узла.	`zava-primary-app.azurewebsites.net`
`--profile-name`	`<front-door-profile>`	Имя профиля Azure Front Door.	`zava-profile`
`--origin-group-name`	`<front-door-origin-group>`	Имя группы источника Azure Front Door.	`zava-origin-group`
`--origin-name`	`<web-app-origin-name>`	Имя источника для основного веб-приложения. Имя должно быть уникальным в группе происхождения.	`primary-origin`
`--origin-host-header`	`<web-app-name>.azurewebsites.net`	Заголовок узла для отправки запросов к основному источнику веб-приложения. Если значение не указано, имя узла запроса определяет это значение. Azure CDN серверы происхождения, такие как веб-приложения, хранилища Blob и облачные службы, требуют, чтобы это значение заголовка узла по умолчанию соответствовало имени узла происхождения.	`zava-primary-app.azurewebsites.net`
`--priority`	`<origin-priority>`	Приоритет для этого источника в группе источников. Для основного веб-приложения задайте приоритет 1. Azure Front Door использует значения приоритета для балансировки нагрузки между источниками и активными регионами. Значение должно быть от 1 до 5.	1
`--weight`	`<origin-weight>`	Вес источника в группе источников для балансировки нагрузки. Значение должно быть от 1 до 1000.	1000
`--enabled-state`	`<origin-state>`	Укажите, следует ли включить этот источник для получения трафика.	`Enabled`
`--http-port`	`<origin-port>`	Порт, используемый для HTTP-запросов к источнику.	80
`--https-port`	`<origin-secure-port>`	Порт, используемый для защищенных HTTPS-запросов к источнику.	443

Дополнительные сведения см. в справке о команде az afd origin create.

Запустите команду еще раз и добавьте источник для резервного веб-приложения. Команда использует те же параметры, но со следующими уникальными значениями параметров:

Параметр	Значение	Описание	Пример
`--host-name`	`<web-app-name>.azurewebsites.net`	Имя хоста для резервного веб-приложения.	`zava-standby-app.azurewebsites.net`
`--origin-name`	`<web-app-origin-name>`	Имя источника для резервного веб-приложения.	`standby-origin`
`--origin-host-header`	`<web-app-name>.azurewebsites.net`	Заголовок хоста для отправки запросов на резервный источник веб-приложения.	`zava-standby-app.azurewebsites.net`
`--priority`	`<origin-priority>`	Приоритет для этого источника в группе источников. Для резервного веб-приложения задайте приоритет 2. Azure Front Door пытается направить весь трафик к основному источнику. Если основной источник недоступен, трафик направляется в резервный источник.	2

Добавление правила маршрута

Добавьте правило маршрутизации для сопоставления конечной точки Azure Front Door с группой источников. Маршрут перенаправит запросы из конечной точки в группу источников.

Создайте правило маршрута для сопоставления конечной точки Azure Front Door с группой источников:

az afd route create --resource-group <resource-group> --profile-name <front-door-profile> --endpoint-name <front-door-endpoint> `
   --forwarding-protocol <protocol-type> --route-name <route-rule-name> --https-redirect <secure-redirect> `
   --origin-group <front-door-origin-group> --supported-protocols <protocol-list> --link-to-default-domain <domain-link>

Замените следующие <placeholder> значения параметров сведениями для собственных ресурсов:

Параметр	Значение	Описание	Пример
`--resource-group`	`<resource-group>`	Группа ресурсов, содержащая объекты, созданные в этом учебном пособии.	`zava-resource-group`
`--profile-name`	`<front-door-profile>`	Имя профиля Azure Front Door.	`zava-profile`
`--endpoint-name`	`<front-door-endpoint>`	Имя конечной точки в профиле Azure Front Door.	`zava-endpoint`
`--forwarding-protocol`	`<protocol-type>`	Протокол, используемый этим правилом маршрута при переадресации трафика в внутренние приложения.	`MatchRequest`
`--route-name`	`<route-rule-name>`	Имя правила маршрута. Должен быть уникальным в рамках профиля Azure Front Door.	`zava-route-rule`
`--https-redirect`	`<secure-redirect>`	Указывает, следует ли автоматически перенаправлять HTTP-трафик в трафик HTTPS.	`Enabled`
`--origin-group-name`	`<front-door-origin-group>`	Имя группы источника Azure Front Door.	`zava-origin-group`
`--supported-protocols`	`<protocol-list>`	Список поддерживаемых протоколов для этого правила маршрута. Используйте пространство для разделения типов протоколов.	`Http Https`
`--link-to-default-domain`	`<domain-link>`	Укажите, связан ли этот маршрут с доменом конечной точки по умолчанию.	`Enabled`

Дополнительные сведения см. в справочнике по утилите az afd route create.

Оставьте около 15 минут на завершение развертывания. Для глобального распространения изменений может потребоваться некоторое время.

Ограничение доступа только через Azure Front Door

В настоящее время вы можете получить доступ к веб-приложениям напрямую, введя имена узлов в браузере. Если вы настроили ограничения доступа к приложениям, вы можете обеспечить доступ к приложениям только через Azure Front Door.

Azure Front Door функции лучше всего работают, если трафик проходит только через службу. Рекомендуется настроить источники веб-приложения для блокировки трафика, который не отправляется через Azure Front Door. В противном случае трафик может обойти брандмауэр веб-приложения Azure Front Door, защиту от атак DDoS и другие функции безопасности.

Трафик из Azure Front Door в приложения происходит из известного набора диапазонов IP-адресов, определенных в теге службы AzureFrontDoor.Backend. С помощью правила ограничения тега службы можно ограничить трафик, чтобы он поступал только из Azure Front Door.

Получите идентификатор для профиля Azure Front Door.

Вам нужен идентификатор профиля, чтобы убедиться, что трафик поступает только из конкретного экземпляра Azure Front Door. Ограничение доступа дополнительно фильтрует входящие запросы на основе уникального заголовка HTTP, отправленного из профиля Azure Front Door.

az afd profile show --resource-group <resource-group> --profile-name <front-door-profile> --query "frontDoorId"

Замените следующие <placeholder> значения параметров сведениями для собственных ресурсов:

Параметр	Значение	Описание	Пример
`--resource-group`	`<resource-group>`	Группа ресурсов, содержащая объекты, созданные в этом учебном пособии.	`zava-resource-group`
`--profile-name`	`<front-door-profile>`	Имя профиля Azure Front Door.	`zava-profile`

В выходных данных команды отображается идентификатор профиля (32-цифрное буквенно-цифровое значение):

"0000aaaa-1b1b-2c2c-3d3d-444444eeeeee"

На следующем шаге используйте идентификатор профиля в качестве значения для <profile-identifier>.

Выполните следующую команду, чтобы задать ограничения доступа к основному веб-приложению и снова запустите команду, чтобы задать ограничения для резервного приложения.

az webapp config access-restriction add --resource-group <resource-group> --name <web-app-name> `
   --priority <access-priority> --service-tag <tag-name> --http-header x-azure-fdid=<front-door-id>

Замените следующие <placeholder> значения параметров сведениями для собственных ресурсов:

Параметр	Значение	Описание	Пример
`--resource-group`	`<resource-group>`	Группа ресурсов, содержащая объекты, созданные в этом учебном пособии.	`zava-resource-group`
`--name`	`<web-app-name>`	Имя веб-приложения, для которого вы настраиваете ограничения доступа.	`zava-primary-app` `zava-standby-app`
`--priority`	`<access-priority>`	Укажите приоритет правила ограничения доступа во всех правилах, определенных для профиля. Более низкое значение равно более высокому приоритету.	100
`--service-tag`	`<tag-name>`	Имя тега сервиса, распознаваемое Azure Front Door. Ограничения доступа применяются к диапазону IP-адресов, указанному тегом службы.	`AzureFrontDoor.Backend`
`--http-header`	`x-azure-fdid=<profile-identifier>`	Укажите один или несколько уникальных заголовков HTTP для дополнительной фильтрации входящего трафика. Ограничения доступа фильтруют входящие запросы на основе уникального заголовка HTTP, отправленного из профиля Azure Front Door. Заголовок объединяет префикс Azure Front Door и идентификатор профиля для экземпляра Azure Front Door.	`x-azure-fdid=0000aaaa-1b1b-2c2c-3d3d-444444eeeeee`

Дополнительные сведения см. в справочнике по команде az webapp config access-restriction add.

Проверка ограничений доступа

Убедитесь, что ограничения доступа препятствуют прямому доступу к приложениям.

В браузере введите имя узла для основного веб-приложения, например zava-primary-app.azurewebsites.net.

Подключение должно завершиться ошибкой со следующим сообщением:
Повторите тест с именем узла для резервного веб-приложения, например zava-standby-app.azurewebsites.net.

Тестирование развертывания Azure Front Door

При создании профиля Azure Front Door уровня "Стандартный" или "Премиум" может потребоваться некоторое время для глобального развертывания конфигурации. После завершения развертывания вы можете получить доступ к хосту интерфейса.

Получите имя хоста конечной точки Azure Front Door.

az afd endpoint show --resource-group <resource-group> --profile-name <front-door-profile> --endpoint-name <front-door-endpoint> --query "hostName"

Замените следующие <placeholder> значения параметров сведениями для собственных ресурсов:

Параметр	Значение	Описание	Пример
`--resource-group`	`<resource-group>`	Группа ресурсов, содержащая объекты, созданные в этом учебном пособии.	`zava-resource-group`
`--profile-name`	`<front-door-profile>`	Имя профиля Azure Front Door.	`zava-profile`
`--endpoint-name`	`<front-door-endpoint>`	Имя конечной точки в профиле Azure Front Door.	`zava-endpoint`

Выходные данные команды отображают хостнейм конечной точки.

"zava-endpoint-0a1b2c3d4e5f6g78.z00.azurefd.net"

Имя узла состоит из имени конечной точки, уникального буквенно-цифрового хэша, идентификатора и суффикса Azure Front Door. На следующем шаге вы используете адрес узла конечной точки.

Дополнительные сведения см. в справочнике по команде az afd endpoint show.

В браузере введите имя узла конечной точки, например zava-endpoint-0a1b2c3d4e5f6g78.z00.azurefd.net.

Запрос должен автоматически направляться в основное приложение в активном регионе.

После успешного завершения подключения отображается следующее сообщение:
Тестирование мгновенного глобального переключения между приложениями в парных регионах.
1. В браузере введите имя узла конечной точки, например zava-endpoint-0a1b2c3d4e5f6g78.z00.azurefd.net.
2. Остановите основное приложение, выполнив команду az webapp stop .
  
  Замените следующие <placeholder> значения параметров сведениями для собственных ресурсов:
```
az webapp stop --name <primary-web-app> --resource-group <resource-group>
```
3. Обновите свой браузер.
  
  Если трафик правильно перенаправляется в резервное приложение в другом регионе, вы увидите ту же страницу и сообщение.
  
  Подсказка
  
  Чтобы завершить отработку отказа, может потребоваться обновить страницу несколько раз.
  
  Вы можете подтвердить, что Azure Front Door перенаправляется в резервное приложение, проверив состояние веб-приложений на портале Azure. На странице обзора основного веб-приложения параметр "Пуск " должен быть доступен (не серый). На странице "Обзор " для резервного веб-приложения параметр "Пуск " не должен быть доступен (серый).
4. Запустите команду еще раз и остановите az webapp stop приложение.
  
  Замените следующие <placeholder> значения параметров сведениями для собственных ресурсов:
```
az webapp stop --name <standby-web-app> --resource-group <resource-group>
```
5. Обновите браузер еще раз.
  
  Если резервное приложение также остановится, маршрутизация трафика должна остановиться. На этот раз появится сообщение об ошибке:
6. Выполните команду и перезапустите az webapp start приложение.
  
  Замените следующие <placeholder> значения параметров сведениями для собственных ресурсов:
```
az webapp start --name <standby-web-app> --resource-group <resource-group>
```
7. Обновите браузер и увидите успешное подключение к приложению.

Проверка подтверждает, что теперь вы можете получить доступ к приложениям с помощью Azure Front Door и функций отработки отказа, как это необходимо.

Если вы завершили тестирование переключения на резервный ресурс, снова запустите основное приложение.

Очистка ресурсов

На предыдущих этапах вы создали ресурсы Azure в группе ресурсов Azure. Если вы не ожидаете, что эти ресурсы потребуются в будущем, удалите группу ресурсов, выполнив следующую команду в Cloud Shell.

Замените <placeholder> значение параметра сведениями для собственного ресурса:

az group delete --name <resource-group>

Выполнение этой команды может занять несколько минут.

Развертывание из ARM или Bicep

Ресурсы, созданные в этом руководстве, можно развернуть с помощью шаблона Azure Resource Manager (шаблона ARM) или шаблона Bicep. Вы можете начать с файла Bicep высокодоступного многорегионального веб-приложения на GitHub. Этот шаблон помогает создать безопасное, высокодоступное, мульти-региональное конечное решение с двумя веб-приложениями, расположенными в разных регионах, работающими через Azure Front Door.

Инструкции по развертыванию шаблонов ARM и Bicep см. в статье Развертывание файлов Bicep с помощью Azure CLI.

Часто задаваемые вопросы

В этом руководстве вы развернули базовую инфраструктуру для поддержки многорегионального веб-приложения. Служба приложений предоставляет функции, которые помогут вам обеспечить выполнение приложений, соответствующих лучшим практикам и рекомендациям по безопасности.

В этом разделе содержатся ответы на часто задаваемые вопросы, которые помогут вам защитить приложения и развернуть ресурсы и управлять ими в соответствии с рекомендациями.

Управление инфраструктурой и развертыванием ресурсов Azure

В этом руководстве вы использовали Azure CLI для развертывания ресурсов инфраструктуры. Рассмотрите возможность настройки механизма непрерывного развертывания для управления инфраструктурой приложений. Так как вы развертываете ресурсы в разных регионах, необходимо независимо управлять этими ресурсами в разных регионах. Чтобы гарантировать, что ресурсы идентичны в каждом регионе, инфраструктура как код (IaC), например шаблон ARM или Terraform следует использовать с конвейерами развертывания, такими как Azure Pipelines или GitHub Actions. При правильной настройке этой конфигурации все изменения ресурсов активируют обновления во всех регионах развертывания. Для получения дополнительной информации см. раздел Настройка непрерывного развертывания для Служба приложений Azure.

Использование тестовых слотов для безопасного развертывания в продуктивной среде

Развертывание кода приложения непосредственно в рабочих приложениях и слотах не рекомендуется. Важно иметь безопасное место для тестирования приложений и проверки изменений перед отправкой в рабочую среду. Используйте сочетание промежуточных слотов и переключения слотов для перемещения кода из среды тестирования в рабочую среду.

В этом руководстве вы создали базовую инфраструктуру, которая поддерживает использование промежуточных слотов. Вы можете создать слоты развертывания для каждого экземпляра веб-приложения и настроить непрерывное развертывание для этих промежуточных слотов с GitHub Actions. Как и в случае управления инфраструктурой, настройка непрерывного развертывания для исходного кода приложения также рекомендуется обеспечить синхронизацию изменений в разных регионах. Если вы не настраиваете непрерывное развертывание, необходимо вручную обновлять каждое приложение в каждом регионе при каждом изменении кода.

Чтобы использовать промежуточные слоты, выполните следующую процедуру:

Для этой процедуры вам потребуется приложение, готовое к развертыванию в приложении Службы приложений.

Если вы завершили учебник, вы можете использовать основное веб-приложение и резервное веб-приложение. Однако вам нужен план App Service, который поддерживает достаточно слотов для развертывания. Дополнительные сведения см. в разделе Пределы подписок и служб Azure, квоты и ограничения.

Если у вас нет приложения, можно начать с примера приложения Node.js Hello World. Форкните репозиторий на GitHub, чтобы у вас была своя копия для внесения изменений.
Настройте параметры стека службы приложений для веб-приложений.

Параметры стека относятся к языковой версии или среде выполнения, используемой для приложения.

Параметры можно настроить на портале Azure или использовать команду az webapp config set. Если вы используете пример Node.js, задайте для параметров стека значение Node 24 LTS.
1. На портале Azure перейдите в ваше основное веб-приложение.
2. В меню слева выберите "Конфигурация параметров>".
3. На вкладке "Параметры стека " настройте следующие параметры:
  1. Выберите значение стека , например Node.
  2. Выберите значение версии, такое как Node 24 LTS.
  3. Нажмите кнопку "Применить".
4. Повторите процесс, чтобы настроить параметры стека службы приложений для резервного веб-приложения.
Настройте непрерывное развертывание на портале Azure. Подробные инструкции по настройке непрерывного развертывания с такими поставщиками, как GitHub Actions, см. в статье Настройка непрерывного развертывания для Служба приложений Azure.
Выполните следующую команду, чтобы создать промежуточный слот с именем stage для вашего основного веб-приложения.
```
az webapp deployment slot create --resource-group <resource-group> --name <web-app-name> --slot stage --configuration-source <web-app-name>
```
az webapp deployment slot create Запустите команду еще раз и создайте промежуточный слот с именем stageрезервного веб-приложения.

Настройте непрерывное развертывание с GitHub Actions для каждого промежуточного слота:

На портале Azure перейдите в ваше основное веб-приложение.
В меню слева выберите Развертывание>слоты развертывания.
Найдите слот этапа в списке и выберите слот, чтобы открыть область сведений.
В меню слева выберите Развертывание>Центр развертывания.
На вкладке Settings установите параметр Source значение GitHub:
Если вы впервые развертываете из GitHub, выберите Authorize и следуйте указаниям по авторизации. Если требуется выполнить развертывание из другого пользовательского репозитория, выберите Изменить учетную запись.

После авторизации учетной записи Azure с помощью GitHub выберите Organization, Repository и Branch для настройки CI/CD. Если вы не можете найти организацию или репозиторий, может потребоваться включить дополнительные разрешения на GitHub. Дополнительные сведения см. в статье "Управление доступом пользователей к репозиториям организации".

Если вы используете пример приложения Node.js, используйте следующие параметры.

Настройка	Значение
Предприятие	`<your-GitHub-organization>`
Репозиторий	nodejs-docs-hello-world
Филиал	главный

Выберите Сохранить.

Новые коммиты в выбранном репозитории и ветви теперь непрерывно развертываются в слот вашего приложения в среде App Service. Фиксации и развертывания можно отслеживать на вкладке Журналы.

Файл рабочего процесса по умолчанию, использующий профиль публикации для проверки подлинности в службе приложений, добавляется в репозиторий GitHub. Этот файл можно просмотреть, перейдя в <repo-name>/.github/workflows/ каталог.

Отключение базовой проверки подлинности в службе приложений

Доступ к конечным точкам FTP и SCM можно ограничить пользователям, поддерживаемым Microsoft Entra ID, отключив базовую проверку подлинности.

Если вы используете средство непрерывного развертывания для развертывания исходного кода приложения, отключение базовой проверки подлинности требует дополнительных шагов для настройки непрерывного развертывания. Например, нельзя использовать профиль публикации, так как он не использует учетные данные Microsoft Entra. Вместо этого необходимо использовать служебный принципал или учетные данные OpenID Connect.

Следующие команды отключают базовую проверку подлинности для основного веб-приложения службы приложений и промежуточного слота, а также резервного веб-приложения и промежуточного слота. Замените следующие <placeholder> значения параметров сведениями для собственных ресурсов.

Отключите доступ по FTP для производственных сред и тестовых слотов вашего основного веб-приложения:

az resource update --resource-group <resource-group> --name ftp --namespace Microsoft.Web --resource-type basicPublishingCredentialsPolicies \
   --parent sites/<web-app-name> --set properties.allow=false

az resource update --resource-group <resource-group> --name ftp --namespace Microsoft.Web --resource-type basicPublishingCredentialsPolicies \
   --parent sites/<web-app-name>/slots/stage --set properties.allow=false

Снова выполните команды для резервного веб-приложения.

Отключите базовый доступ к порту WebDeploy и сайту SCM для рабочих сайтов и промежуточных слотов для основного веб-приложения:

az resource update --resource-group <resource-group> --name scm --namespace Microsoft.Web --resource-type basicPublishingCredentialsPolicies \
   --parent sites/<primary-web-app> --set properties.allow=false

az resource update --resource-group <resource-group> --name scm --namespace Microsoft.Web --resource-type basicPublishingCredentialsPolicies \
   --parent sites/<primary-web-app>/slots/stage --set properties.allow=false

Снова выполните команды для резервного веб-приложения.

Дополнительные сведения об отключении базовой проверки подлинности, включая тестирование и мониторинг входов, см. в статье "Отключение базовой проверки подлинности в развертываниях Службы приложений".

Использование непрерывного развертывания при отключении базовой проверки подлинности

Если вы решили разрешить обычную проверку подлинности в приложениях службы приложений, можно использовать любой из доступных методов развертывания в Службе приложений. Например, можно использовать профиль публикации, настроенный в разделе слотов промежуточной среды.

Если вы отключите базовую проверку подлинности для приложений App Service, для непрерывного развертывания потребуется учетная запись службы или OpenID Connect для аутентификации. Если вы используете GitHub Actions для автоматического развертывания из вашего репозитория кода, см. Развертывание в Служба приложений Azure с помощью GitHub Actions. В этом руководстве приведены пошаговые инструкции по созданию сервисного принципала или OpenID Connect для развертывания в App Service при помощи GitHub Actions. Вы также можете выполнить процесс, выполнив процедуру в следующем разделе.

Создание субъекта-службы и учетных данных с помощью GitHub Actions

Настройте непрерывное развертывание с помощью GitHub Actions и служебного принципала.

Создайте основной объект службы для вашего основного веб-приложения и резервного веб-приложения.

Замените следующие <placeholder> значения параметров сведениями для собственных ресурсов.
```
az ad sp create-for-rbac --name <service-principal-name> --role contributor --scopes \
   /subscriptions/<subscription-ID>/resourceGroups/<resource-group>/providers/Microsoft.Web/sites/<primary-web-app> \
   /subscriptions/<subscription-ID>/resourceGroups/<resource-group>/providers/Microsoft.Web/sites/<standby-web-app>
```
Выходные данные — это объект JSON с учетными данными назначения ролей, предоставляющими доступ к приложениям Служба приложений.
```
{
  "clientId": "00001111-aaaa-2222-bbbb-3333cccc4444",
  "clientSecret": "ffffffff-5a5a-6b6b-7c7c-888888888888",
  "subscriptionId": "cccc2c2c-dd3d-ee4e-ff5f-aaaaaa6a6a6a",
  "tenantId": "aaaabbbb-6666-cccc-7777-dddd8888eeee",
  "activeDirectoryEndpointUrl": "https://login.microsoftonline.com",
  "resourceManagerEndpointUrl": "https://management.azure.com/",
  "activeDirectoryGraphResourceId": "https://graph.windows.net/",
  "sqlManagementEndpointUrl": "https://management.core.windows.net:8443/",
  "galleryEndpointUrl": "https://gallery.azure.com/",
  "managementEndpointUrl": "https://management.core.windows.net/"
}
```
JSON включает секрет клиента, который отображается только в настоящее время.

Подсказка

Рекомендуется предоставить минимальный доступ. В этом примере область ограничена только приложениями, а не всей группой ресурсов.
Скопируйте объект JSON, чтобы у вас была запись секрета клиента.

Укажите учетные данные принципала службы для выполнения операции входа в Azure в рамках рабочего процесса GitHub Action.

Вы можете указать значения прямо в рабочем процессе или сохранить их как секреты GitHub, которые используются в вашем рабочем процессе. Сохранение значений в качестве GitHub секретов является более безопасным вариантом.

Откройте репозиторий GitHub для приложения.
Перейдите в Параметры>Безопасность>Секреты и переменные>Действия.

Выберите новый секрет репозитория и создайте секрет для каждого из следующих параметров. Используйте значения из выходных данных JSON.

Настройка	Значение	Пример
AZURE_APP_ID	`<application/client-id>`	`00001111-aaaa-2222-bbbb-3333cccc4444`
AZURE_PASSWORD	`<client-secret>`	`ffffffff-5a5a-6b6b-7c7c-888888888888`
AZURE_TENANT_ID	`<tenant-id>`	`aaaabbbb-6666-cccc-7777-dddd8888eeee`
AZURE_SUBSCRIPTION_ID	`<subscription-id>`	`cccc2c2c-dd3d-ee4e-ff5f-aaaaaa6a6a6a`

Создание рабочего процесса GitHub Actions

После того как у вас есть служебный принципал, который имеет доступ к вашим приложениям App Service, измените стандартные рабочие процессы для приложений. Эти рабочие процессы создаются автоматически при настройке непрерывного развертывания.

Аутентификация должна выполняться с помощью сервисного принципала вместо профиля публикации. Примеры рабочих процессов см. на вкладке Доверенные приложения в разделе Добавьте файл рабочего процесса в ваш репозиторий GitHub. Следующий пример рабочего процесса можно использовать для Node.js примера приложения.

Откройте репозиторий GitHub для приложения.
Перейдите в <repo-name>/.github/workflows/ каталог. Вы увидите автоматически созданные рабочие процессы.
Для каждого файла рабочего процесса выберите "Изменить " (карандаш).

Замените содержимое файла рабочего процесса следующим содержимым. В коде предполагается, что вы уже создали секреты GitHub для учетных данных.

env В разделе настройте следующие параметры:

AZURE_WEBAPP_NAME: Замените заполнитель <web-app-name> именем вашего веб-приложения.
NODE_VERSION: укажите используемую версию узла. Для примера Node.js значение равно '24.x'.
AZURE_WEBAPP_PACKAGE_PATH: укажите путь к проекту веб-приложения. По умолчанию используется корневой каталог '.'репозитория.
AZURE_WEBAPP_SLOT_NAME: укажите имя слота приложения. Общее имя — stage.


 name: Build and deploy Node.js app to Azure Web App

 on:
   push:
     branches:
       - main
   workflow_dispatch:

 env:
   AZURE_WEBAPP_NAME: <web-app-name>   # Your application name
   NODE_VERSION: '24.x'                # Node version to use
   AZURE_WEBAPP_PACKAGE_PATH: '.'      # Path to your web app project
   AZURE_WEBAPP_SLOT_NAME: stage       # Application slot name

 jobs:
   build:
     runs-on: ubuntu-latest

     steps:
       - uses: actions/checkout@v4

       - name: Set up Node.js version
         uses: actions/setup-node@v4
         with:
           node-version: ${{ env.NODE_VERSION }}

       - name: npm install, build
         run: |
           npm install
           npm run build --if-present

       - name: Upload artifact for deployment job
         uses: actions/upload-artifact@v4
         with:
           name: node-app
           path: .

   deploy:
     runs-on: ubuntu-latest
     needs: build
     environment:
       name: 'stage'
       url: ${{ steps.deploy-to-webapp.outputs.webapp-url }}

     steps:
       - name: Download artifact from build job
         uses: actions/download-artifact@v4
         with:
           name: node-app

       - uses: azure/login@v2
         with:
           creds: |
             {
               "clientId": "${{ secrets.AZURE_APP_ID }}",
               "clientSecret":  "${{ secrets.AZURE_PASSWORD }}",
               "subscriptionId": "${{ secrets.AZURE_SUBSCRIPTION_ID }}",
               "tenantId": "${{ secrets.AZURE_TENANT_ID }}"
             }

       - name: 'Deploy to Azure Web App'
         id: deploy-to-webapp
         uses: azure/webapps-deploy@v3
         with:
           app-name: ${{ env.AZURE_WEBAPP_NAME }}
           slot-name: ${{ env.AZURE_WEBAPP_SLOT_NAME }}
           package: ${{ env.AZURE_WEBAPP_PACKAGE_PATH }}

       - name: logout
         run: |
           az logout

Сохраните и зафиксируйте изменения файла рабочего процесса непосредственно в главной ветви репозитория.

Коммит вызывает выполнение GitHub Action снова для развертывания вашего кода. На этот раз субъект-служба используется для проверки подлинности.

Тестирование обновлений приложений с использованием маршрутизации трафика между слотами

Маршрутизация трафика с слотами позволяет направлять предопределенную часть пользовательского трафика к каждому слоту. Изначально 100% трафика направляется на рабочий сайт. Однако вы можете отправить 10% трафика в промежуточный слот. Этот подход к маршрутизации трафика слотов автоматически отправляет 10% пользователей, которые пытаются получить доступ к промежуточному слоту. Этот подход не требует изменений в вашем экземпляре Azure Front Door. Дополнительные сведения об обмене слотами и промежуточных средах в Службе приложений см. в статье Настройка промежуточных сред в службе приложений Azure.

Перемещение кода из тестового слота в производственный слот

После завершения тестирования и проверки промежуточных слотов можно выполнить переключение слотов с промежуточного слота на продуктивный слот. Вы завершили переключение для всех экземпляров вашего приложения в каждом регионе. Во время переключения слотов платформа Служба приложений гарантирует, что целевой слот не испытывает простоя.

Выполните переключение для основного веб-приложения:

az webapp deployment slot swap --resource-group <resource-group> -name <primary-web-app-name> --slot stage --target-slot production

Выполните переключение на standby веб-приложение:

az webapp deployment slot swap --resource-group <resource-group> -name <standby-web-app-name> --slot stage --target-slot production

Через несколько минут перейдите к конечной точке Azure Front Door в портале Azure и убедитесь, что переключение слотов прошло успешно.

На этом этапе ваши приложения запущены, и любые изменения, внесенные в исходный код вашего приложения, автоматически активируют обновление для обоих слотов подготовки. Затем можно повторить процесс переключения слотов, когда вы будете готовы переместить этот код в рабочую среду.

Избегайте сбоев и проблем непрерывности с помощью развертываний с несколькими регионами

Вы можете избежать потенциальных сбоев или проблем с непрерывностью между регионами, временно удалив сайт, который участвует в операции переключения слотов, из группы источников Azure Front Door. Это действие помогает предотвратить одновременное просмотр различных версий приложения клиентами. Это также полезно при внесении значительных изменений в приложения. Временное удаление приводит к перенаправлению всего трафика на другой сервер-источник.

На портале Azure перейдите к инстанции Azure Front Door.
В меню слева выберите Параметры>Группы источника.
В списке групп источников выберите группу источников, содержащую слот, который необходимо временно удалить.
На панели "Обновить группу источников " найдите слот для удаления в списке имен узла источника .
Выбор дополнительных действий (...) >Удалите и нажмите кнопку "Обновить".

Для применения изменения может потребоваться несколько минут.
Когда вы будете готовы разрешить трафик к удалённому слоту, вернитесь в область Обновление группы источника.
В верхней части выберите + Добавить источник, чтобы добавить слот источника обратно в группу источников.

Создание дополнительных групп источников и изменение связей маршрутов

Если вы предпочитаете не удалять и читать источники, можно создать дополнительные группы источников для вашего экземпляра Azure Front Door. Затем можно связать маршрут с группой источников, которая указывает на предполагаемый источник.

Например, можно создать две дополнительные группы источников, одну для основного (активного) региона, а также один для резервного (пассивного) региона. Если основной регион проходит изменение, свяжите маршрут с резервным регионом. Если резервный регион проходит изменение, свяжите маршрут с основным регионом. По завершении всех изменений можно связать маршрут с исходной группой источников, содержащей оба региона. Этот метод работает, так как маршрут может быть связан только с одной группой источников одновременно.

Рассмотрим конфигурацию с тремя группами источников:

Группа Main-Origin содержит как основные, так и резервные веб-приложения, которые находятся в своих соответствующих регионах.
Группа Primary-Origin содержит только основное веб-приложение в активном регионе.
Группа Standby-Origin содержит только резервное веб-приложение в пассивном регионе.

Предположим, что основное веб-приложение проходит изменение. Перед началом изменений ассоциация маршрутов для группы Main-Origin изменяется на группу Secondary-Origin. Это действие гарантирует перенаправление всего трафика в резервное веб-приложение в его регионе, в то время как в основном веб-приложении в том же регионе происходят изменения.

Выполните следующие действия, чтобы изменить ассоциацию маршрута для группы происхождения:

На портале Azure перейдите к инстанции Azure Front Door.
В меню слева выберите Параметры>Группы источника.
В списке групп источников найдите группу источников, отображающую индикатор unassociated в столбце "Маршруты ".
Выбор дополнительных действий (...) >Связывание конечной точки и маршрута.
В области "Связать маршруты " выберите один или несколько маршрутов, чтобы связаться с группой источников, а затем нажмите кнопку "Связать".

Ограничить доступ к сайту продвинутых инструментов

С помощью службы приложение Azure сайт SCM/advanced tools используется для управления приложениями и развертывания исходного кода приложения. Подумайте о блокировке сайта SCM/advanced tools, так как этот сайт, скорее всего, не требует доступа через Front Door. Например, можно настроить ограничения доступа, которые позволяют только вам проводить ваше тестирование и включать непрерывное развертывание из предпочитаемого вами инструмента. Если вы используете слоты развертывания, в частности для слотов для производства, вы можете запретить почти весь доступ к сайту SCM, так как тестирование и проверка выполняются с промежуточными слотами.

Обратная связь

Были ли сведения на этой странице полезными?

Last updated on 2026-04-14

Поделиться через

Руководство. Создание высокодоступного приложения с несколькими регионами в Служба приложений Azure

Предварительные требования

Просмотр архитектуры сценария

Создайте группу ресурсов

Создание двух планов службы приложений

Создание двух приложений

Настройка Azure Front Door

Создание профиля

Добавление конечной точки

Создание группы источников

Добавление источников в группу источников

Добавление правила маршрута

Ограничение доступа только через Azure Front Door

Проверка ограничений доступа

Тестирование развертывания Azure Front Door

Очистка ресурсов

Развертывание из ARM или Bicep

Часто задаваемые вопросы

Управление инфраструктурой и развертыванием ресурсов Azure

Использование тестовых слотов для безопасного развертывания в продуктивной среде

Отключение базовой проверки подлинности в службе приложений

Использование непрерывного развертывания при отключении базовой проверки подлинности

Создание субъекта-службы и учетных данных с помощью GitHub Actions

Создание рабочего процесса GitHub Actions

Тестирование обновлений приложений с использованием маршрутизации трафика между слотами

Перемещение кода из тестового слота в производственный слот

Избегайте сбоев и проблем непрерывности с помощью развертываний с несколькими регионами

Создание дополнительных групп источников и изменение связей маршрутов

Ограничить доступ к сайту продвинутых инструментов

Связанный контент

Обратная связь

Дополнительные ресурсы