Amazon DOP-C02: Контейнеры и бессерверные операции — Руководство по подготовке

By Laurynas Brazys · 4 August 2026 · #amazon #dop-c02 #certification #exam-prep #study-guide

Часть AWS DevOps Engineer Professional DOP-C02 — Руководство по подготовке. Практикуйтесь с проверенными ответами в центре экзаменов Amazon, или пройдите тесты на время на ExamRoll.io.

Обзор

Контейнеры и бессерверные вычисления меняют способы эксплуатации, масштабирования и выпуска приложений в AWS. Этот раздел связывает операционные примитивы Amazon ECS, AWS Fargate, Amazon EKS, Amazon ECR, AWS Lambda и Amazon API Gateway, чтобы вы могли проектировать безопасные развертывания, обеспечивать управление образами, настраивать параллелизм и делать последовательный выбор между вычислительными мощностями на базе EC2 и Fargate. Основное внимание уделяется моделям планирования задач и подов, проверкам работоспособности и элементам управления развертыванием, переключению трафика, распространению образов между аккаунтами и функциям производительности, таким как кэширование API и provisioned concurrency в Lambda.

Amazon ECS и AWS Fargate

Определения задач ECS (task definitions) объявляют один или несколько контейнеров и всю конфигурацию времени выполнения, необходимую планировщику. Ключевые элементы включают резервирование и лимиты CPU/памяти, portMappings, переменные окружения и секреты (из AWS Secrets Manager или Systems Manager Parameter Store), параметры и ulimits для Linux, logConfiguration (awslogs, firelens и т.д.), размер ephemeralStorage (для Fargate, 20–200 ГБ) и тома (включая EFS). Используйте роль выполнения задачи (task execution role) для загрузки образов и драйверов логов; используйте роль задачи (task role) для доступа приложения к AWS API. Параметр healthCheck контейнера определяет команду, интервал, таймаут, количество повторных попыток и startPeriod. В сочетании с dependsOn (condition=HEALTHY) проверки работоспособности обеспечивают порядок запуска для сайдкаров.

Сервисы ECS поддерживают желаемое количество задач и опционально регистрируют задачи в ALB/NLB. Параметр deploymentConfiguration сервиса управляет поэтапными обновлениями (rolling updates) с помощью minimumHealthyPercent и maximumPercent. Механизм прерывания развертывания (deployment circuit breaker) (с опциями enabled/rollback) может автоматически откатывать неудачные выкатки, когда задачи не проходят проверки работоспособности. Автомасштабирование сервиса (Service autoscaling) интегрируется с Application Auto Scaling для отслеживания целевых значений на основе CPU/памяти или ALB RequestCountPerTarget. Обнаружение сервисов (Service discovery) через AWS Cloud Map и ECS Service Connect упрощают взаимодействие между сервисами.

Типы кластеров и вычислительные мощности:

Тип запуска EC2 (EC2 launch type) запускает задачи на инстансах EC2, которыми вы управляете самостоятельно. Используйте группы Auto Scaling, ограничения/стратегии размещения (placement constraints/strategies) и любой networkMode (bridge/host/awsvpc). Поддерживаются задачи-демоны (Daemon tasks) и специализированные AMI (например, Bottlerocket).
Тип запуска Fargate (Fargate launch type) — это бессерверные вычисления для контейнеров. Он использует только сетевой режим awsvpc, предоставляя каждой задаче собственный ENI и группу безопасности. Задачи-демоны не поддерживаются; вы полагаетесь на сайдкары или нативные интеграции сервисов (например, FireLens). Версии платформы (Platform versions) определяют доступность функций (проверяйте примечания к выпуску для поддержки EFS, ephemeral storage и exec). Fargate Spot снижает стоимость для прерываемых задач. Выбирайте CPU/память в поддерживаемых парах (например, от 0.25 vCPU/0.5–2 ГБ до 16 vCPU/120 ГБ). При запуске в частных подсетях добавьте интерфейсные эндпоинты VPC для ECR (api и dkr), CloudWatch Logs и шлюзовой эндпоинт S3, чтобы загружать образы и отправлять логи без NAT.

Fargate и EFS: определите том EFS в определении задачи и монтируйте его с использованием TLS; предпочитайте точки доступа EFS (EFS access points) для реализации принципа наименьших привилегий и принудительного применения идентификационных данных. Это обеспечивает поддержку задач с отслеживанием состояния, таких как общие конфигурации, веса моделей или промежуточные файлы, без их встраивания в образы.

Проверки работоспособности контейнеров, поэтапные обновления и сине-зеленые развертывания:

