Создание кластера AWS ECS и развертывание Nginx

Кратко: пошаговый практический гид по созданию кластера Amazon Elastic Container Service (ECS) на EC2 и развертыванию простого контейнерного приложения Nginx. Показываю, как создать кластер, роль исполнения задач, определение задачи, службу, получить доступ к запущенным контейнерам и удалить тестовый кластер. Подсказки по безопасности, масштабированию и проверке работоспособности.

Важно: руководство ориентировано на тестовый сценарий. Для production-окружения адаптируйте конфигурации сети, безопасности и мониторинга под требования.

О чём эта статья

• Коротко о ECS и моделях запуска (EC2, Fargate)
• Подготовка: аккаунт, IAM, VPC
• Пошаговое создание кластера ECS на EC2
• Создание роли исполнения задач (ecsTaskExecutionRole)
• Определение задачи и контейнера с Nginx
• Создание сервиса и запуск задач
• Доступ к приложению и отладка
• Очистка (удаление кластера)
• Практические советы: безопасность, мониторинг, масштабирование, чек-листы для продакшена

Ключевые термины в одну строку

• ECS Cluster: логическая группа задач и сервисов.
• Task Definition: описание контейнеров и ресурсов для запуска.
• Task: инстанс запускаемого определения задачи.
• Service: поддерживает заданное число задач и обеспечивает обновления/восстановление.

Зачем использовать ECS

ECS — полностью управляемый оркестратор контейнеров от AWS. Поддерживает запуск на EC2 (вы управляете классом EC2-инстансов) и на Fargate (серверлесс, без управления серверами). Подходит, если вы хотите:

• Быстро развернуть контейнеры в AWS без внешних оркестраторов.
• Использовать интеграции с IAM, CloudWatch, ALB и ECR.
• Комбинировать контроль инфраструктуры (EC2) и безсерверные модели (Fargate).

Когда ECS не подходит: если у вас строгие требования к мультиоблакам или вам нужна сложная сетка сервисов — рассмотрите Kubernetes.

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

• EC2: вы платите за инстансы EC2, на которых выполняются задачи.
• Fargate: вы платите за vCPU и память, выделенные задачам, без управления инстансами.

Для оценки стоимости всегда используйте официальный калькулятор AWS и страницу ценообразования.

Предварительные требования

1. AWS аккаунт (создайте, если нет).
2. Базовое понимание IAM (роли и политики).
3. Базовое понимание VPC и сетей.

Если вы новичок, пройдите официальные руководства по IAM и VPC перед настройкой продакшн-кластера.

План действий (коротко)

1. Войти в AWS Management Console.
2. Создать ECS-кластер (EC2 Linux + Networking).
3. Создать роль исполнения задач (ecsTaskExecutionRole).
4. Создать Task Definition и добавить контейнер Nginx.
5. Создать Service, запустить задачи.
6. Получить доступ к приложению через публичные адреса или балансировщик.
7. Удалить тестовый кластер.

Вход в AWS

Перейдите на страницу входа AWS и авторизуйтесь.

После входа откроется консоль управления AWS.

Создание кластера ECS

1. В консоли AWS выберите «Services» → «Containers» → «Elastic Container Service».

2. В панели ECS выберите «Clusters».

3. Если у вас ещё нет кластеров — нажмите «Create Cluster».

4. Выберите шаблон «EC2 Linux + Networking» и нажмите «Next step».

5. Укажите имя кластера, тип EC2-инстанса, модель провизии (On-Demand, Spot) и остальные параметры. EC2-инстансы, которые будут частью кластера, создаются автоматически на этом шаге.

6. Настройте VPC и подсети. Можно создать новую VPC автоматически или выбрать существующую.

7. Укажите теги (опционально) и нажмите «Create».

8. Процесс займет несколько минут. По завершении нажмите «View Cluster».

Совет: для теста используйте минимальный размер группы автоскейлинга и лёгкие инстансы (t3.small/t3.medium). В продакшне рассчитывайте ресурсы по SLI/SLO и нагрузке.

Создание роли исполнения задач (ecsTaskExecutionRole)

Для запуска задач ECS требуется роль, которую задачи будут использовать для доступа к ECR, CloudWatch и другим сервисам.

