Microsoft AZ-204: Контейнерные решения Azure — Руководство по подготовке

By Laurynas Brazys · 5 August 2026 · #microsoft #az-204 #certification #exam-prep #study-guide

Часть Microsoft Azure Developer Associate AZ-204 — Руководство по подготовке. Практикуйтесь с проверенными ответами в центре экзаменов Microsoft, или пройдите тесты на время на ExamRoll.io.

Обзор

Azure предоставляет спектр вариантов для работы с контейнерами, охватывающий от запуска одиночных контейнеров до оркестрируемых кластеров и безопасной цепочки поставок образов корпоративного уровня. Azure Container Instances (ACI) — это самый быстрый способ запускать контейнеры Linux или Windows без управления серверами. Azure Kubernetes Service (AKS) — это управляемая плоскость управления Kubernetes, которая масштабирует микросервисы с помощью расширенных возможностей планирования, сетевого взаимодействия, безопасности и интеграции с DevOps. Azure Container Registry (ACR) — это частный, геореплицируемый реестр, который лежит в основе ваших процессов сборки, тегирования, отправки/получения (push/pull) и распространения Helm-чартов. Владение навыками создания образов Docker и управления их жизненным циклом является основой для надежных развертываний на любой из этих платформ. В этом разделе представлен практический взгляд с точки зрения разработчика на то, как все компоненты взаимодействуют друг с другом, включая развертывания на основе YAML, упаковку с помощью Helm, предоставление доступа к сервисам и шаблоны идентификации/безопасности.

Docker и Azure Container Registry (ACR)

Надежная доставка контейнеров начинается с прочных основ Docker. Каждый образ состоит из слоев, формируемых инструкциями Dockerfile; повторное использование слоев и попадания в кэш критически важны для быстрой сборки.

• Распространенные инструкции Dockerfile и рекомендации:
  • FROM определяет базовый образ. Предпочитайте минималистичные образы (например, distroless, alpine, когда это уместно), чтобы уменьшить поверхность атаки и размер.
  • RUN выполняет команды для установки зависимостей. Объединяйте связанные команды, чтобы уменьшить количество слоев, но избегайте монолитных строк RUN, которые скрывают ошибки.
  • COPY и ADD размещают артефакты приложения. Используйте .dockerignore, чтобы избежать раздувания контекста сборки; используйте COPY с явным указанием путей.
  • WORKDIR устанавливает рабочий каталог; используйте эту инструкцию вместо последовательных вызовов cd в RUN.
  • EXPOSE документирует предполагаемые порты для прослушивания (это не брандмауэр).
  • ENV и ARG настраивают переменные окружения и переменные времени сборки; обеспечивайте детерминированность сборки, фиксируя значения ARG по умолчанию или передавая явные значения.
  • ENTRYPOINT определяет основной исполняемый файл; используйте CMD для аргументов по умолчанию. Отдавайте предпочтение форме exec (массив JSON) для сохранения обработки сигналов и корректного завершения работы.
  • HEALTHCHECK включает проверку работоспособности (liveness), чтобы оркестраторы могли реагировать.
• Многоэтапные сборки разделяют этапы сборки и выполнения, копируя только необходимые артефакты в чистый образ времени выполнения, что значительно сокращает размер и количество уязвимостей (CVE). Например, можно выполнить сборку с помощью SDK, опубликовать бинарные файлы, а затем скопировать их в базовый образ для выполнения.
• Слои образа неизменяемы и адресуются по содержимому. Изменение порядка инструкций влияет на кэширование. Размещайте часто изменяющиеся инструкции (например, COPY исходного кода) в конце Dockerfile, чтобы максимизировать количество попаданий в кэш.

С помощью ACR можно приватно хранить и распространять образы и Helm-чарты:

• Репозитории и тегирование: Отправляйте образы в формате <registry>.azurecr.io/<repo>:<tag>. Предпочитайте семантические или основанные на Git теги (например, 1.4.0, SHA сборки) и используйте неизменяемые дайджесты в производственных развертываниях для обеспечения повторяемости.
• Отправка и получение (Push/Pull):
  • Аутентифицируйтесь в ACR с помощью az acr login -n <acr-name> или docker login с токеном Azure AD. Избегайте включения пользователя-администратора ACR в производственной среде.
  • Тегирование и отправка: docker tag app:1.0 <acr>.azurecr.io/apps/app:1.0; docker push <acr>.azurecr.io/apps/app:1.0. Получайте образы с помощью docker pull или через ссылки на образы в Kubernetes.
  • Импортируйте образы из внешних реестров в ACR для контроля цепочки поставок: az acr import -n <acr> --source docker.io/library/nginx:1.25 --image base/nginx:1.25.