Проверки работоспособности происходят на нескольких уровнях: контейнера (на основе CMD), задачи ECS (агрегированные статусы контейнеров) и целевой группы балансировщика нагрузки (HTTP/TCP). Согласуйте интервалы и пороговые значения, чтобы ECS мог корректно заменять неработоспособные задачи до того, как ALB отменит их регистрацию.
Поэтапные обновления (Rolling updates) являются поведением по умолчанию в ECS. Настраивайте minHealthy/maxPercent для контроля всплеска нагрузки (surge) и обеспечения безопасности емкости.
Сине-зеленое развертывание (Blue/green) использует CodeDeploy с ECS (тип deploymentController —

undefined

). CodeDeploy управляет двумя целевыми группами за ALB, переключает тестовый трафик на «зеленый» набор (AfterAllowTestTraffic), выполняет автоматизированные проверки (например, через Lambda), а затем переключает основной трафик. Привяжите тревоги CloudWatch для отката при всплесках 5XX ошибок, задержек или по пользовательским метрикам. Этот паттерн изолирует сбои и обеспечивает быстрый откат с почти нулевым временем простоя.

Управление образами с помощью ECR:

Сканирование: включите сканирование при загрузке (scan-on-push) и используйте расширенное сканирование Amazon Inspector для непрерывного отслеживания CVE и получения SBOM. Блокируйте развертывания на основе серьезности уязвимостей с помощью проверок в конвейере.
Политики жизненного цикла (Lifecycle policies) удаляют старые теги образов по количеству/возрасту и префиксу тега. Сочетайте с неизменяемостью тегов (tag immutability), чтобы блокировать случайные перезаписи.
Шифрование: используйте шифрование, управляемое ECR, или ключ KMS, управляемый клиентом, с соответствующей политикой ключа.
Межаккаунтный доступ: прикрепите политики ресурсов к репозиторию, чтобы предоставить права на pull/push из других аккаунтов или для ролей CI. Используйте правила репликации ECR для копирования образов между регионами/аккаунтами для локальности и уменьшения радиуса поражения. PrivateLink (эндпоинты VPC) позволяет загружать образы без доступа в интернет.

Модели вычислений в Amazon EKS

EKS разделяет управляемую плоскость управления (control plane) и выбираемую вами плоскость данных (data plane):

Управляемые группы узлов (MNG) отвечают за предоставление и управление жизненным циклом рабочих узлов EC2. Они интегрируются с шаблонами запуска (launch templates) для выбора AMI (Amazon Linux 2, Bottlerocket), типов инстансов и параметров начальной загрузки (bootstrap). MNG управляют поэтапными обновлениями с использованием дополнительной мощности (surge capacity) и автоматической изоляцией/осушением узлов (cordon/drain) для минимизации сбоев. Используйте taints и tolerations узлов для направления на них определенных рабочих нагрузок. Используйте их в сочетании с Cluster Autoscaler (или Karpenter) для оптимизации мощности узлов в зависимости от количества ожидающих подов.

Самоуправляемые узлы дают полный контроль над начальной загрузкой и ОС, но добавляют операционные издержки; обычно их используют для специальных ядер или нишевого оборудования.

EKS on Fargate запускает поды без управления узлами. Профили Fargate сопоставляют пространства имен/метки с Fargate. Каждый под получает собственный ENI (awsvpc), что упрощает сетевую изоляцию. Ограничения включают отсутствие поддержки DaemonSets, сети/томов хоста и ограничения для привилегированных рабочих нагрузок. Агенты наблюдаемости (например, Fluent Bit) должны запускаться как сайдкары или использовать управляемый сбор логов. Эта модель идеально подходит для неравномерных, небольших или многопользовательских (multi-tenant) рабочих нагрузок, которым выгодна изоляция на уровне пода и экономика с оплатой за под.

Операционные дополнения:

VPC CNI, CoreDNS и kube-proxy — это управляемые дополнения; закрепляйте версии, совместимые с версией кластера, и обновляйтесь осознанно.
IAM Roles for Service Accounts (IRSA) обеспечивает доступ к AWS для каждого пода по принципу минимальных привилегий и заменяет совместное использование учетных данных роли узла.
Балансировка нагрузки через AWS Load Balancer Controller поддерживает ALB/NLB для объектов Service и Ingress; убедитесь в правильности правил IAM и групп безопасности, особенно при смешивании MNG и Fargate.
Постоянное хранилище через драйверы CSI (EBS для блочного хранилища на уровне пода, EFS для общего хранилища POSIX). Для Fargate EFS является типичным вариантом для хранения общего состояния.

Операции и параллелизм в AWS Lambda

Упаковка и конфигурация:

