Обновление и развертывание изменений в приложениях контейнеров Azure

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

Управление изменениями в Azure Container Apps осуществляется через редакции, которые представляют собой снимок состояния каждой версии контейнерного приложения.

К ключевым характеристикам редакций относятся:

• Неизменяемый: после установки редакция остается неизменной.

• Версионирование: Ревизии служат как запись версий приложения контейнера, фиксируя его состояние на различных этапах.

• Автоматическая подготовка: при первом развертывании приложения-контейнера создается начальная редакция.

• Изменения в пределах области: в то время как редакции остаются неизменными, изменения в пределах области приложения могут повлиять на все редакции, а изменения в пределах области редакции создают новую редакцию.

• Историческая запись. По умолчанию у вас есть доступ к 100 неактивным редакциям, но этот порог можно настроить вручную.

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

Жизненный цикл

Каждая версия проходит определенные состояния, на которые влияют её статус и доступность. В течение жизненного цикла приложение-контейнер проходит разные этапы: настройки, исполнения и неактивности.

Состояние подготовки

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

Состояние	Описание
Подготовка	Редакция находится в процессе проверки.
Подготовлено	Редакция успешно прошла все проверки.
Provisioning failed (Сбой подготовки)	При проверке исправлений возникли проблемы.

Состояние выполнения

После успешной подготовки приложения-контейнера ревизия входит в фазу эксплуатации. Текущий статус помогает отслеживать здоровье и функциональные возможности приложения контейнера.

Состояние	Описание
Подготовка	Ревизия находится в процессе проверки.
Масштабирование до 0	Нет работающих реплик и не подготавливаются новые реплики. Приложение-контейнер может создавать новые реплики, если активируются правила масштабирования.
Активация	Ноль запущенных реплик, одна реплика в процессе подготовки.
Сбой активации	Первая реплика не удалось подготовить.
Масштабирование и обработка	Выполняется масштабирование вовнутрь или наружу. Одна или несколько реплик выполняются, а другие реплики подготавливаются.
Запущено	Выполняется одна или несколько реплик. Сообщать не о чем.
Выполнение (на максимальной мощности)	Выполняется предельное количество реплик (в соответствии с правилами масштабирования ревизии). Сообщать не о чем.
Отключение ресурсов	Редакция переходит от активной к неактивной и удаляет все созданные ресурсы.
Деградация	По крайней мере одна реплика в ревизии находится в состоянии сбоя. Просмотрите сведения о состоянии выполнения для конкретных вопросов.
Неудачно	Критические ошибки привели к сбою исправлений. Состояние выполнения содержит сведения. Наиболее вероятные причины: •Окончание • Код выхода 137

Неактивное состояние

Редакции также могут перейти в неактивное состояние. Эти ревизии не имеют состояния развертывания или выполнения. Однако Azure Container Apps поддерживает список этих ревизий, включая до 100 неактивных записей. Вы можете активировать ревизию в любое время.

Изменить предел неактивных ревизий (предварительный просмотр)

Параметр --max-inactive-revisions можно использовать с командами containerapp create или containerapp update для управления количеством неактивных редакций, отслеживаемых контейнерными приложениями.

Сначала убедитесь, что вы установили расширение "Приложения контейнеров" с включенными функциями предварительной версии для Azure CLI:

az extension add --name containerapp --upgrade --allow-preview true

В этом примере показано, как создать новое приложение контейнера, которое отслеживает 50 неактивных редакций:

az containerapp create --max-inactive-revisions 50

Режимы правок

Приложения контейнеров Azure поддерживают два режима редакции. Выбор режима определяет, сколько версий приложения одновременно активны.

Режимы редактирования	Описание	По умолчанию
Один	Новые редакции автоматически подготавливаются, активируются и масштабируются до требуемого размера. После запуска всех реплик, определенных правилом масштабирования, трафик перенаправляется от старой версии к новой. Если обновление завершается ошибкой, трафик по-прежнему направляется на старую версию. Старые версии автоматически снимаются с обслуживания.	Да
Метки развертывания (предварительная версия)	Назначьте значимые имена (например, dev, staging, prod) определённым версиям контейнера. Используется для разделения трафика и тестирования A/B, автоматического переключения промежуточных версий выпуска и упрощенного отката.	нет
Множественный	Вы можете иметь несколько активных редакций, разделить трафик между редакциями и выбрать, когда следует отменить старые редакции. Этот уровень управления полезен для тестирования нескольких версий приложения, сине-зеленого тестирования или полного управления обновлениями приложений. Дополнительные сведения см. в разделении трафика.	нет

Наклейки

Для приложений-контейнеров с внешним 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 и вы решите использовать суффикс редакции first-revision, полное имя редакции будет album-api-first-revision.

Название суффикса ревизии должно:

• Состоит только из буквенно-цифровых символов или дефисов нижнего регистра (-)
• Начните с алфавитного символа
• Закончить буквенно-цифровым символом

Имена не должны иметь:

• Два последовательных дефиса (--)
• Быть длиннее 64 символов

Суффикс редакции можно задать в шаблоне ARM, с помощью команд az containerapp create и az containerapp update Azure CLI или при создании редакции на портале Azure.

Случаи использования

Ниже приведены распространенные варианты использования редакций в приложениях контейнеров. Этот список не является исчерпывающим списком целей или возможностей использования редакций контейнерных приложений.

Управление выпуском

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

Возврат к предыдущим версиям

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

Тестирование А/Б

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

Сине-зеленые развертывания

Редакции поддерживают стратегию развертывания сине-зеленым цветом. Имея две параллельные версии (синий для текущей версии и зеленый для новой), вы можете постепенно внедрить новую редакцию. После того как вы уверены в стабильности и производительности новой версии, вы можете полностью переключить трафик на зеленую среду.

Следующие шаги

Управление жизненным циклом приложений