• ACR Tasks: Собирайте, тестируйте и обновляйте образы нативно в Azure. Используйте az acr build -r <acr> -t apps/app:1.0 . для сборок по требованию; автоматизируйте обновления с помощью az acr task create, чтобы запускать сборку по коммитам в Git или при обновлении базового образа, что позволяет устранять уязвимости (CVE) без изменения кода приложения.
• Георепликация (тариф Premium) обеспечивает локальность получения образов в нескольких регионах и отказоустойчивость. Настраивайте реплики в регионах, близких к кластерам AKS, чтобы уменьшить задержку при скачивании и исходящий трафик между регионами.
• Управление доступом:
  • Интегрируйте с Azure AD и назначайте встроенные роли, такие как AcrPull, удостоверению kubelet в AKS, и AcrPush — конвейерам CI. Разрешения на уровне репозитория доступны через токены и карты областей (scope maps) для гранулярного контроля.
  • Ограничивайте сетевой доступ с помощью приватных конечных точек (private endpoints), конечных точек служб (service endpoints) и правил брандмауэра. Для производственной среды предпочитайте приватные конечные точки.
  • Присоедините ACR к AKS с помощью az aks update --attach-acr <acr>, чтобы упростить назначение роли AcrPull.

Azure Container Instances (ACI)

ACI запускает контейнеры по требованию без управления кластером. Основной единицей является группа контейнеров — совместно планируемый набор контейнеров, использующих одно и то же ядро ОС хоста, жизненный цикл, IP-адрес и тома. Используйте группы контейнеров для реализации шаблона sidecar (например, для сборщиков логов, прокси) или для объединения основного процесса со вспомогательным.

• Группы из нескольких контейнеров используют общее сетевое пространство имен, что позволяет контейнерам взаимодействовать друг с другом через localhost. Они также совместно используют подключенные тома (Azure Files, emptyDir) и жизненный цикл, что делает их подходящими для связанных одноразовых задач, требующих тесной взаимосвязи.
• Политики перезапуска управляют семантикой выполнения:
  • Always перезапускает контейнеры при их завершении. Лучше всего подходит для долгоживущих сервисов.
  • OnFailure перезапускает только при завершении с ненулевым кодом выхода. Подходит для пакетных задач, которые должны повторяться при сбое.
  • Never запускает контейнеры один раз и никогда не перезапускает их, что идеально для идемпотентных заданий.
• Сетевые интеграции включают публичный IP-адрес с DNS-меткой, частные IP-адреса в делегированной подсети Azure VNet и безопасный исходящий трафик через NAT или брандмауэр. ACI, внедренный в VNet, обеспечивает частный доступ к сервисам (базам данных, хранилищам) без их публикации в интернете.
• Эксплуатационные аспекты:
  • Внедряйте секреты с помощью защищенных переменных окружения или монтируйте Azure Files; для более надежной защиты получайте секреты во время выполнения через управляемое удостоверение из Key Vault.
  • Наблюдайте за работой с помощью az container logs и az container attach; выполняйте интерактивные команды с помощью az container exec.
  • Оплата посекундная за vCPU и гигабайты памяти. Контейнеры запускаются быстро и подходят для пиковых нагрузок, вспомогательных задач CI, интеграционных тестов и заданий, запускаемых по событиям в очереди, где издержки Kubernetes нецелесообразны.

Azure Kubernetes Service (AKS)

AKS предоставляет управляемую плоскость управления с пулами узлов, автомасштабированием и расширенными возможностями для работы с сетью и удостоверениями.

Пулы узлов определяют структуру емкости и размещение рабочих нагрузок. Системные пулы узлов (system node pools) запускают основные службы; пользовательские пулы узлов (user node pools) — поды приложений. Используйте несколько пулов для разделения рабочих нагрузок по потребностям в CPU/Memory/GPU, ОС (Linux/Windows), размеру ВМ и зоне доступности. Применяйте механизмы taints/tolerations для защиты системных пулов, метки (labels) для выбора узлов и cluster autoscaler для добавления/удаления узлов в зависимости от ожидающих подов. При определении размеров учитывайте maxPods на узел и плотность подов.

Планирование подов определяется запросами/лимитами ресурсов (requests/limits), классами QoS (Guaranteed/Burstable/BestEffort) и ограничениями. Используйте nodeSelector/affinity и anti-affinity для направления подов в соответствующие пулы и распределения реплик по зонам доступности и доменам сбоя. Ограничения Topology spread constraints улучшают равномерность распределения. Для критически важных служб определяйте PodDisruptionBudgets и PriorityClasses, чтобы управлять добровольными прерываниями и поведением вытеснения. DaemonSets размещают на каждом узле агентов (для логирования, мониторинга), а CronJobs планируют запуск контейнеров для периодических задач.

