Слоты развертывания и переключение

Слоты развертывания — это работающие отдельные среды для веб-приложения App Service, у каждой из которых есть собственное имя узла (например, myapp-staging.azurewebsites.net). Слоты используют один и тот же план App Service и ресурсы со слотом Production, но работают независимо. Они поддерживают сине-зелёные развертывания: Вы проверяете новый выпуск в слоте Staging, а затем переключаете его в Production без простоя. Слоты доступны начиная с уровня Standard.

Добавьте новый слот развертывания для веб-приложения с помощью портала Azure или CLI. Каждый слот получает собственный URL, параметры приложения и строки подключения. В уровне Standard можно создать до 5 слотов, а в уровне Premium — до 20 слотов. Распространённые имена слотов — staging, canary, hotfix и integration; они отражают разные этапы конвейера выпуска.

Перед переключением крайне важно предварительно запустить слот Staging, чтобы новая версия полностью инициализировалась. Экземпляр App Service после холодного запуска медленно обрабатывает первые запросы, пока инициализируется среда выполнения, что неприемлемо в Production. Включите Auto Swap или вручную отправьте HTTP-запросы для предварительного запуска в слот Staging. App Service также поддерживает конфигурацию applicationInitialization, позволяющую определить пути предварительного запуска, которые должны возвращать код 200, прежде чем слот будет признан готовым.

Переключение атомарно меняет местами слоты Staging и Production. Во время переключения App Service сначала направляет трафик к экземплярам Staging с новым кодом, ждёт их инициализации, затем перенаправляет весь трафик Production к новым экземплярам, а прежние экземпляры Production становятся новым слотом Staging. Благодаря этому откат выполняется очень просто — достаточно ещё раз выполнить переключение.

Параметры приложения можно пометить как sticky (относящиеся к конкретному слоту) или не sticky (переключаемые). Не sticky-параметры перемещаются вместе со слотом развертывания при переключении — поэтому строка подключения к базе данных Staging перейдёт вместе с кодом в Production. Sticky-параметры остаются в своём слоте независимо от переключений — Production всегда сохраняет строку подключения к своей базе данных. Пометьте параметры как sticky с помощью флажка «параметр слота развертывания» или CLI.

App Service поддерживает разделение трафика — направление определённого процента трафика Production в слот, не являющийся Production, без полного переключения. Это позволяет выполнять поэтапные выпуски, постепенно изменяя долю трафика с 5% до 10%, а затем до 50% по мере повышения уверенности в новом выпуске и отслеживая частоту ошибок на каждом шаге. Пользователи, попавшие в слот canary, получают сохраняемый файл cookie, который оставляет их в одной и той же версии на время сеанса.

Auto Swap автоматически переключает слот Staging в Production при каждом развертывании в него нового кода. Это особенно удобно для конвейеров CI/CD, в которых каждый успешный выпуск должен сразу становиться доступным пользователям. Auto Swap ждёт, пока HTTP-запросы слота Staging не начнут возвращать код 200, и только после этого завершает переключение. Включите эту возможность для нужного слота на портале или через CLI, но используйте её осторожно: между развертыванием и публикацией в Production нет этапа ручного утверждения.

Соблюдайте следующие рекомендации при работе со слотами развертывания: всегда проверяйте изменения в Staging перед переключением в Production, используйте sticky-параметры, чтобы изолировать подключения Production к базе данных от Staging, запускайте дымовые тесты по URL слота Staging после развертывания, настраивайте пути проверки работоспособности, чтобы App Service не завершал переключение при неисправности новой версии, и добавляйте метки к развертываниям, чтобы отслеживать, какой коммит работает в каждом слоте.

В типичном конвейере CI/CD этап сборки компилирует и тестирует код, этап развертывания отправляет артефакт в слот Staging, на этапе интеграционного тестирования запускаются автоматические тесты для URL Staging, а этап переключения переводит Staging в Production — при необходимости это действие можно защитить ручным утверждением. Этот шаблон изначально поддерживается и в Azure Pipelines, и в GitHub Actions с помощью действия развертывания App Service.

Во время и после переключения слотов отслеживайте ключевые метрики в Azure Monitor, чтобы убедиться в работоспособности новой версии. Следите за скачками ошибок HTTP 5xx, среднего времени ответа и использования CPU/памяти. Настройте оповещения по метрикам, которые срабатывают при превышении частотой ошибок заданного порога, — это даст сигнал быстро выполнить обратное переключение. Интеллектуальное обнаружение в Application Insights может автоматически уведомлять об аномалиях после развертывания.

Слоты развертывания предпочтительнее полностью отдельных приложений App Service для Staging и Production: слоты используют один план (без дополнительных расходов), поддерживают переключение одним нажатием с возможностью отката, позволяют разделять трафик и управляются в рамках одного ресурса App Service. Используйте отдельные приложения только в том случае, если для Staging требуются принципиально другие SKU планов, изоляция или полностью раздельная тарификация.

Проверьте, насколько хорошо Вы усвоили концепции Microsoft Azure Fundamentals (AZ-900) из этого урока.

В этом уроке Вы узнали, что слоты развертывания предоставляют изолированные среды для сине-зелёных развертываний, параметры, сохраняемые за слотом, привязывают конфигурацию конкретной среды (например, URL базы данных) к слоту, а не к коду, а разделение трафика позволяет выполнять поэтапные выпуски, направляя часть трафика Production на новую версию. Далее мы рассмотрим автомасштабирование и пользовательские домены.