Модуль 3.7: ACI та Azure Container Apps

Складність: [COMPLEX] | Час на виконання: 3 год | Передумови: Модуль 3.6 (ACR), Модуль 3.1 (Entra ID)

Чому цей модуль важливий

На початку 2023 року медіа-компанія мала обробляти відео під час прямих трансляцій. Трафік був дуже нерівномірним: нуль завдань вночі та понад 500 одночасних процесів під час ефіру. Їхнє старе рішення на базі 20 постійно ввімкнених ВМ коштувало $2 800 на місяць. Під час піків черга на обробку розтягувалася на 15 хвилин, а вночі машини просто спалювали гроші в порожнечу. Вони перейшли на Azure Container Apps. Тепер система масштабується від 0 до 200 за 90 секунд, коли з’являється робота, і вимикається в нуль після ефіру. Рахунок впав до $340 — економія 88%.

Контейнери стали стандартом де-факто, але не кожному додатку потрібна складність Kubernetes. Azure пропонує два безсерверні варіанти: Azure Container Instances (ACI) — для запуску поодиноких контейнерів, та Azure Container Apps (ACA) — потужну платформу, яка бере на себе масштабування, маршрутизацію та зв’язок між мікросервісами.

У цьому модулі ви навчитеся обирати між ACI та Container Apps, розберетеся з ревізіями та розділенням трафіку, навчитеся налаштовувати автомасшабування KEDA на основі подій (напр. довжини черги) та зрозумієте, як Dapr спрощує життя розробникам мікросервісів.

Azure Container Instances (ACI): Контейнери без серверів

ACI — це найшвидший спосіб запустити контейнер. Вам не потрібен кластер, не потрібні вузли (nodes). Ви просто кажете: “запусти цей образ із 1 ядром CPU”, і Azure робить це миттєво.

Коли використовувати ACI:

Batch jobs: обробка даних, генерація звітів (запустив -> виконав -> видалив).
CI/CD агенти: ефемерні сервери для збірки коду.
Sidecar для AKS: розширення кластера Kubernetes, коли на основних вузлах закінчилося місце.

Azure Container Apps (ACA): Золота середина

ACA побудований на базі Kubernetes, але приховує всю його складність від вас. Це ідеальна платформа для сучасних мікросервісів.

Чому ACA — це круто:

Scale to zero: Якщо ніхто не заходить на ваш сайт, кількість контейнерів падає до нуля. Ви не платите нічого.
Revisions: Кожен деплой створює нову версію. Ви можете направити 10% трафіку на нову версію, щоб перевірити її (Canary).
KEDA: Автоматичне масштабування не за CPU, а за реальними подіями (напр. 1000 повідомлень у черзі = +10 контейнерів).
Dapr: Вбудований інструмент, який сам налаштовує зв’язок між вашими сервісами, ротацію секретів та логування.

Типові помилки

Помилка	Чому це стається	Як виправити
ACI для веб-сайтів	Здається найпростішим	ACI не має вбудованого балансувальника та автомасшабування. Використовуйте Container Apps
min-replicas = 1 завжди	Страх “холодного старту”	Якщо це фоновий воркер, ставте 0. Це зекономить купу грошей
Немає Health Probes	Додаток “завис”, але контейнер живий	Завжди налаштовуйте Liveness та Readiness probes, щоб ACA знав, коли перезавантажити додаток
Паролі в коді	”Для тестів піде”	Використовуйте Secrets у Container Apps, які інтегруються з Key Vault

Тест

1. У чому головна перевага KEDA в Azure Container Apps?

KEDA дозволяє масштабувати додаток на основі зовнішніх подій, а не тільки CPU чи пам’яті. Наприклад, ви можете додати контейнери залежно від кількості листів у черзі або запитів до бази даних.

2. Чи маю я доступ до вузлів (nodes) або Kubernetes API, коли використовую Container Apps?

Ні. Azure Container Apps повністю абстрагує інфраструктуру. Ви керуєте лише додатком, а Microsoft керує кластером Kubernetes під ним. Якщо вам потрібен повний контроль — використовуйте AKS.

Практична вправа: Воркер на ACA

Створіть середовище (Environment) для Container Apps.
Розгорніть додаток, який масштабується до 0.
Налаштуйте правило масштабування (Scale rule) на основі HTTP-запитів: 10 одночасних запитів на один контейнер.
Навантажте додаток і подивіться, як Azure додає нові репліки.

Наступний модуль

Переходьте до Модуля 3.8: Azure Functions та Serverless — ви навчитеся створювати функції, що реагують на події, та опануєте Durable Functions для побудови складних ланцюжків процесів.