Пакеты развертывания могут быть ZIP-архивами (со средой выполнения языка) или образами контейнеров размером до 10 ГБ. ZIP-архивы легче и подходят для небольшого кода; образы унифицируют инструментарий со сборками на основе контейнеров.
Слои инкапсулируют общие библиотеки для нескольких функций; делайте их минимальными и версионируйте. Функция может включать до пяти слоев.
Версии — это неизменяемые снимки (snapshots); псевдонимы (aliases) — это стабильные указатели на версии, которые могут иметь веса для смещения трафика.
Эфемерное хранилище по умолчанию составляет 512 МБ и может быть увеличено до 10 240 МБ для сборок, временных файлов или кэшей ML-выводов. Выбирайте архитектуру x86_64 или arm64 для оптимизации затрат/производительности. Используйте переменные окружения для конфигурации и интегрируйтесь с Secrets Manager или Parameter Store.

Смещение трафика и безопасность:

Используйте CodeDeploy для канареечных/линейных развертываний с автоматическим откатом по тревогам CloudWatch (например, по 5XX ошибкам, задержке или пользовательским метрикам приложения). В качестве альтернативы, устанавливайте веса псевдонимов напрямую для простой A/B-маршрутизации.
Используйте структурированное логирование в CloudWatch Logs и создавайте фильтры метрик для получения метрик с измерениями по операции/версии/коду без изменения инструментария метрик. Включите X-Ray для сквозного отслеживания задержек.

Управление параллелизмом:

Незарезервированный параллелизм использует общий региональный пул аккаунта. Резкие всплески трафика могут привести к нехватке ресурсов для других функций.
Зарезервированный параллелизм ограничивает максимальное количество одновременных выполнений функции и гарантирует для нее эту мощность, выделяя ее из регионального пула; это обеспечивает изоляцию от «шумных соседей».
Подготовленный параллелизм (provisioned concurrency) поддерживает среды выполнения инициализированными для определенной версии/псевдонима, практически устраняя холодные старты и стабилизируя задержку. Масштабируйте подготовленный параллелизм с помощью Application Auto Scaling по расписанию или на основе метрик.
Регулирование (throttling) происходит, когда функция достигает своего лимита параллелизма; синхронные вызовы получают ошибки 429, а асинхронные вызовы повторяются с экспоненциальной выдержкой и могут быть отправлены в очередь недоставленных сообщений (dead-letter queue) после настроенного числа попыток. Для источников на основе опроса, таких как SQS, Lambda увеличивает параллелизм с ростом глубины очереди; убедитесь, что зарезервированный/подготовленный параллелизм и пропускная способность последующих систем соответствуют максимальному количеству сообщений в обработке, чтобы избежать роста очереди.

Проектирование API Gateway и межаккаунтный доступ к ECR

REST API и HTTP API в API Gateway:

REST API предоставляют наиболее богатый набор функций: преобразование запросов/ответов (VTL), планы использования и ключи API, авторизаторы, WAF и кэширование на уровне стадии. Выбирайте REST API, когда вам нужны сложные преобразования, ключи API с квотами или зрелые интеграции с экосистемой.
HTTP API имеют меньшую задержку и стоимость, а также более простую маршрутизацию к бэкендам Lambda и HTTP (включая приватные интеграции с ALB/NLB). Они поддерживают JWT-авторизаторы и IAM, но лишены многих функций REST API, включая кэширование на уровне стадии и преобразования VTL. Выбирайте HTTP API для простого проксирования с минимальными издержками.

Стадии и регулирование (throttling):

Стадии привязывают конкретное развертывание к URL-пути. Настраивайте переменные стадии, журналирование и регулирование на уровне стадии. Применяйте планы использования (REST API) для установки ограничений (throttles) и квот для каждого ключа API. Настройки регулирования включают скорость (rate) и всплеск (burst); они сочетаются с лимитами на уровне аккаунта, поэтому убедитесь, что совокупный трафик не превышает региональные квоты. Включите журналирование доступа в структурированном формате JSON и интегрируйте WAF для проверки и блокировки вредоносных запросов.

Кэширование (только для REST API):

Кэш на уровне стадии снижает нагрузку на бэкенд и задержку; устанавливайте TTL для каждого метода, включайте шифрование и учитывайте параметры/заголовки ключа кэша для корректности. Инвалидируйте кэш после развертываний, которые изменяют структуру или поведение ответов.

Приватное подключение:

Выберите тип эндпоинта: edge-optimized (REST, глобальный через CloudFront), региональный или приватный (VPC endpoints). Приватные интеграции с VPC Link подключаются к бэкендам NLB/ALB в VPC без вывода в публичный доступ.

Межаккаунтный доступ к ECR:

Используйте политики ресурсов репозитория, чтобы предоставить права на pull/push для субъектов (principals) в других аккаунтах (ролей CI/CD или ролей времени выполнения). Если используется управляемый клиентом ключ KMS, соответствующим образом расширьте политику ключа. Для распространения в несколько аккаунтов определите правила репликации ECR, указав целевые аккаунты/регионы, и проверяйте целостность образов с помощью неизменяемости тегов (tag immutability) и фиксации по дайджесту (digest pinning) в развертываниях.

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

