Контейнеры на AWS: Docker и ECS

Контейнеры упаковывают приложение и окружение в единый образ, который удобно запускать на Amazon ECS через ECR и Fargate. В статье — понятное объяснение, пример Dockerfile, команды для работы с ECR и практические чек-листы по безопасности, масштабированию и откату.

AWS containers

Быстрые ссылки

Что такое контейнеры и как их использовать?
Упаковка приложения с помощью Docker
Отправка Dockerfile в Amazon ECS (через ECR)

Что такое контейнеры и как их использовать?

Контейнер — это лёгкая виртуализация процессов в Unix-подобной системе, которая изолирует окружение приложения без накладных расходов полноценной виртуальной машины. Проще: контейнер — это образ с кодом, зависимостями и конфигурацией, который запускается одинаково везде.

Краткое определение терминов:

Образ (image): снимок файловой системы и метаданных, из которого запускается контейнер.
Контейнер (container): запущенный экземпляр образа, изолированный по процессам и файловой системе.
Репозиторий образов (ECR): хранилище образов в AWS.
Оркестратор (ECS/Fargate): сервис, который управляет запуском, масштабированием и здоровьем контейнеров.

Почему это удобно:

Консистентность окружений: то, что работает локально, будет работать в продакшне.
Портативность: образ можно перемещать между облаками и машинами.
Быстрый деплой и авто‑масштабирование: контейнеры запускаются и завершаются быстро.

Ограничения и что не стоит держать в контейнере:

Контейнеры по умолчанию ориентированы на stateless‑модели — данные внутри контейнера эпhemerальны.
Хранение персистентных данных (базы данных, файлы) лучше вынести в специальный сервис: RDS, DynamoDB, S3, EFS.
Если вы всё же запускаете долгоживущие stateful‑службы на выделенных EC2, учитывайте резервирование и резервное копирование.

Когда контейнеры не подходят:

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

Установка и подготовка Docker

Для разработки установите Docker Desktop для вашей ОС и убедитесь, что у вас есть доступ к Docker CLI:

docker --version

Создайте директорию проекта и файл с именем Dockerfile без расширения:

touch Dockerfile

Простой Dockerfile начинается с базового образа:

FROM ubuntu

Или используйте более целевые образы (node, python, nginx и т. п.). Ниже — пример Dockerfile для Node.js‑приложения:

# Пример для Node.js
FROM node:18-alpine
WORKDIR /app
COPY package*.json ./
RUN npm install --production
COPY . .
EXPOSE 3000
CMD ["node", "index.js"]

Ключевые команды Dockerfile:

FROM — базовый образ.
COPY — копирование файлов в образ.
RUN — выполнение команд во время сборки образа.
CMD / ENTRYPOINT — команда, которая запускается при старте контейнера.
EXPOSE — объявление порта (информативно).

Если конфигурации слишком много, разбейте её на слои, кешируйте зависимости и используйте multi-stage сборку для уменьшения размера образа.

Паттерны и рекомендации при упаковке

Держите образы небольшими: выбирайте облегчённые базовые образы (alpine, slim).
Не храните секреты в образах: используйте секреты окружения, AWS Secrets Manager или SSM Parameter Store.
Логи отправляйте в stdout/stderr — оркестратор соберёт их и отправит в CloudWatch или другой лог‑агрегатор.
Используйте многоступенчатые сборки для компиляции и минимального runtime.

Подготовка образа к публикации в ECR

Соберите образ локально и проставьте тег в формате репозитория:

docker build -t my-app:latest .

Создайте репозиторий в Amazon ECR через консоль или CLI.
Авторизуйтесь в ECR и отправьте образ. Пример команд (замените и ):

aws ecr get-login-password --region  | docker login --username AWS --password-stdin .dkr.ecr..amazonaws.com

docker tag my-app:latest .dkr.ecr..amazonaws.com/my-app:latest

docker push .dkr.ecr..amazonaws.com/my-app:latest

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

Uploading your image to ECR repository

Советы по тегированию:

Используйте семантические теги или CI‑генерируемые хэши сборки (например, v1.2.3, commit-abcdef).
Для автоматического деплоя используйте метки «latest» только как маркер последней сборки, но не как единственный способ версии.

Развёртывание в Amazon ECS через консоль

Откройте ECS Management Console и начните создание сервиса («Get Started» → выбрать Custom как тип образа).

Customizing image type.

Вставьте полный URI образа:

.dkr.ecr..amazonaws.com/my-app:latest

В разделе Advanced Configuration обязательно рассмотрите включение отправки логов в CloudWatch (Auto‑Configure CloudWatch Logs), настройку переменных окружения и таймаутов.
Выберите движок выполнения: Fargate или EC2.

Fargate — полностью управляемый режим, не требует EC2‑инстансов, удобен для большинства приложений.
EC2 — даёт доступ к виртуальным машинам, если нужен прямой доступ к хосту или специальные драйверы.

Настройте количество задач (tasks), конфигурацию CPU/памяти и опциональный балансировщик нагрузки (Load Balancer).

Defining how many can containers run with optional load balancer.

Включите Auto Scaling для сервиса, если хотите, чтобы количество задач автоматически менялось в зависимости от метрик.
Создайте кластер и сервис. После этого вы сможете увидеть задачи в разделе «Clusters».

Проверка, отладка и мониторинг