Развертывания в AKS являются декларативными. YAML-манифесты определяют apiVersion, kind, metadata и spec для Deployments, StatefulSets, Jobs, Services и Ingress. Храните манифесты в системе контроля версий, параметризуйте их с помощью Kustomize overlays для различий между средами и применяйте с помощью kubectl apply -f. Server-side apply и правильные метки/аннотации помогают в определении владельца и обнаружении расхождений. Для упаковки переиспользуемых приложений Helm 3 объединяет шаблоны и значения. Размещайте Helm-чарты как OCI-артефакты в ACR и устанавливайте с помощью helm upgrade --install <release> oci://<acr>.azurecr.io/helm/<chart> -f values.yaml. Используйте файлы values.yaml для каждой среды, отслеживайте версии чартов и выполняйте откат с помощью helm rollback для быстрого восстановления.

Команды kubectl, которые вы будете использовать ежедневно:

• Доступ к контексту кластера: az aks get-credentials -g <rg> -n <cluster> объединяет kubeconfig; использование машины, присоединенной к Azure AD, с kubectl является достаточным — Docker не требуется для развертывания манифестов.
• Проверка и управление: kubectl get nodes,pods,deploy,svc -A; kubectl describe pod <name>; kubectl logs -f <pod>; kubectl exec -it <pod> -- sh; kubectl rollout status deploy/<name>; kubectl set image deploy/<name> container=<image>:<tag>; kubectl top pods; kubectl cordon/drain nodes для обслуживания; kubectl auth can-i для проверки RBAC.
• Применение/обновление: kubectl apply -f k8s/; kubectl patch deploy <name> --type merge -p '{...}'.

Сеть в AKS предоставляет поды и сервисы с четким разделением ответственности:

• ClusterIP предоставляет внутренние, доступные только в кластере виртуальные IP-адреса и DNS для обнаружения сервисов. Это стандартный способ для внутреннего трафика (east-west) между микросервисами.
• NodePort открывает один и тот же порт на каждом узле; его лучше использовать за Ingress или внешним балансировщиком нагрузки, а не напрямую.
• LoadBalancer создает внешний интерфейс Azure Load Balancer, который направляет трафик на NodePort. Помечайте сервисы как внутренние, добавляя аннотацию service.beta.kubernetes.io/azure-load-balancer-internal: "true", или назначайте статический публичный IP для стабильного DNS.
• Ingress controllers обеспечивают маршрутизацию на уровне L7, терминирование TLS и правила на основе пути/хоста. NGINX Ingress Controller — это универсальный вариант по умолчанию с богатым набором аннотаций. Application Gateway Ingress Controller (AGIC) интегрируется с Azure Application Gateway для использования WAF, автомасштабирования и корпоративных возможностей L7, сохраняя при этом нативные манифесты Kubernetes. Используйте cert-manager для автоматизации TLS с помощью ACME или синхронизируйте сертификаты из Key Vault в секреты Kubernetes с помощью CSI Secret Store.

Интеграция удостоверений и авторизации с Azure AD происходит без хранения секретов в кластере:

• Управляемые удостоверения (Managed identities) для AKS состоят из удостоверения кластера/плоскости управления и удостоверения kubelet. Предоставьте kubelet роль AcrPull для ACR (az aks update --attach-acr <acr>), чтобы узлы могли безопасно извлекать образы.
• Workload identity позволяет подам получать доступ к ресурсам Azure, используя федеративные учетные данные Azure AD, сопоставленные с сервисными аккаунтами Kubernetes — без учетных данных на уровне узла или sidecar-контейнеров. Включите OIDC issuer в кластере, создайте управляемое удостоверение, назначаемое пользователем, настройте FederatedIdentityCredential для сервисного аккаунта/пространства имен и используйте Azure Identity SDK в приложении. Этот подход заменяет старую модель AAD Pod Identity и соответствует открытым стандартам.
• RBAC управляет разрешениями Kubernetes API. Привязывайте Kubernetes Roles/ClusterRoles к пользователям или группам Azure AD через RoleBindings/ClusterRoleBindings, когда AKS интегрирован с Azure AD. В качестве альтернативы, включите Azure RBAC for Kubernetes Authorization для управления доступом с помощью ролей Azure RBAC, таких как Azure Kubernetes Service RBAC Reader, Writer и Admin. Следуйте принципу наименьших привилегий, разделяйте пространства имен по командам или рабочим нагрузкам и контролируйте доступ к продакшену через привязки на основе групп.

