Azure Container Apps

Azure Container Apps (ACA) — это полностью управляемая бессерверная служба размещения контейнеров, построенная на Kubernetes и KEDA (автоматическое масштабирование Kubernetes на основе событий). В отличие от AKS, Вам не нужно напрямую управлять плоскостью управления, пулами узлов или манифестами Kubernetes. Вместо этого Вы развёртываете контейнеры с помощью простого CLI или определения YAML, а Azure берёт на себя всю оркестрацию. ACA идеально подходит для микрослужб, серверных компонентов API, обработчиков, управляемых событиями, и фоновых заданий обработки, которым требуется динамическое масштабирование, включая масштабирование до нуля.

Среда Container Apps — это изолированная граница, внутри которой выполняется одно или несколько приложений Container Apps. Все приложения в среде используют одну виртуальную сеть и рабочую область Log Analytics. Среды относятся к региону и группе ресурсов. Можно развернуть несколько сред для изоляции команд или этапов (рабочая среда и промежуточная среда). Среду также можно при необходимости внедрить в VNet собственной виртуальной сети, чтобы разрешить закрытое взаимодействие между Container Apps и другими службами Azure без использования общедоступного Интернета.

Чтобы развернуть приложение-контейнер, укажите образ контейнера (из Azure Container Registry или любого общедоступного реестра), количество реплик и переменные среды. Если включить внешний входящий трафик, приложение будет доступно из общедоступной сети по автоматически созданному URL HTTPS. Конфигурация входящего трафика включает целевой порт, распределение трафика для развёртываний «сине-зелёного» типа, а также разрешение только HTTP или только HTTPS. ACA извлекает образ во время развёртывания; среда должна иметь разрешения на извлечение образа из реестра.

Container Apps масштабируется с помощью средств масштабирования KEDA, работающих на основе внешних метрик. Встроенные средства масштабирования KEDA включают: трафик HTTP (параллельные запросы на реплику), глубину очереди Azure Service Bus (ожидающие сообщения), очередь Azure Storage, Cron (на основе времени) и CPU/Memory. Когда значение метрики средства масштабирования становится равным нулю, а для minReplicas установлено значение 0, Container Apps масштабируется до нуля — вычислительные ресурсы не оплачиваются, пока не поступят новые запросы. Масштабирование до нуля отлично подходит для обработчиков, управляемых событиями, с нерегулярной нагрузкой.

Dapr (среда выполнения распределённых приложений) — это переносимая среда выполнения, управляемая событиями, которая упрощает создание микрослужб. Container Apps имеет встроенную интеграцию с Dapr — её можно включить для каждого приложения с помощью одного флага. Dapr предоставляет строительные блоки для: вызова службы (с повторными попытками и mTLS), обмена сообщениями по модели публикации и подписки (абстрагируя Service Bus и Event Hubs), управления состоянием (абстрагируя Redis и Cosmos DB) и исходящих привязок. С Dapr микрослужбы взаимодействуют через побочный процесс Dapr, не зная подробностей базовой инфраструктуры.

Каждое развёртывание приложения Container App создаёт новую редакцию. В режиме нескольких редакций можно распределять трафик между редакциями для «сине-зелёных» или канареечных развёртываний. Например, направить 10% трафика в новую редакцию, а 90% — в текущую стабильную редакцию. Отслеживайте частоту ошибок и задержку новой редакции, прежде чем увеличить долю её трафика до 100%. Старые редакции можно деактивировать, но они сохраняются в журнале, что позволяет мгновенно выполнить откат, вернув прежнюю долю трафика.

Container Apps поддерживает два способа передачи конфигурации: переменные среды (для неконфиденциальных настроек, таких как флаги функций или URL-адреса API) и секреты (для конфиденциальных значений, таких как строки подключения). Секреты хранятся на уровне приложения Container App и используются через переменные среды или компоненты Dapr. Для наиболее безопасной конфигурации ссылайтесь на секреты из Azure Key Vault с помощью управляемой идентификации, чтобы значение секрета извлекалось во время выполнения и никогда не хранилось на уровне конфигурации Container App.

Задания Container Apps расширяют платформу, обеспечивая поддержку рабочих нагрузок с выполнением до завершения — контейнеров, которые запускаются, выполняют работу и завершаются. Задания поддерживают три типа запуска: вручную (через API или CLI), по расписанию (выражение cron) и по событию (масштабировщик KEDA запускает каждое выполнение). Оплата заданий взимается только за фактическое время выполнения, поэтому они идеально подходят для пакетной обработки, создания отчётов, миграции баз данных и конвейеров вывода моделей машинного обучения, которые запускаются периодически или в ответ на события.

Container Apps отправляет системные журналы (события платформы, например создание ревизии и масштабирование) и журналы консоли (вывод stdout/stderr вашего приложения) в рабочую область Log Analytics, подключённую к среде. Запрашивайте журналы с помощью KQL: ContainerAppConsoleLogs_CL | where ContainerAppName_s == 'myapi' | project TimeGenerated, Log_s. Встроенные метрики Azure Monitor включают количество реплик, количество запросов, задержку запросов и загрузку CPU/памяти для каждой реплики — всё это доступно на портале Azure без дополнительной настройки.

Выбор подходящей контейнерной платформы Azure: Container Apps лучше всего подходит для микросервисов, обработчиков событий и API, когда вам нужны преимущества Kubernetes без управления кластером, особенно если важно масштабирование до нуля. AKS лучше всего подходит, когда необходим полный контроль над Kubernetes, пользовательские операторы или особые конфигурации узлов (GPU, большой объём памяти). App Service лучше всего подходит для традиционных веб-приложений и API, когда команда разработчиков предпочитает простую модель PaaS без накладных расходов на управление контейнерами. Все три решения поддерживают контейнеры; различие заключается в соотношении сложности управления и уровня контроля.

Container Apps поддерживает два режима входящего трафика: внешний (доступен из общедоступной сети через конечную точку HTTPS с балансировкой нагрузки и автоматическим TLS) и внутренний (доступен только из той же среды Container Apps или из ресурсов, подключённых через пиринг VNet). Внутренний входящий трафик используется для внутренних служб, которые ни в коем случае не должны быть доступны из интернета. Приложения могут обращаться друг к другу по автоматически созданному внутреннему DNS-имени http://myapi в одной среде, что обеспечивает простой обмен данными между службами без развёртывания шлюза API.

Проверьте своё понимание концепций Microsoft Azure Fundamentals (AZ-900), рассмотренных в этом уроке.

В этом уроке вы узнали, что Azure Container Apps обеспечивает бессерверное размещение контейнеров на базе Kubernetes и KEDA без управления кластером, масштабировщики KEDA позволяют масштабировать до нуля на основе длины очереди, HTTP-трафика или расписаний cron, а интеграция Dapr упрощает взаимодействие между микрослужбами и управление состоянием. Далее мы объединим всё в единый сквозной рабочий процесс разработчика.