Логи: CloudWatch Logs автоматически собирает stdout/stderr при включённой опции.
Метрики: используйте CloudWatch для CPU, памяти, сетевого трафика и кастомных метрик.
Здоровье: настройте проверки здоровья (health checks) в балансировщике нагрузки.
Локальная отладка: запускайте контейнеры локально и подключайте отладчик к порту, проброшенному портом EXPOSE.

Классический рабочий цикл разработки и деплоя:

Изменили код → собрали образ локально
Протестировали локально → прогнали интеграционные тесты
Отправили образ в ECR → обновили сервис в ECS (через консоль/CI)
Мониторим метрики и логи → при проблемах откатываемся на предыдущий тег

Шаблон команд для CI/CD

Пример шага в CI для сборки и пуша в ECR:

# Получаем логин
aws ecr get-login-password --region $AWS_REGION | docker login --username AWS --password-stdin $AWS_ACCOUNT_ID.dkr.ecr.$AWS_REGION.amazonaws.com

# Сборка и пуш
docker build -t $IMAGE_NAME:$COMMIT_SHA .
docker tag $IMAGE_NAME:$COMMIT_SHA $AWS_ACCOUNT_ID.dkr.ecr.$AWS_REGION.amazonaws.com/$REPO_NAME:$COMMIT_SHA
docker push $AWS_ACCOUNT_ID.dkr.ecr.$AWS_REGION.amazonaws.com/$REPO_NAME:$COMMIT_SHA

После пуша CI может вызвать обновление ECS сервиса (через aws ecs update-service или через CD пайплайн).

Безопасность и управление секретами

Рекомендации по безопасности:

IAM-политики: давайте минимально необходимые права для CI/CD систем (push в конкретный репозиторий, чтение секретов).
Секреты: храните пароли/ключи в AWS Secrets Manager или SSM Parameter Store и пробрасывайте как переменные окружения.
Сканирование образов: интегрируйте сканеры уязвимостей (Clair, Trivy) в CI.
Сеть: используйте VPC, приватные подсети и Security Groups для ограничения доступа.

Харднинг и лучшие практики

Используйте non-root пользователя в контейнере, когда это возможно.
Минимизируйте количество слоёв и размер образа.
Обновляйте базовые образы и зависимости регулярно.
Разделяйте права: сервис‑аккаунты и роли для каждой службы.

Откат и инцидент-менеджмент

План отката:

Поддерживайте стабильный тег образа (например, vX.Y.Z) и не перезаписывайте его.
При падении нового релиза быстро переключайтесь на предыдущий тег в конфигурации ECS.
Если требуется срочное выключение, уменьшите desired count до 0 и восстановите после диагностики.

Краткий runbook при проблемах с новой версией:

Симптом: повышенный процент ошибок 5xx или падение health checks.
Шаги:
1. Просмотреть логи CloudWatch для задач с новым тегом.
2. Сравнить конфигурации окружений и переменных.
3. Откатить сервис на предыдущий стабильный тег через update-service.
4. Уведомить команду и начать пост‑mortem.

Частые ошибки и способы их решить

Ошибка авторизации при docker push — убедитесь в корректном aws ecr get-login-password и правах IAM.
Контейнер падает после старта — проверьте CMD/ENTRYPOINT и зависимости (всё ли скопировано в образ).
Высокое потребление CPU/памяти — увеличьте лимиты CPU/Memory в конфигурации задачи или оптимизируйте приложение.

Контейнерные модели хранения и альтернативы

S3 для статического хранения и бэкапов.
RDS/DynamoDB для персистентных баз данных.
EFS для совместного доступа к файловой системе между задачами.

Когда стоит выбрать EC2 вместо Fargate:

Необходим доступ к ядру ОС или к драйверам.
Требуется специализированное аппаратное обеспечение.
Хочется управлять длинноживущими stateful‑инстансами.

Контроль качества и критерии приёмки

Критерии приёмки релиза:

Образ успешно собирается и пушится в ECR.
Сервис в ECS разворачивается и проходит health checks на всех инстансах.
Логи приложения появляются в CloudWatch.
Нагрузочные тесты проходят в пределах SLA.

Шаблон чек‑листа перед деплоем

Собран образ и проставлен тег релиза
Пройшли unit и интеграционные тесты
Обновлён конфиг ECS и проверены переменные окружения
Настроено логирование и мониторинг
Составлен план отката

Краткая памятка по затратам и хранению

Fargate тарификация: оплата за ресурсы CPU/памяти, выделенные задачам.
EC2: вы оплачиваете инстансы, даже когда задачи не загружены.
S3 обычно дешевле EBS/EFS для архивного хранения.

Взвесьте эффект гибкого масштабирования (Fargate) против стоимости постоянных инстансов (EC2) в зависимости от паттернов нагрузки.

1‑строчный глоссарий

Dockerfile — сценарий сборки образа.
Image — готовый образ с приложением.
Task — единица запуска в ECS, основанная на образе.
Service — управление набором задач для обеспечения нужного количества экземпляров.
ECR — Elastic Container Registry (хранилище образов).
Fargate — серверлесс‑режим запуска контейнеров в AWS.

Заключение

Контейнеризация приложения с Docker и развёртывание на AWS ECS даёт повторяемость, удобство CI/CD и масштабируемость. Основные усилия — корректно упаковать приложение, безопасно управлять секретами и выбрать подходящий способ запуска (Fargate или EC2). Следуйте чек‑листам, автоматизируйте сборку/пуш и включайте логирование и мониторинг с самого начала.

Важно

Не храните секреты в образах и ограничивайте права IAM до минимально необходимых.

Полезные ссылки