Полный цикл доставки образа в AKS прост и безопасен. Создавайте многоэтапные образы, тегируйте их неизменяемыми версиями, отправляйте в ACR и развертывайте в AKS с помощью манифестов или Helm. AKS извлекает образы из ACR, используя управляемое удостоверение kubelet, а поды используют ресурсы Azure через workload identity. Сервисы предоставляются через ClusterIP/LoadBalancer и настраиваются с помощью ingress controller, который централизует TLS и маршрутизацию.

Практический сценарий

Команда Adobe Creative Cloud проводит декомпозицию монолитного сервиса обработки медиа на микросервисы, стремясь к низкой задержке при глобальной доставке и усиленной безопасности цепочки поставок ПО.

1. Сборка и хранение образов с использованием многоэтапных Dockerfiles в CI

• Используйте многоэтапную сборку Docker для компиляции медиакодеков и копирования только исполняемых файлов в минимальный базовый образ, уменьшая размер и количество уязвимостей (CVE). Отправляйте образы в ACR как <acr>.azurecr.io/processing/encoder:<git-sha>. Это обеспечивает воспроизводимые, безопасные артефакты с неизменяемыми дайджестами для фиксации версий при развертывании.

2. Усиление безопасности реестра и автоматизация обновлений

• Создайте реестр ACR Premium с приватными эндпоинтами (private endpoints) в каждой виртуальной сети, где размещен AKS. Включите георепликацию в регионы North Europe и East US, чтобы извлечение образов было локальным. Настройте ACR Tasks для запуска пересборки при обновлении вышестоящих базовых образов, автоматически распространяя исправленные слои. Это обеспечивает баланс между производительностью и безопасностью и сокращает исходящий трафик.

3. Развертывание AKS с разделенными пулами узлов и удостоверениями

• Разверните AKS с Azure CNI и системным/пользовательским пулами узлов: небольшой системный пул для дополнений плоскости управления, пользовательские пулы с GPU для транскодирования и пулы общего назначения для API. Включите интеграцию с Azure AD, OIDC issuer и workload identity. Назначьте роль AcrPull удостоверению kubelet с помощью az aks update --attach-acr. Это изолирует рабочие нагрузки, обеспечивает эффективное масштабирование и устраняет необходимость в извлечении образов на основе секретов.

4. Определение декларативных развертываний и упаковки

• Создайте Kubernetes YAML для Deployments, StatefulSets (где требуется персистентность), Services, HorizontalPodAutoscaler и PodDisruptionBudgets. Упакуйте сервис кодирования и API-шлюз как Helm-чарты, опубликуйте их как OCI-артефакты в ACR и разверните с помощью helm upgrade --install, используя файлы values для конкретной среды. Это обеспечивает согласованные, версионированные релизы и простые откаты.

5. Предоставление доступа к сервисам и обеспечение безопасности на уровне L7

• Используйте ClusterIP для внутренних микросервисов и сервис типа LoadBalancer с Application Gateway Ingress Controller для публичных API. Терминируйте TLS на Application Gateway с политикой WAF, управляйте сертификатами с помощью cert-manager, интегрированного с Azure DNS для ACME-проверок, и маршрутизируйте трафик на бэкенды по хосту/пути. Это обеспечивает безопасность корпоративного уровня L7 с нативной конфигурацией Kubernetes.

6. Реализация безопасного доступа рабочих нагрузок к ресурсам Azure

• Для сервиса создания миниатюр, который записывает данные в Blob Storage и читает секреты, создайте управляемое удостоверение, назначаемое пользователем, свяжите его с сервисным аккаунтом через workload identity и предоставьте роли Storage Blob Data Contributor и Key Vault Secrets User. Под аутентифицируется в Azure AD, что устраняет необходимость в монтировании секретов и обеспечивает гранулированный, аудируемый доступ.

7. Обработка пиковых пакетных нагрузок с помощью ACI

• Для спорадических, высокоприоритетных пиковых пакетных нагрузок запускайте мультиконтейнерные группы ACI (кодировщик + sidecar-сборщик метрик) с restartPolicy: Never в подсети с инъекцией VNet. Это поглощает всплески нагрузки без масштабирования AKS до пиковых значений и сохраняет приватные пути данных к учетным записям хранения.

Каждый выбор напрямую поддерживает цели Adobe: ACR Premium с георепликацией и приватными эндпоинтами обеспечивает безопасность и ускоряет извлечение образов; AKS со специализированными пулами узлов и workload identity обеспечивает изоляцию и доступ по принципу наименьших привилегий; Helm и декларативный YAML стандартизируют развертывания и откаты; AGIC с WAF предоставляет отказоустойчивый и безопасный L7-вход; а ACI обрабатывает пиковые пакетные нагрузки без постоянных затрат на кластер.

← Azure Cosmos DB · Все домены · Аутентификация →

Отработать эти вопросы → · Тесты на время на ExamRoll.io →

Просмотреть Microsoft →