Spotify модернизирует стек микросервисов для плейлистов, чтобы уменьшить колебания задержки во время пиковых релизов и усилить контроль над цепочкой поставок образов в нескольких аккаунтах AWS.

Стандартизация сборки и управления образами

Внедрить репозитории ECR со сканированием при отправке (scan-on-push) и расширенным сканированием Amazon Inspector. Добавить неизменяемость тегов (tag immutability) и политики жизненного цикла, чтобы сохранять N последних версий для каждой ветки и удалять устаревшие. Настроить межрегиональную/межаккаунтную репликацию из аккаунта сборки в аккаунты продакшена и стейджинга. Почему: Inspector обеспечивает непрерывное покрытие CVE, неизменяемость тегов предотвращает их перехват, а репликация локализует операции pull, чтобы уменьшить задержку развертывания и радиус поражения (blast radius).

Развертывание stateless API на ECS с Fargate

Определить определения задач (task definitions) ECS с awslogs и FireLens для структурированных логов и метрик. Включить проверки состояния контейнера (healthCheck) и согласовать их с проверками состояния целевой группы ALB. Монтировать том EFS для общей конфигурации только для чтения через точку доступа. Запускать сервисы на Fargate со стратегией поставщика емкости (capacity provider), смешивающей Fargate и Fargate Spot для экономической эффективности. Почему: Fargate устраняет необходимость в управлении узлами и изолирует задачи на уровне ENI; EFS позволяет не встраивать конфигурации в образы и поддерживает атомарные откаты конфигурации.

Безопасные развертывания с blue/green и автоматическими тестами

Переключить сервисы ECS на контроллер развертывания CodeDeploy. Настроить две целевые группы на ALB. Использовать канареечное развертывание (canary shift) с хуком AfterAllowTestTraffic, чтобы вызвать тестовый исполнитель на Lambda, который проверяет критически важные эндпоинты в течение 5 минут. Привязать CloudWatch alarms к 5XX ошибкам и задержке p90 для запуска отката. Почему: Развертывание blue/green в CodeDeploy изолирует риски, тестовый хук проверяет «зеленое» окружение перед полным переключением трафика, а алармы обеспечивают автоматический, объективный откат.

Операции, чувствительные к задержкам, на Lambda со стабилизированными холодными стартами

Для вспомогательного API для токенизации упаковать функцию в ZIP-архив с минимальными зависимостями. Создать версию/алиас и включить provisioned concurrency, рассчитанный на пиковую нагрузку. Управлять provisioned concurrency через Application Auto Scaling с ежедневным расписанием, отслеживающим окна релизов. Использовать канареечное развертывание CodeDeploy (10%/15 минут) для смещения трафика на основе алиаса, привязанное к CloudWatch alarms. Почему: Provisioned concurrency устраняет холодные старты во время всплесков нагрузки; канареечные развертывания на алиасах обеспечивают постепенное внедрение с возможностью быстрого отката.

Предоставление внешних API через API Gateway и защита приватных бэкендов

Разместить API Gateway перед Lambda и ECS ALB. Использовать HTTP API для прокси для Lambda, чтобы минимизировать стоимость/задержку. Использовать REST API для пути к ECS ALB, которому требуется преобразование запросов/ответов и кэширование на уровне стадии для эндпоинтов с высокой нагрузкой на чтение. Применить WAF web ACL и регулирование на уровне стадии; включить структурированные журналы доступа. Почему: Подбор типов API в соответствии с потребностями оптимизирует затраты и возможности; кэширование снижает нагрузку; WAF и регулирование добавляют защиту при всплесках событий.

Межаккаунтные pull-операции во время выполнения без доступа в интернет

В VPC времени выполнения добавить интерфейсные эндпоинты для ECR (api, dkr) и CloudWatch Logs, а также шлюзовой эндпоинт для S3. Прикрепить политики ресурсов репозитория ECR, чтобы разрешить ролям выполнения задач (task execution roles) продакшен-аккаунта выполнять pull-операции. Использовать управляемый клиентом ключ KMS с межаккаунтной политикой ключа для шифрования образов в состоянии покоя. Почему: Приватные pull-операции с образами позволяют избежать затрат на NAT и рисков исходящего трафика; явные политики ресурсов/ключей обеспечивают межаккаунтный доступ по принципу наименьших привилегий.

Эта архитектура снижает операционную нагрузку (нет узлов для управления), обеспечивает детерминированную задержку благодаря provisioned concurrency и развертываниям, согласованным с проверками состояния ALB, и обеспечивает сквозное отслеживание происхождения образов с помощью сканирования, репликации и неизменяемости тегов в ECR.

← Безопасность · Все домены · Высокая доступность →

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