Перейдите в IAM → Roles → Create role и создайте роль для ECS Task Execution с политикой, дающей права на загрузку образов из ECR и запись логов. Пример минимальной политики (используйте точно в таком виде):

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "ecr:GetAuthorizationToken",
                "ecr:BatchCheckLayerAvailability",
                "ecr:GetDownloadUrlForLayer",
                "ecr:BatchGetImage",
                "logs:CreateLogStream",
                "logs:PutLogEvents"
            ],
            "Resource": "*"
        }
    ]
}

После создания роль будет видна в консоли IAM.

Важно: для продакшена ограничьте Resource и Actions в соответствии с принципом наименьших привилегий.

Создание определения задачи (Task Definition)

Task Definition описывает, какие контейнеры запускать, какие ресурсы выделить и какие настройки сети/логирования применить.

1. В панели ECS выберите «Task Definitions» и нажмите «Create new Task Definition».

2. Выберите тип запуска «EC2» и нажмите «Next».

3. Укажите имя Task Definition и задайте роль (Task Role) — выберите созданную ecsTaskExecutionRole.

4. Прокрутите до секции «Add container» и добавьте контейнер:
   • Имя контейнера: nginx или test-nginx
   • Образ: nginx:latest (или ваш образ в ECR)
   • Порт: 80
   • Память/CPU: укажите лимиты и запросы
   • Логи: настройте awslogs для отправки в CloudWatch

5. Укажите общие ресурсы задачи: Task memory и Task CPU.

6. Нажмите «Create». После создания вы увидите подтверждение.

Совет: в продакшне используйте конкретные теги образов (не latest), настройте readiness и liveness проверки, а также ограничения ресурсов.

Создание службы (Service) и запуск задач

Сервис отвечает за поддержание желаемого числа задач и за обновления.

1. Внутри кластера выберите вкладку «Services» → «Create».

2. Укажите:
   • Launch type: EC2
   • Task Definition: выберите созданную
   • Cluster: ваш кластер
   • Service name: например nginx-service
   • Desired number of tasks: 2 (или другое значение для теста)

3. Оставьте настройки Deployment и Task placement по умолчанию или настройте стратегию распределения.

4. Если у вас есть балансировщик нагрузки (ALB/NLB), привяжите его к сервису, чтобы направлять внешний трафик.

5. Если не собираетесь использовать авто-scaling — оставьте опцию “Do not adjust the service’s desired count”.

6. Просмотрите настройки и нажмите «Create Service».

После создания вы увидите статус сервиса.

Доступ к запущенным задачам и проверка Nginx

1. Вернитесь в кластер и откройте вкладку «Tasks» — вы увидите запущенные задачи (2 экземпляра в нашем примере).

2. Откройте одну задачу и в разделе Network bindings найдите публичный IP и порт (или приватный IP, если VPC без публичного доступа).

