Руководство. Создание высокодоступного приложения с несколькими регионами в службе приложение Azure
Высокий уровень доступности и отказоустойчивость являются ключевыми компонентами хорошо спроектированного решения. Лучше всего подготовиться к неожиданному, имея план экстренного реагирования, который может сократить время простоя и сохранить системы в состоянии автоматического запуска, когда что-то завершается сбоем.
При развертывании приложения в облаке вы выбираете регион в этом облаке, где основана инфраструктура приложений. Если приложение развертывается в одном регионе и регион становится недоступным, приложение также будет недоступно. Это отсутствие доступности может быть неприемлемым в соответствии с условиями соглашения об уровне обслуживания вашего приложения. В этом случае развертывание приложения и его служб в нескольких регионах является хорошим решением.
В этом руководстве описано, как развернуть веб-приложение с высоким уровнем доступности в нескольких регионах. Этот сценарий прост, ограничив компоненты приложения только веб-приложением и Azure Front Door, но основные понятия можно расширить и применить к другим шаблонам инфраструктуры. Например, если приложение подключается к предложению базы данных Azure или учетной записи хранения, ознакомьтесь с активным гео-реплика tion для баз данных SQL и вариантами избыточности учетных записей хранения. Эталонная архитектура для более подробного сценария см. в разделе "Высокодоступное веб-приложение с несколькими регионами".
На следующей схеме архитектуры показана инфраструктура, созданная в этом руководстве. Он состоит из двух идентичных Служба приложений в отдельных регионах, один из которых является активным или основным регионом, а другой — резервным или вторичным регионом. Azure Front Door используется для маршрутизации трафика в Служба приложений и ограничений доступа, чтобы прямой доступ к приложениям из Интернета был заблокирован. Точка в строке указывает, что трафик отправляется в резервный регион, только если активный регион исчезает.
Azure предоставляет различные варианты балансировки нагрузки и маршрутизации трафика. Azure Front Door был выбран для этого варианта использования, так как он включает веб-приложения, подключенные к Интернету, размещенные в службе приложение Azure, развернутой в нескольких регионах. Чтобы решить, что следует использовать для вашего варианта использования, если оно отличается от этого руководства, см . дерево принятия решений для балансировки нагрузки в Azure.
С этой архитектурой:
- Идентичные Служба приложений приложения развертываются в двух отдельных регионах.
- Общедоступный трафик непосредственно к приложениям Служба приложений блокируется.
- Azure Front Door использует трафик маршрутизации в основной или активный регион. В дополнительном регионе есть Служба приложений, которая работает и готова обслуживать трафик при необходимости.
Из этого руководства вы узнаете, как выполнять такие задачи:
- Создайте идентичные Служба приложений в отдельных регионах.
- Создайте Azure Front Door с ограничениями доступа, которые блокируют общедоступный доступ к Служба приложений.
Необходимые компоненты
Если у вас еще нет подписки Azure, создайте бесплатную учетную запись Azure, прежде чем начинать работу.
Для работы с этим руководством:
Используйте среду Bash в Azure Cloud Shell. Дополнительные сведения см . в кратком руководстве по Bash в Azure Cloud Shell.
Если вы предпочитаете выполнять справочные команды CLI локально, установите Azure CLI. Если вы работаете в Windows или macOS, Azure CLI можно запустить в контейнере Docker. Дополнительные сведения см. в статье Как запустить Azure CLI в контейнере Docker.
Если вы используете локальную установку, выполните вход в Azure CLI с помощью команды az login. Чтобы выполнить аутентификацию, следуйте инструкциям в окне терминала. Сведения о других возможностях, доступных при входе, см. в статье Вход с помощью Azure CLI.
Установите расширение Azure CLI при первом использовании, когда появится соответствующий запрос. Дополнительные сведения о расширениях см. в статье Использование расширений с Azure CLI.
Выполните команду az version, чтобы узнать установленную версию и зависимые библиотеки. Чтобы обновиться до последней версии, выполните команду az upgrade.
Создание двух экземпляров веб-приложения
Для работы с этим руководством вам потребуется два экземпляра веб-приложения, выполняющегося в разных регионах Azure. Вы используете пару регионов "Восточная часть США/ Западная часть США" в качестве двух регионов и создаете два пустых веб-приложения. При необходимости вы можете выбрать собственные регионы.
Чтобы упростить управление и очистку, используйте одну группу ресурсов для всех ресурсов в этом руководстве. Рассмотрите возможность использования отдельных групп ресурсов для каждого региона или ресурса для дальнейшего изоляции ресурсов в ситуации аварийного восстановления.
Выполните следующую команду, чтобы создать группу ресурсов.
az group create --name myresourcegroup --location eastus
Создание планов службы приложений
Выполните следующие команды, чтобы создать планы Служба приложений. Замените заполнители двумя уникальными именами <app-service-plan-east-us> <app-service-plan-west-us> , в которых можно легко определить регион, в котором они есть.
az appservice plan create --name <app-service-plan-east-us> --resource-group myresourcegroup --is-linux --location eastus
az appservice plan create --name <app-service-plan-west-us> --resource-group myresourcegroup --is-linux --location westus
Создание веб-приложений
После создания планов Служба приложений выполните следующие команды, чтобы создать веб-приложения. Замените заполнители для двух глобальных уникальных имен (допустимых символов <web-app-east-us> <web-app-west-us> 0-9a-zи-) и обязательно обратите внимание на --plan параметр, чтобы поместить одно приложение в каждый план (и, следовательно, в каждом регионе). Замените <runtime> параметр языковой версией приложения. Запустите az webapp list-runtimes список доступных сред выполнения. Если вы планируете использовать пример приложения Node.js, приведенного в этом руководстве в следующих разделах, используйте NODE:18-lts в качестве среды выполнения.
az webapp create --name <web-app-east-us> --resource-group myresourcegroup --plan <app-service-plan-east-us> --runtime <runtime>
az webapp create --name <web-app-west-us> --resource-group myresourcegroup --plan <app-service-plan-west-us> --runtime <runtime>
Запишите имя узла по умолчанию для каждого веб-приложения, чтобы определить внутренние адреса при развертывании Front Door на следующем шаге. Ее необходимо указать в формате <web-app-name>.azurewebsites.net. Эти имена узлов можно найти, выполнив следующую команду или перейдя на страницу обзора приложения в портал Azure.
az webapp show --name <web-app-name> --resource-group myresourcegroup --query "hostNames"
Создавать Azure Front Door.
Развертывание с несколькими регионами может использовать конфигурацию "активный—активный" или "активный- пассивный". Конфигурация active-active распределяет запросы по нескольким активным регионам. Конфигурация "активный- пассивный" сохраняет выполнение экземпляров в дополнительном регионе, но не отправляет трафик туда, если основной регион не завершается ошибкой. Azure Front Door имеет встроенную функцию, которая позволяет включить эти конфигурации. Дополнительные сведения о разработке приложений для обеспечения высокой доступности и отказоустойчивости см. в статье "Архитектор приложений Azure для обеспечения устойчивости и доступности".
Создание профиля Azure Front Door
Теперь вы создадите Azure Front Door Premium для маршрутизации трафика в приложения.
Выполните команду az afd profile create , чтобы создать профиль Azure Front Door.
Примечание.
Если вы хотите развернуть Azure Front Door Standard вместо premium, замените значение --sku параметра Standard_AzureFrontDoor. Вы не можете развертывать управляемые правила с помощью политики WAF, если выбран уровень "Стандартный". Подробное сравнение ценовых категорий см . в сравнении ценовой категории Azure Front Door.
az afd profile create --profile-name myfrontdoorprofile --resource-group myresourcegroup --sku Premium_AzureFrontDoor
| Параметр | Стоимость | Описание |
|---|---|---|
profile-name |
myfrontdoorprofile |
Имя профиля Azure Front Door, уникальное в группе ресурсов. |
resource-group |
myresourcegroup |
Группа ресурсов, содержащая ресурсы из этого руководства. |
sku |
Premium_AzureFrontDoor |
Ценовая категория профиля Azure Front Door. |
Добавление конечной точки
Запустите az afd endpoint create , чтобы создать конечную точку в профиле. После завершения процесса создания в профиле можно создать несколько конечных точек.
az afd endpoint create --resource-group myresourcegroup --endpoint-name myendpoint --profile-name myfrontdoorprofile --enabled-state Enabled
| Параметр | Стоимость | Описание |
|---|---|---|
endpoint-name |
myendpoint |
Имя конечной точки в профиле, уникальное глобально. |
enabled-state |
Enabled |
Следует ли включить эту конечную точку. |
Создание группы источников
Выполните команду az afd origin-group create , чтобы создать группу источников, содержащую два веб-приложения.
az afd origin-group create --resource-group myresourcegroup --origin-group-name myorigingroup --profile-name myfrontdoorprofile --probe-request-type GET --probe-protocol Http --probe-interval-in-seconds 60 --probe-path / --sample-size 4 --successful-samples-required 3 --additional-latency-in-milliseconds 50
| Параметр | Стоимость | Описание |
|---|---|---|
origin-group-name |
myorigingroup |
Имя исходной группы. |
probe-request-type |
GET |
Тип запроса проверки работоспособности, который выполняется. |
probe-protocol |
Http |
Протокол, используемый для пробы работоспособности. |
probe-interval-in-seconds |
60 |
Число секунд между выполнением проб работоспособности. |
probe-path |
/ |
Путь относительно источника, который используется для определения работоспособности источника. |
sample-size |
4 |
Количество выборок, рассматриваемых при балансировке нагрузки. |
successful-samples-required |
3 |
Количество выборок в течение примера периода, который должен завершиться успешно. |
additional-latency-in-milliseconds |
50 |
Дополнительная задержка в миллисекундах для зондов, чтобы попасть в самый низкий сегмент задержки. |
Добавление источника в группу
Выполните команду az afd origin create , чтобы добавить источник в группу источников. Для параметра замените --host-name заполнитель <web-app-east-us> именем приложения в этом регионе. Обратите внимание, --priority что для параметра задано 1значение , указывающее, что весь трафик отправляется в основное приложение.
az afd origin create --resource-group myresourcegroup --host-name <web-app-east-us>.azurewebsites.net --profile-name myfrontdoorprofile --origin-group-name myorigingroup --origin-name primaryapp --origin-host-header <web-app-east-us>.azurewebsites.net --priority 1 --weight 1000 --enabled-state Enabled --http-port 80 --https-port 443
| Параметр | Стоимость | Описание |
|---|---|---|
host-name |
<web-app-east-us>.azurewebsites.net |
Имя узла основного веб-приложения. |
origin-name |
primaryapp |
Имя источника. |
origin-host-header |
<web-app-east-us>.azurewebsites.net |
Заголовок узла для отправки запросов к этому источнику. Если оставить это пустое, имя узла запроса определяет это значение. Источники Azure CDN, такие как веб-приложения, служба хранилища BLOB-объектов и Облачные службы требуют, чтобы это значение заголовка узла соответствовало имени узла источника по умолчанию. |
priority |
1 |
Задайте для этого параметра значение 1, чтобы направить весь трафик к основному веб-приложению. |
weight |
1000 |
Вес источника в заданной группе источников для балансировки нагрузки. Значение должно находиться в диапазоне от 1 до 1000. |
enabled-state |
Enabled |
Следует ли включить этот источник. |
http-port |
80 |
Порт, используемый для HTTP-запросов к источнику. |
https-port |
443 |
Порт, используемый для HTTPS-запросов к источнику. |
Повторите этот шаг, чтобы добавить второй источник. Обратите внимание на --priority параметр. Для этого источника задано значение 2. Этот параметр приоритета сообщает Azure Front Door направлять весь трафик к основному источнику, если основной не будет отключен. Если для этого источника 1задан приоритет, Azure Front Door обрабатывает оба источника как активный и прямой трафик в обоих регионах. Обязательно замените оба экземпляра заполнителя <web-app-west-us> именем этого веб-приложения.
az afd origin create --resource-group myresourcegroup --host-name <web-app-west-us>.azurewebsites.net --profile-name myfrontdoorprofile --origin-group-name myorigingroup --origin-name secondaryapp --origin-host-header <web-app-west-us>.azurewebsites.net --priority 2 --weight 1000 --enabled-state Enabled --http-port 80 --https-port 443
Добавление маршрута
Запустите az afd route create , чтобы сопоставить конечную точку с группой источника. Этот маршрут перенаправляет запросы от конечной точки в группу источников.
az afd route create --resource-group myresourcegroup --profile-name myfrontdoorprofile --endpoint-name myendpoint --forwarding-protocol MatchRequest --route-name route --https-redirect Enabled --origin-group myorigingroup --supported-protocols Http Https --link-to-default-domain Enabled
| Параметр | Стоимость | Описание |
|---|---|---|
endpoint-name |
myendpoint |
Имя конечной точки. |
| протокол пересылки | MatchRequest | Протокол этот правило используется при переадресации трафика на серверные серверы. |
route-name |
route |
Имя маршрута. |
| https-redirect | Enabled |
Следует ли автоматически перенаправлять HTTP-трафик в трафик HTTPS. |
supported-protocols |
Http Https |
Список поддерживаемых протоколов для этого маршрута. |
link-to-default-domain |
Enabled |
Связан ли этот маршрут с доменом конечной точки по умолчанию. |
Разрешите выполнение этого шага примерно через 15 минут, так как это займет некоторое время, чтобы это изменение распространялось глобально. После этого периода azure Front Door полностью работает.
Ограничение доступа к веб-приложениям экземпляру Azure Front Door
На этом этапе вы по-прежнему можете получить доступ к приложениям напрямую с помощью url-адресов. Чтобы обеспечить доступ к приложениям только через Azure Front Door, вы устанавливаете ограничения доступа для каждого из приложений. Функции Front Door лучше всего работают, когда трафик проходит только через Front Door. Вы должны настроить источники, чтобы заблокировать трафик, который еще не отправляется через Front Door. В противном случае трафик может обойти брандмауэр веб-приложения Front Door, защиту от атак DDoS и другие функции безопасности. Трафик из Azure Front Door в приложения происходит из известного набора диапазонов IP-адресов, определенных в теге AzureFrontDoor.Backend службы. С помощью правила ограничения тегов службы можно ограничить трафик только из Azure Front Door.
Перед настройкой ограничений доступа Служба приложений обратите внимание на идентификатор Front Door, выполнив следующую команду. Этот идентификатор необходим, чтобы убедиться, что трафик поступает только из конкретного экземпляра Front Door. Ограничение доступа дополнительно фильтрует входящие запросы на основе уникального заголовка HTTP, который отправляет Azure Front Door.
az afd profile show --resource-group myresourcegroup --profile-name myfrontdoorprofile --query "frontDoorId"
Выполните следующие команды, чтобы задать ограничения доступа для веб-приложений. Замените заполнитель <front-door-id> результатом предыдущей команды. Замените заполнители для имен приложений.
az webapp config access-restriction add --resource-group myresourcegroup -n <web-app-east-us> --priority 100 --service-tag AzureFrontDoor.Backend --http-header x-azure-fdid=<front-door-id>
az webapp config access-restriction add --resource-group myresourcegroup -n <web-app-west-us> --priority 100 --service-tag AzureFrontDoor.Backend --http-header x-azure-fdid=<front-door-id>
Тестирование Front Door
При создании профиля Azure Front Door уровня "Стандартный" или "Премиум" глобальное развертывание конфигурации требует нескольких минут. После завершения вы сможете получить доступ к созданному интерфейсному узлу.
Выполните команду az afd endpoint show , чтобы получить имя узла конечной точки Front Door.
az afd endpoint show --resource-group myresourcegroup --profile-name myfrontdoorprofile --endpoint-name myendpoint --query "hostName"
В браузере перейдите к имени узла конечной точки, возвращенной предыдущей командой: <myendpoint>-<hash>.z01.azurefd.net Запрос должен автоматически направляться в основное приложение на востоке США.
Чтобы проверить моментальную глобальную отработку отказа:
Откройте браузер и перейдите к имени узла конечной точки:
<myendpoint>-<hash>.z01.azurefd.netОстановите основное приложение, выполнив az webapp stop.
az webapp stop --name <web-app-east-us> --resource-group myresourcegroupОбновите свой браузер. Вы должны увидеть ту же страницу информации, так как трафик теперь направляется в работающее приложение в Западной части США.
Совет
Чтобы завершить отработку отказа, может потребоваться обновить страницу несколько раз.
Теперь остановите дополнительное приложение.
az webapp stop --name <web-app-west-us> --resource-group myresourcegroupОбновите свой браузер. На этот раз вы увидите сообщение об ошибке.
Перезапустите одно из веб-приложений, выполнив команду az webapp start. Обновите браузер и снова увидите приложение.
az webapp start --name <web-app-east-us> --resource-group myresourcegroup
Теперь вы проверили, что вы можете получить доступ к приложениям через Azure Front Door и эти функции отработки отказа, как предполагается. Перезапустите другое приложение, если вы завершите тестирование отработки отказа.
Чтобы проверить ограничения доступа и убедиться, что приложения можно получить только через Azure Front Door, откройте браузер и перейдите к каждому URL-адресу вашего приложения. Чтобы найти URL-адреса, выполните следующие команды:
az webapp show --name <web-app-east-us> --resource-group myresourcegroup --query "hostNames"
az webapp show --name <web-app-west-us> --resource-group myresourcegroup --query "hostNames"
Вы увидите страницу ошибок, указывающую, что приложения недоступны.
Очистка ресурсов
На предыдущем шаге вы создали ресурсы Azure в группе ресурсов. Если эти ресурсы вам не понадобятся в будущем, вы можете удалить группу ресурсов, выполнив приведенную ниже команду в Cloud Shell.
az group delete --name myresourcegroup
Выполнение этой команды может занять несколько минут.
Развертывание из ARM/Bicep
Ресурсы, созданные в этом руководстве, можно развернуть с помощью шаблона ARM/Bicep. Шаблон Bicep веб-приложения с высоким уровнем доступности позволяет создавать безопасное, высокодоступное решение с несколькими регионами с двумя веб-приложениями в разных регионах за Azure Front Door.
Сведения о развертывании шаблонов ARM/Bicep см. в статье "Развертывание ресурсов с помощью Bicep и Azure CLI".
Часто задаваемые вопросы
В этом руководстве вы развернули базовую инфраструктуру, чтобы включить веб-приложение с несколькими регионами. Служба приложений предоставляет функции, которые помогут вам обеспечить выполнение приложений после рекомендаций и рекомендаций по безопасности.
В этом разделе содержатся часто задаваемые вопросы, которые помогут вам защитить приложения и развернуть ресурсы и управлять ими с помощью рекомендаций.
Что такое рекомендуемый метод для управления инфраструктурой приложений и ресурсами Azure и их развертывания?
В этом руководстве вы использовали Azure CLI для развертывания ресурсов инфраструктуры. Рассмотрите возможность настройки механизма непрерывного развертывания для управления инфраструктурой приложений. Так как вы развертываете ресурсы в разных регионах, необходимо независимо управлять этими ресурсами в разных регионах. Чтобы обеспечить одинаковые ресурсы в каждом регионе, инфраструктуру как код (IaC), например шаблоны Azure Resource Manager или Terraform , следует использовать с конвейерами развертывания, такими как Azure Pipelines или GitHub Actions. Таким образом, если это настроено соответствующим образом, любые изменения ресурсов активируют обновления во всех регионах, в которые вы развертываете. Дополнительные сведения см. в статье "Непрерывное развертывание в службе приложение Azure".
Как использовать промежуточные слоты для практики безопасного развертывания в рабочей среде?
Развертывание кода приложения непосредственно в рабочих приложениях и слотах не рекомендуется. Это связано с тем, что вы хотите иметь безопасное место для тестирования приложений и проверки изменений, внесенных перед отправкой в рабочую среду. Используйте сочетание промежуточных слотов и переключения слотов для перемещения кода из среды тестирования в рабочую среду.
Вы уже создали базовую инфраструктуру для этого сценария. Теперь вы создаете слоты развертывания для каждого экземпляра приложения и настраиваете непрерывное развертывание для этих промежуточных слотов с помощью GitHub Actions. Как и при управлении инфраструктурой, настройка непрерывного развертывания для исходного кода приложения также рекомендуется обеспечить синхронизацию изменений в разных регионах. Если вы не настроите непрерывное развертывание, необходимо вручную обновлять каждое приложение в каждом регионе при каждом изменении кода.
Для остальных действий, описанных в этом руководстве, вы должны иметь приложение, готовое к развертыванию в Служба приложений. Если вам нужен пример приложения, можно использовать пример приложения Node.js Hello World. Вилку этого репозитория, чтобы вы имели собственную копию.
Не забудьте задать параметры стека Служба приложений для приложений. Параметры стека относятся к языку или среде выполнения, используемому для приложения. Этот параметр можно настроить с помощью Azure CLI с az webapp config set помощью команды или на портале, выполнив следующие действия. Если вы используете пример Node.js, задайте для параметра стека значение Node 18 LTS.
- Перейдите в приложение и выберите "Конфигурация" в левой части оглавления.
- Выберите вкладку Общие параметры.
- В разделе "Параметры стека" выберите соответствующее значение для приложения.
- Нажмите кнопку "Сохранить", а затем "Продолжить", чтобы подтвердить обновление.
- Повторите эти действия для других приложений.
Выполните следующие команды, чтобы создать промежуточные слоты под названием "этап" для каждого приложения. Замените заполнители <web-app-east-us> именами приложений и <web-app-west-us> их именами.
az webapp deployment slot create --resource-group myresourcegroup --name <web-app-east-us> --slot stage --configuration-source <web-app-east-us>
az webapp deployment slot create --resource-group myresourcegroup --name <web-app-west-us> --slot stage --configuration-source <web-app-west-us>
Чтобы настроить непрерывное развертывание, следует использовать портал Azure. Подробные инструкции по настройке непрерывного развертывания с поставщиками, такими как GitHub Actions, см. в статье "Непрерывное развертывание в службе приложение Azure".
Чтобы настроить непрерывное развертывание с помощью GitHub Actions, выполните следующие действия для каждого промежуточного слота.
В портал Azure перейдите на страницу управления для одного из слотов приложения Служба приложений.
В области слева выберите Центр развертывания. Затем выберите Параметры.
В поле "Источник" выберите "GitHub" в параметрах CI/CD:
При первом развертывании из GitHub выберите Авторизовать и следуйте запросам авторизации. Если требуется выполнить развертывание из другого пользовательского репозитория, выберите Изменить учетную запись.
После авторизации учетной записи Azure с помощью GitHub выберите параметры Организация, Репозиторий и Ветвь, чтобы настроить CI/CD. Если вам не удается найти организацию или репозиторий, возможно, необходимо включить дополнительные разрешения в GitHub. Дополнительные сведения см. в статье Управление доступом к репозиториям организации.
Если вы используете пример приложения Node.js, используйте следующие параметры.
Параметр Значение Организация <your-GitHub-organization>Репозиторий nodejs-docs-hello-world Филиал main
Выберите Сохранить.
Новые фиксации в выбранном репозитории и ветви теперь постоянно развертываются в слоте приложения Служба приложений. Фиксации и развертывания можно отслеживать на вкладке Журналы.
Файл рабочего процесса по умолчанию, использующий профиль публикации для проверки подлинности в Служба приложений, добавляется в репозиторий GitHub. Этот файл можно просмотреть, перейдя в <repo-name>/.github/workflows/ каталог.
Разделы справки отключить базовую проверку подлинности на Служба приложений?
Рассмотрите возможность отключения базовой проверки подлинности, которая ограничивает доступ к конечным точкам FTP и SCM пользователям, которые поддерживаются идентификатором Microsoft Entra. При использовании средства непрерывного развертывания для развертывания исходного кода приложения отключение базовой проверки подлинности требует дополнительных шагов для настройки непрерывного развертывания. Например, нельзя использовать профиль публикации, так как он не использует учетные данные Microsoft Entra. Вместо этого необходимо использовать субъект-службу или openID Подключение.
Чтобы отключить базовую проверку подлинности для Служба приложений, выполните следующие команды для каждого приложения и слота, заменив заполнители и <web-app-east-us> <web-app-west-us> именами приложений. Первый набор команд отключает доступ FTP для рабочих сайтов и промежуточных слотов, а второй набор команд отключает базовый доступ к порту WebDeploy и сайтУ SCM для рабочих сайтов и промежуточных слотов.
az resource update --resource-group myresourcegroup --name ftp --namespace Microsoft.Web --resource-type basicPublishingCredentialsPolicies --parent sites/<web-app-east-us> --set properties.allow=false
az resource update --resource-group myresourcegroup --name ftp --namespace Microsoft.Web --resource-type basicPublishingCredentialsPolicies --parent sites/<web-app-east-us>/slots/stage --set properties.allow=false
az resource update --resource-group myresourcegroup --name ftp --namespace Microsoft.Web --resource-type basicPublishingCredentialsPolicies --parent sites/<web-app-west-us> --set properties.allow=false
az resource update --resource-group myresourcegroup --name ftp --namespace Microsoft.Web --resource-type basicPublishingCredentialsPolicies --parent sites/<web-app-west-us>/slots/stage --set properties.allow=false
az resource update --resource-group myresourcegroup --name scm --namespace Microsoft.Web --resource-type basicPublishingCredentialsPolicies --parent sites/<web-app-east-us> --set properties.allow=false
az resource update --resource-group myresourcegroup --name scm --namespace Microsoft.Web --resource-type basicPublishingCredentialsPolicies --parent sites/<web-app-east-us>/slots/stage --set properties.allow=false
az resource update --resource-group myresourcegroup --name scm --namespace Microsoft.Web --resource-type basicPublishingCredentialsPolicies --parent sites/<web-app-west-us> --set properties.allow=false
az resource update --resource-group myresourcegroup --name scm --namespace Microsoft.Web --resource-type basicPublishingCredentialsPolicies --parent sites/<web-app-west-us>/slots/stage --set properties.allow=false
Дополнительные сведения об отключении базовой проверки подлинности, включая тестирование и мониторинг входов, см. в разделе "Отключение базовой проверки подлинности в Служба приложений развертываниях".
Разделы справки развернуть код с помощью непрерывного развертывания, если я отключил обычную проверку подлинности?
Если вы решили разрешить базовую проверку подлинности в приложениях Служба приложений, можно использовать любой из доступных методов развертывания в Служба приложений, включая использование профиля публикации, настроенного в разделе промежуточных слотов.
Если отключить базовую проверку подлинности для Служба приложений, для проверки подлинности требуется субъект-служба или OpenID Подключение. Если вы используете GitHub Actions в качестве репозитория кода, ознакомьтесь с пошаговым руководством по использованию субъекта-службы или OpenID Подключение для развертывания в Служба приложений с помощью GitHub Actions или выполните действия, описанные в следующем разделе.
Создание субъекта-службы и настройка учетных данных с помощью GitHub Actions
Чтобы настроить непрерывное развертывание с помощью GitHub Actions и субъекта-службы, выполните следующие действия.
Выполните следующую команду, чтобы создать субъект-службу. Замените заполнители именами ваших
<subscription-id>и приложений. Выходные данные — это объект JSON с учетными данными назначения ролей, предоставляющими доступ к приложениям Служба приложений. Скопируйте этот объект JSON для следующего шага. Он включает секрет клиента, который отображается только в настоящее время. Рекомендуется всегда предоставлять минимальные разрешения доступа. Область в этом примере ограничивается только приложениями, а не всей группой ресурсов.az ad sp create-for-rbac --name "myApp" --role contributor --scopes /subscriptions/<subscription-id>/resourceGroups/myresourcegroup/providers/Microsoft.Web/sites/<web-app-east-us> /subscriptions/<subscription-id>/resourceGroups/myresourcegroup/providers/Microsoft.Web/sites/<web-app-west-us> --sdk-authНеобходимо указать учетные данные субъекта-службы в действие azure/login в рамках используемого рабочего процесса GitHub Action. Эти значения могут быть указаны непосредственно в рабочем процессе или храниться в секретах GitHub с указанием ссылок на них в рабочем процессе. Сохранение значений в виде секретов GitHub является более безопасным вариантом.
Откройте репозиторий GitHub и перейдите к Параметры> Security>Secret и переменным Actions>
Выберите новый секрет репозитория и создайте секрет для каждого из следующих значений. Значения можно найти в выходных данных JSON, скопированных ранее.
Имя. Значение AZURE_APP_ID <application/client-id>AZURE_PASSWORD <client-secret>AZURE_TENANT_ID <tenant-id>AZURE_SUBSCRIPTION_ID <subscription-id>
Создание рабочего процесса GitHub Actions
Теперь, когда у вас есть субъект-служба, который может получить доступ к приложениям Служба приложений, измените рабочие процессы по умолчанию, созданные для приложений при настройке непрерывного развертывания. Проверка подлинности должна выполняться с помощью субъекта-службы вместо профиля публикации. Примеры рабочих процессов см. на вкладке "Субъект-служба" в репозитории GitHub. Следующий пример рабочего процесса можно использовать для предоставленного Node.js примера приложения.
Откройте репозиторий GitHub приложения и перейдите в
<repo-name>/.github/workflows/каталог. Вы увидите автоматически созданные рабочие процессы.Для каждого файла рабочего процесса нажмите кнопку "карандаш" в правом верхнем углу, чтобы изменить файл. Замените содержимое следующим текстом, который предполагает, что вы создали секреты GitHub ранее для учетных данных. Обновите заполнитель в
<web-app-name>разделе "env", а затем зафиксируйте его непосредственно в главной ветви. Эта фиксация активирует действие GitHub для повторного выполнения и развертывания кода, на этот раз с помощью субъекта-службы для проверки подлинности.name: Build and deploy Node.js app to Azure Web App on: push: branches: - main workflow_dispatch: env: AZURE_WEBAPP_NAME: <web-app-name> # set this to your application's name NODE_VERSION: '18.x' # set this to the node version to use AZURE_WEBAPP_PACKAGE_PATH: '.' # set this to the path to your web app project, defaults to the repository root AZURE_WEBAPP_SLOT_NAME: stage # set this to your application's slot name jobs: build: runs-on: ubuntu-latest steps: - uses: actions/checkout@v2 - name: Set up Node.js version uses: actions/setup-node@v1 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@v2 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@v2 with: name: node-app - uses: azure/login@v1 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@v2 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
Как маршрутизация трафика слотов позволяет тестировать обновления, которые я делаю в моих приложениях?
Маршрутизация трафика с слотами позволяет направлять предопределенную часть пользовательского трафика к каждому слоту. Изначально 100% трафика направляется на рабочий сайт. Однако у вас есть возможность отправлять 10 % трафика в промежуточный слот. Если вы настраиваете маршрутизацию трафика слотов таким образом, когда пользователи пытаются получить доступ к приложению, 10% из них автоматически направляются в промежуточный слот без изменений в экземпляре Front Door. Дополнительные сведения о переключениях слотов и промежуточных средах в Служба приложений см. в статье "Настройка промежуточных сред в службе приложение Azure".
Разделы справки переместить код из промежуточного слота в рабочий слот?
После завершения тестирования и проверки в промежуточных слотах можно выполнить переключение слотов с промежуточного слота на рабочий сайт. Этот переключение необходимо выполнить для всех экземпляров приложения в каждом регионе. Во время переключения слотов платформа Служба приложений гарантирует, что целевой слот не работает без простоя.
Чтобы выполнить переключение, выполните следующую команду для каждого приложения. Замените заполнитель для <web-app-name>.
az webapp deployment slot swap --resource-group MyResourceGroup -name <web-app-name> --slot stage --target-slot production
Через несколько минут вы можете перейти к конечной точке Front Door, чтобы проверить успешное переключение слотов.
На этом этапе приложения работают и работают, и все изменения, внесенные в исходный код приложения, автоматически активируют обновление для обоих промежуточных слотов. Затем можно повторить процесс переключения слотов, когда вы будете готовы переместить этот код в рабочую среду.
Как еще можно использовать Azure Front Door в развертываниях с несколькими регионами?
Если вы обеспокоены потенциальными нарушениями или проблемами с непрерывностью в регионах, как и в некоторых клиентах, которые видят одну версию приложения, а другие видят другую версию или если вы вносите значительные изменения в ваши приложения, вы можете временно удалить сайт, который проходит смену слотов из группы источников Front Door. Затем весь трафик направляется в другой источник. Перейдите к области группы источников обновления и удалите источник, который проходит изменение. После внесения всех изменений и готовности к работе с трафиком снова можно вернуться в ту же область и выбрать + Добавить источник для чтения источника.
Если вы предпочитаете не удалять и читать источники, можно создать дополнительные группы источников для экземпляра Front Door. Затем можно связать маршрут с группой источников, указывающей на предполагаемый источник. Например, можно создать две новые группы источников, одну для основного региона и одну для дополнительного региона. Когда основной регион проходит изменение, свяжите маршрут с дополнительным регионом и наоборот, когда дополнительный регион проходит изменение. По завершении всех изменений можно связать маршрут с исходной группой источников, содержащей оба региона. Этот метод работает, так как маршрут может быть связан только с одной группой источников одновременно.
Чтобы продемонстрировать работу с несколькими источниками на следующем снимке экрана, существует три группы источников. MyOriginGroup состоит из обоих веб-приложений, а другие две группы источников состоят из веб-приложения в соответствующем регионе. В примере приложение в основном регионе проходит изменение. Перед началом этого изменения маршрут был связан с "MySecondaryRegion", поэтому весь трафик будет отправлен приложению в дополнительном регионе в течение периода изменения. Вы можете обновить маршрут, нажав кнопку "Отменить связь", которая открывает область "Связать маршруты ".
Разделы справки ограничить доступ к сайту расширенных средств?
С помощью службы приложение Azure сайт SCM/advanced tools используется для управления приложениями и развертывания исходного кода приложения. Рассмотрите возможность блокировки сайта SCM/advanced tools, так как этот сайт , скорее всего, не требуется достичь через Front Door. Например, можно настроить ограничения доступа, которые позволяют проводить тестирование и включать непрерывное развертывание из выбранного средства. Если вы используете слоты развертывания, в частности для рабочих слотов, вы можете запретить почти весь доступ к сайту SCM, так как тестирование и проверка выполняются с промежуточными слотами.