Обновление и развертывание изменений в приложениях контейнеров Azure
Управление изменениями может быть сложной задачей при разработке контейнерных приложений в облаке. В конечном счете вам нужна поддержка для отслеживания изменений, обеспечения времени простоя и механизмов для обработки плавного отката.
Управление изменениями в приложениях контейнеров Azure работает с помощью редакций, которые представляют собой моментальный снимок каждой версии приложения контейнера.
К ключевым характеристикам редакций относятся:
Неизменяемый: после установки редакция остается неизменной.
Версия: редакции действуют как запись версий приложения контейнера, захватывая его состояние на различных этапах.
Автоматическая подготовка: при первом развертывании приложения-контейнера создается начальная редакция.
Изменения в области: в то время как редакции остаются статическими, изменения область приложений могут повлиять на все изменения, а изменения область редакции создают новую редакцию.
Историческая запись. По умолчанию у вас есть доступ к 100 неактивным редакциям, но этот порог можно настроить вручную.
Несколько редакций: можно одновременно запускать несколько редакций. Эта функция особенно полезна, если необходимо одновременно управлять различными версиями приложения.
Жизненный цикл
Каждая редакция проходит определенные состояния, на которые влияет его состояние и доступность. В течение жизненного цикла приложение-контейнер выполняет различные операции подготовки, выполнения и неактивного состояния.
Состояние подготовки
При создании новой редакции приложение контейнера проходит запуск и готовность проверка. На этом этапе состояние подготовки служит руководством по отслеживанию хода выполнения приложения контейнера.
| Состояние | Description |
|---|---|
| Подготовка | Редакция находится в процессе проверки. |
| Подготовлено | Редакция успешно прошла все проверка. |
| Provisioning failed (Сбой подготовки) | При проверке исправлений возникли проблемы. |
Состояние выполнения
После успешной подготовки приложения-контейнера редакция переходит на его этап работы. Состояние выполнения помогает отслеживать работоспособность и функциональные возможности приложения контейнера.
| Состояние | Description |
|---|---|
| Подготовка | Редакция находится в процессе проверки. |
| Масштабирование до 0 | Ноль запущенных реплика и не подготавливает новые реплика. Приложение-контейнер может создавать новые реплика, если активируются правила масштабирования. |
| Идет активация | Ноль запущенных реплика, один реплика подготавливается. |
| Сбой активации | Первая реплика не удалось подготовить. |
| Масштабирование и обработка | Выполняется масштабирование в или вне. Выполняется одна или несколько реплика, а другие реплика подготавливаются. |
| Выполняется | Выполняется одна или несколько реплика. Нет проблем с отчетом. |
| Выполнение (максимум) | Выполняется максимальное количество реплика (в соответствии с правилами масштабирования редакции). Нет проблем с отчетом. |
| Отмена подготовки | Редакция переходит от активной к неактивной и удаляет все созданные ресурсы. |
| Деградация | По крайней мере одна реплика в редакции находится в состоянии сбоя. Просмотрите сведения о состоянии выполнения для конкретных проблем. |
| Неудачно | Критические ошибки привели к сбою исправлений. Состояние выполнения содержит сведения. Наиболее вероятные причины: •Прекращения • Код выхода 137 |
Неактивное состояние
Редакции также могут ввести неактивное состояние. Эти редакции не обладают состоянием подготовки или выполнения. Однако приложения контейнеров Azure поддерживают список этих исправлений, а также неактивные записи до 100. Вы можете активировать редакцию в любое время.
Изменение неактивного ограничения редакции
Параметр можно использовать --max-inactive-revisions с containerapp create помощью команд или containerapp update для управления количеством неактивных редакций, отслеживаемых приложениями контейнеров.
В этом примере показано, как создать новое приложение контейнера, которое отслеживает 50 неактивных редакций:
az containerapp create --max-inactive-revisions 50
Режимы редакций
Приложения контейнеров Azure поддерживают два режима редакции. Выбор режима определяет, сколько редакций приложения одновременно активен.
| Режимы редакций | Description | По умолч. |
|---|---|---|
| Одна | Новые редакции автоматически подготавливаются, активируются и масштабируются до требуемого размера. После выполнения всех реплика, определенных правилом масштабирования, трафик отвлечения трафика от старой версии к новой. Если обновление завершается ошибкой, трафик по-прежнему указывает на старую редакцию. Старые редакции автоматически отозваны. | Да |
| Кратность | Вы можете иметь несколько активных редакций, разделить трафик между редакциями и выбрать, когда следует отменить старые редакции. Этот уровень управления полезен для тестирования нескольких версий приложения, сине-зеленого тестирования или полного управления обновлениями приложений. Дополнительные сведения см. в разделении трафика. |
Наклейки
Для приложений-контейнеров с внешним HTTP-трафиком метки направляют трафик к определенным редакциям. Метка предоставляет уникальный URL-адрес, который можно использовать для маршрутизации трафика в редакцию, которой назначена метка.
Чтобы переключить трафик между редакциями, можно переместить метку из одной редакции в другую.
- При перемещении из одной редакции в другую у меток остается один и тот же URL-адрес.
- Метку можно применять только к одной редакции за раз.
- Редакциям с метками не требуется выделение для разделения трафика.
- Метки наиболее полезны, когда приложение находится в режиме нескольких редакций.
- Можно включить метки, разделение трафика или и то, и другое.
Метки полезны для тестирования новых редакций. Например, если вы хотите предоставить доступ группе тестовых пользователей, вы можете предоставить им URL-адрес метки. Затем, когда вы захотите переместить пользователей в другую редакцию, в эту редакцию можно переместить метку.
Метки работают независимо от разделения трафика. При разделении трафик, передаваемый по URL-адресу приложения-контейнера, распределяется в редакции в зависимости от процента трафика. Когда трафик направляется по URL-адресу метки, он передается в одну конкретную редакцию.
Имя метки должно:
- Состоит из буквенно-цифровых символов нижнего регистра или дефисов (
-) - Начните с алфавитного символа
- Конец буквенно-цифровым символом
Метки не должны:
- Иметь два последовательных дефиса (
--) - Быть более 64 символов
Метками можно управлять на странице Управление редакциями для приложения-контейнера на портале Azure.
URL-адрес метки доступен в области сведений о редакции.
Развертывание без простоев
В режиме единой редакции приложения-контейнеры гарантируют, что приложение не будет простоя при создании новой редакции. Существующая активная редакция не деактивируется до тех пор, пока новая редакция не будет готова.
Если входящий трафик включен, существующая редакция продолжает получать 100 % трафика до тех пор, пока новая редакция не будет готова.
Новая редакция считается готовой, когда:
- Исправление успешно подготовлено
- Версия масштабируется до соответствия предыдущим версиям реплика счетчика (учитывая минимальное и максимальное количество реплика новых версий)
- Все реплика прошли свои пробы запуска и готовности
В нескольких режимах редакции можно контролировать, когда изменения активируются или деактивируются и какие редакции получают трафик входящего трафика. Если правило разделения трафика настроено с latestRevision заданным значениемtrue, трафик не переключается на последнюю редакцию до тех пор, пока он не будет готов.
Работа с несколькими редакциями
Хотя один режим редакции является стандартным, иногда может потребоваться полный контроль над управлением редакциями.
Режим нескольких редакций позволяет управлять редакцией вручную. Например, использование нескольких режимов редакции позволяет определить, сколько трафика выделяется для каждой редакции.
Разделение трафика
На следующей схеме показано приложение-контейнер с двумя редакциями.
В этом сценарии предполагается, что приложение-контейнер находится в следующем состоянии:
- Входящий трафик включен, что делает приложение контейнера доступным через ПРОТОКОЛ HTTP или TCP.
- Первая редакция была развернута как Редакция 1.
- После обновления контейнера новая редакция была активирована как Редакция 2.
- Правила разделения трафика настроены таким образом, чтобы Редакция 1 получала 80 % запросов, а Редакция 2 — оставшиеся 20 %.
Прямой доступ к редакции
Вместо использования правила маршрутизации для перенаправления трафика в редакцию может потребоваться сделать редакцию доступной для запросов на определенный URL-адрес. Режим нескольких версий позволяет отправлять все запросы, поступающие в домен, в последнюю версию, а запросы на более старую редакцию доступны через метки для прямого доступа.
Состояние активации
В нескольких режимах редакции можно активировать или деактивировать редакции по мере необходимости. Активные редакции работают и могут обрабатывать запросы, а неактивные редакции остаются неактивными.
Контейнерные приложения не взимает плату за неактивные редакции. Тем не менее, есть ограничение на общее количество доступных редакций, причем самые старые из них очищаются после превышения количества 100.
Типы изменений
Изменения в приложении-контейнере делятся на две категории: изменения области редакции или изменения области приложения. Изменения области редакции активируют новую редакцию при развертывании приложения, а изменения области приложения — нет.
Изменения области редакции
Новая редакция создается при обновлении приложения-контейнера с учетом изменений области редакции. Изменения ограничены редакцией, в которой они развернуты, и не влияют на другие редакции.
Изменение области редакции — это любое изменение параметров в разделе properties.template шаблона ресурса приложения-контейнера.
Это следующие параметры.
- Суффикс редакции
- Конфигурация и образы контейнера
- Правила масштабирования для приложения-контейнера
Изменения области приложения
При развертывании приложения-контейнера с изменениями области приложения:
- Изменения применяются глобально ко всем редакциям.
- Новая редакция не создается.
Изменения области приложения определяются как любые изменения параметров в разделе properties.configuration шаблона ресурса приложения-контейнера.
Это следующие параметры.
- Значения секретов (прежде чем контейнер распознает новые значения секретов, необходимо перезапустить редакции)
- Режим редакции
- Конфигурация входящего трафика, в том числе:
- Включение или отключение входящего трафика
- Правила разделения трафика
- Наклейки
- Учетные данные для частных реестров контейнеров
- Параметры Dapr
Настройка редакций
Вы можете настроить имя и метки редакции, чтобы лучше соответствовать соглашениям об именовании или стратегии управления версиями.
Суффикс имени
Каждая редакция в контейнерных приложениях назначается уникальным идентификатором. Хотя имена создаются автоматически, вы можете персонализировать имя редакции.
Типичный формат имени редакции:
<CONTAINER_APP_NAME>-<REVISION_SUFFIX>
Например, если у вас есть приложение-контейнер с именем album-api и решите о первом суффиксе редакции, полное имя редакции становится альбом-api-first-revision.
Имя суффикса редакции должно:
- Состоит только из буквенно-цифровых символов или дефисов нижнего регистра (
-) - Начните с алфавитного символа
- Конец буквенно-цифровым символом
Имена не должны иметь:
- Два последовательных дефиса (
--) - Быть более 64 символов
Суффикс редакции можно задать в шаблоне ARM, с помощью команд az containerapp create и az containerapp update Azure CLI или при создании редакции на портале Azure.
Случаи использования
Ниже приведены распространенные варианты использования редакций в приложениях контейнеров. Этот список не является исчерпывающим списком целей или возможностей использования редакций контейнерных приложений.
Управление выпуском
Редакции упрощают процесс внедрения новых версий приложения. Когда вы будете готовы развернуть обновление или новую функцию, можно создать новую редакцию, не влияя на текущую динамическую версию. Такой подход обеспечивает плавный переход и сводит к минимуму нарушения для конечных пользователей.
Возврат к предыдущим версиям
Иногда необходимо быстро отменить изменения к предыдущей стабильной версии приложения. При необходимости можно выполнить откат к предыдущей редакции приложения-контейнера.
Тестирование А/Б
Если вы хотите протестировать различные версии приложения, исправления могут поддерживать тестирование A/B. Вы можете направлять подмножество пользователей на новую редакцию, собирать отзывы и принимать обоснованные решения на основе реальных данных.
Сине-зеленые развертывания
Редакции поддерживают стратегию развертывания сине-зеленым цветом. Имея две параллельные редакции (синий для динамической версии и зеленый для новой), вы можете постепенно фазу в новой редакции. После того как вы уверены в стабильности и производительности новой версии, вы можете полностью переключить трафик на зеленую среду.