Стратегии сине-зеленого развертывания в Azure Spring Apps
Примечание.
Планы "Базовый", "Стандартный" и "Корпоративный" будут устарели начиная с середины марта 2025 г. с 3-летнего периода выхода на пенсию. Рекомендуется перейти в приложения контейнеров Azure. Дополнительные сведения см. в объявлении о выходе на пенсию в Azure Spring Apps.
Стандартный план потребления и выделенного плана будет устарел с 30 сентября 2024 г. с полным завершением работы после шести месяцев. Рекомендуется перейти в приложения контейнеров Azure. Дополнительные сведения см. в статье "Миграция потребления Azure Spring Apps Standard" и выделенного плана в приложения контейнеров Azure.
Эта статья относится к: ✔️ Basic/Standard ✔️ Enterprise
В этой статье описывается поддержка сине-зеленых развертываний в Azure Spring Apps.
Azure Spring Apps (стандартный план и более поздние версии) разрешает два развертывания для каждого приложения, только одно из которых получает рабочий трафик. Этот шаблон часто называется сине-зеленым развертыванием. Поддержка сине-зеленого развертывания в Azure Spring Apps в сочетании с конвейером непрерывной поставки (CD) и тщательное автоматизированное тестирование позволяют гибко развертывать приложения с высоким уровнем уверенности.
Чередование развертываний
Для самой простой реализации сине-зеленого развертывания в Azure Spring Apps следует создать два фиксированных развертывания и всегда использовать для развертывания обновлений то из них, которое не получает рабочий трафик. Задача Azure Spring Apps для Azure Pipelines позволяет легко настроить такой режим развертывания, установив для флага UseStagingDeployment значение true.
Ниже описан практический подход к чередованию развертываний.
Предположим, что приложение имеет два развертывания: deployment1 и deployment2. На данный момент рабочим считается развертывание deployment1, где выполняется версия приложения v3.
Это означает, что развертывание deployment2 является промежуточным. Таким образом, когда конвейер непрерывной поставки (CD) начинает выполнение, он развертывает очередную версию приложения (v4) в промежуточном развертывании deployment2.
Когда v4 начинает работу в развертывании deployment2, здесь можно через частную тестовую конечную точку выполнить все автоматические и ручные тесты, чтобы гарантировать соответствие v4 всем ожиданиям.
Когда вы будете уверены в версии v4, развертывание deployment2 можно перевести в статус рабочего, и теперь оно будет получать весь рабочий трафик. При этом v3 продолжит работу в deployment1 на случай, если вы обнаружите критическую ошибку и потребуется откат.
Развертывание deployment1 становится промежуточным. Поэтому следующий запуск конвейера развертывания выполняет развертывание новой версии в развертывании deployment1.
Теперь вы можете протестировать V5 на частной тестовой конечной точке в развертывании deployment1.
И теперь, когда версия v5 соответствует всем ожиданиям, вы снова присваиваете развертыванию deployment1 статус рабочего, чтобы v5 получало весь рабочий трафик.
Компромиссы, связанные со стратегией чередования развертываний
Метод чередования развертываний применяется очень просто и быстро, так как не требует создания новых развертываний. Но он имеет несколько недостатков, которые мы описали в следующих разделах.
Постоянное промежуточное развертывание
Промежуточное развертывание всегда работает, а значит потребляет ресурсы экземпляра Azure Spring Apps. Это по сути удваивает требования к ресурсам для каждого приложения в Azure Spring Apps.
Состояние гонки при утверждении
Предположим, что в приведенном выше примере в конвейере выпуска требуется утверждение вручную перед переключением рабочего трафика на новую версию приложения. Это создает риск того, что конвейер развертывания снова запустится и перезапишет новую версию (v7), пока предыдущая версия (v6) ожидает утверждения вручную в промежуточном развертывании. Затем, когда будет предоставлено утверждение для v6, конвейер развертывания v6 переведет это промежуточное развертывание в статус рабочего. Но к этому моменту здесь развернута непроверенная версия v7, а не утвержденная v6, и именно она будет получать рабочий трафик.
Чтобы предотвратить состояние гонки, нужно гарантировать, что поток развертывания для новой версии не сможет начаться, пока не будет завершен или прерван поток развертывания для всех предыдущих версий. Другой способ предотвратить состояние гонки при утверждении — использовать метод именованных развертываний, который описан ниже.
Именованные развертывания
При использовании метода именованных развертываний для каждой новой версии развертываемого приложения создается новое развертывание. Когда в этом развертывании завершится тестирование приложения, оно будет назначено рабочим развертыванием. При этом развертывание с предыдущей версией можно сохранять только до тех пор, пока не исчезнет вероятность отката.
На рисунке ниже версия v5 выполняется в развертывании deployment-v5. В этом методе имя развертывания содержит номер версии, так как оно создается специально для этой версии. Других развертываний пока нет. Теперь, чтобы развернуть версию v6, конвейер развертывания создает новое развертывание deployment-v6 и развертывает в нем версию приложения v6.
Так мы избавляемся от риска параллельного развертывания другой версии. Во-первых, Azure Spring Apps не допускает создания третьего развертывания, пока существуют два предыдущих. Во-вторых, даже если будет создано более двух развертываний, каждое из них сопоставлено с определенной версией приложения, которую оно содержит. Таким образом, при оркестрации развертывания v6 конвейер будет пытаться установить в качестве рабочего развертывания только deployment-v6.
После того как созданное для новой версии развертывание получит рабочий трафик, необходимо удалить развертывание с предыдущей версией, чтобы освободить место для будущих развертываний. Вы можете отложить этот процесс на несколько минут или часов, чтобы сохранить возможность отката к предыдущей версии, если вы обнаружите в новой версии критическую ошибку.
Компромиссы, связанные с методом именованных развертываний
Метод именованных развертываний имеет следующие преимущества:
- предотвращается состояние гонки при утверждении;
- снижается потребление ресурсов благодаря удалению промежуточного развертывания, когда оно не используется.
Но существуют и недостатки, которые описаны в следующем разделе.
Сбои конвейера развертывания
Между началом развертывания и удалением промежуточного развертывания любые попытки снова запустить конвейер развертывания завершатся ошибкой. Конвейер попытается создать новое развертывание, что завершится ошибкой, так как для каждого приложения в Azure Spring Apps разрешено только два развертывания.
Таким образом, оркестрации развертывания должна иметь возможность повторно выполнять неудачное развертывание либо гарантировать, что потоки развертывания для каждой версии будут оставаться в очереди до завершения рабочего процесса для всех предыдущих версий.