3. Скопируйте ссылку (http://:) и откройте в браузере — вы должны увидеть стандартную стартовую страницу Nginx.

Примечание: если вы не использовали балансировщик нагрузки, каждая задача доступна по своему IP:порт. Для стабильного внешнего доступа в production используйте ALB с target group.

Удаление кластера (очистка тестовой среды)

Если кластер больше не нужен, его можно удалить.

1. В панели кластера нажмите «Delete Cluster».
2. Подтвердите действие, введя текст, требуемый интерфейсом (в примере «delete me»), и нажмите «Delete».

Важно: удаление приведёт к уничтожению всех задач, сервисов и EC2-инстансов, связанных с кластером. Убедитесь, что вы сохранили нужные данные.

Практические рекомендации и лучшие практики

• Образы: используйте версии с тегами, а не latest; сканируйте образы на уязвимости.
• Роли и права: применяйте принцип наименьших привилегий к ролям Task Role и Execution Role.
• Логирование: отправляйте логи контейнеров в CloudWatch Logs или в централизованный лог-стек.
• Мониторинг: настройте CloudWatch Alarms по метрикам CPU, памяти, ошибок приложений.
• Сеть: в production обычно используют приватные под-сети для задач и публичные для NAT/ALB; ограничьте входящий трафик через Security Groups.
• Масштабирование: используйте Service Auto Scaling и Target Tracking по метрикам (CPU, запросы на инстанс).

Безопасность и hardening

• Секреты: используйте AWS Secrets Manager или Parameter Store для хранения секретов, не встраивайте их в образы.
• Минимальные права: определяйте узконаправленные IAM-политики для доступа к ECR, S3 и другим ресурсам.
• Обновления: регулярно обновляйте базовые образы и пакеты в контейнерах.
• Сетевые ACL и Security Groups: запрещайте неиспользуемые порты и ограничивайте доступ по IP.

Мониторинг, логирование и SLI/SLO

• Логи контейнеров → CloudWatch Logs
• Метрики задач и инстансов → CloudWatch Metrics
• Настройте SLO по времени отклика и доступности; используйте оповещения при нарушениях.

Отладка: типичные проблемы и решения

1. Задачи не запускаются — проверьте подсказки в Events в разделе Service; проверьте IAM роль и права.
2. Контейнер стартует, но не отвечает — проверьте mapping портов, health check и правила Security Group.
3. Docker image не грузится — проверьте доступ в ECR и настройки авторизации (ecr:GetAuthorizationToken).
4. Нет публичного доступа — проверьте, назначен ли публичный IP задаче/инстансу и правила ALB.

Чек-лист перед переходом в продакшен

• Образы с конкретными тегами и проверкой уязвимостей
• Настроенные политики IAM с принципом наименьших привилегий
• Логи в CloudWatch и retention policy
• ALB с HTTPS, сертификатами ACM
• Мониторинг и алерты в CloudWatch
• Тесты хелсчеков и readiness
• Автоскейлинг настроен и протестирован

Роль‑ориентированные краткие чек-листы

Для SRE/DevOps:

• Автоматизация развёртывания (CI/CD) → ECR push → обновление Task Definition → rolling deploy
• Настройка мониторинга и автоскейлинга

Для разработчика:

• Локально тестировать контейнеры и health endpoints
• Использовать переменные окружения для конфига, не встраивать секреты

Для инженера безопасности:

• Аудит IAM ролей и Security Group
• Настройка сканирования образов и анализа уязвимостей

Playbook развёртывания (микро-SOP)

1. Собрать и протестировать образ локально.
2. Запушить образ в ECR с семантическим тегом.
3. Обновить Task Definition: новый image tag.
4. Выполнить rolling deploy через обновление Service.
5. Мониторить health checks и метрики 10–30 минут после deploy.
6. В случае проблем — откатить image к предыдущему стабильному тегу.

Runbook для инцидента: приложение недоступно

1. Проверить статус Service и Tasks в ECS.
2. Проверить события (Events) сервиса на ошибки.
3. Если задачи находятся в STOPPED — посмотреть exit code и логи контейнера.
4. Проверить доступность EC2-инстансов в кластере и состояние Docker.
5. При необходимости вернуть предыдущую Task Definition и перезапустить сервис.
6. Уведомить команду и оформить постинцидентный отчёт.

Мини‑методология выбора: EC2 vs Fargate

• Если нужен полный контроль над хостами (специальные драйверы, GPU, кастомный AMI) — EC2.
• Если нужен быстрый запуск и меньше операций — Fargate.
• Для гибридных сценариев можно смешивать: часть сервисов на Fargate, часть на EC2.

Критерии приёмки

• Приложение достигает желаемого количества реплик в сервисе без ошибок.
• Health checks проходят стабильно на каждой задаче.
• Логи доставляются в CloudWatch.
• Автотесты функциональности проходят на развернутой версии.

Однострочные определения (глоссарий)

• ECS: управляемый AWS сервис для оркестрации контейнеров.
• Fargate: серверлесс-режим запуска контейнеров в AWS.
• Task: одна единица запуска Task Definition.
• Service: поддерживает и управляет набором задач.

Заключение

Мы прошли полный путь: от создания ECS-кластера на EC2 до развертывания Nginx, проверки доступа и удаления тестового кластера. Руководство подходит для обучения и быстрых тестов. Для production-окружения добавьте более строгие политики безопасности, мониторинг, автоскейлинг и CI/CD-пайплайн.

Важно: не забывайте удалять тестовые ресурсы, чтобы не нести ненужные расходы.

Короткое резюме в одном абзаце: ECS позволяет управлять контейнерными приложениями в AWS либо на EC2-инстансах, либо на безсерверном Fargate. Основные шаги — создать кластер, роль исполнения, Task Definition и Service; затем проверить работоспособность и настроить безопасность и мониторинг.