Введение в Amazon EC2 Container Service
Ни для кого сегодня уже не является секретом (или даже новостью) успех технологий контейнеризации в общем и платформы Docker, как успешного практического решения, в частности. Каждый, кто хотя бы раз попробовал упаковать своё приложение в контейнер, испытал это ощущения чисто детского счастья от понимания того, что вот она — упакованная и готовая к работе компонента, которая развернется где-угодно, в каких-угодно количествах и заработает там так же хорошо, как работала на компьютере разработчика. Деплоймент стал удовольствием, а не наказанием. «Гибкость» и «масштабируемость» перестали быть маркетинговой чушью из рекламных буклетов и стали реально достижимыми вещами. Писать микросервисы стало не просто «модно», но попросту логично и практично. Контейнеры навсегда изменили мир. (Была, тут правда, вчера мысль о том, что контейнеры — это зло, но в комментариях вроде бы разобрались, что не в контейнерах конкретно беда, а в общем подходе к безопасности)Не прошло и 100 лет, как это заметила компания Amazon, выпустив в конце 2014-го в бету свой новый сервис — Amazon EC2 Container Service. Общий смысл сервиса — дать возможность разворачивать Docker-контейнеры удобным способом. «Удобным» — означает без необходимости углубляться во внутренности Docker, да и вообще делать что-либо руками в консоли хост-машины. Вы просто создаёте новый кластер, добавляете в него виртуалки, на которых будут работать контейнеры, а потом указываете сколько и каких контейнеров нужно запустить. Всё остальное (выбор на какой машине запустить контейнер, права доступа, проброс портов) Амазон берёт на себя. Кроме того, вы можете использовать из Docker-контейнера всю инфраструктуру Амазона — сохранять файлы на S3, пользоваться очередями SQS, прикрутить на входе амазоновский балансировщик нагрузки, а на выходе — амазоновские логи и сервисы аналитики. Контейнеры могут «видеть» друг друга, делиться (или не делиться) ресурсами, стартовать и быть остановленными из консоли AWS (вручную либо по заданным правилам).
[embedded content]
Давайте попробуем что-нибудь запустить в Amazon EC2 Container Service. Например, поднимем Wordpress + Mysql.В принципе, вы можете пойти сюда, нажать кнопку «Get started» и пройти визард, который будет вас вести за ручку сквозь процесс настройки кластера и задач, но лично мне такой подход не нравится — не видишь всей мощи системы и гибкости настроек. Закрываем визард. Открываем вкладку «Кластеры», на которой у нас пока нет ни одного кластера.
Ну что же, давайте создадим один!
И откроем:
Итак, мы видим, что кластер создан и находится в активном состоянии, правда ничего пока в нём не происходит. Ну, это немудрено — мы пока никаких задач ему и не давали. Для того, чтобы всё завертелось, нам нужны рассказать кластеру какие задачи и на каких машинах он должен выполнять.
ECS InstancesЭто EC2-виртуалки, которые вы выделите для работы кластера. Вы можете запустить любое количество любых типов виртуальных машин в одном кластере. Ну ладно, не любое, ограничение — 1000 машин на кластер, вроде должно хватить? Требований к машине только два: там должен быть установлен Docker и там должен быть установлен Amazon ECS Container Agent — такая себе утилита от Амазона для управления кластером. Исходники открыты — github.com/aws/amazon-ecs-agent. Ставится просто:
touch /etc/ecs/ecs.config mkdir -p /var/log/ecs docker run --name ecs-agent -d -v /var/run/docker.sock:/var/run/docker.sock -v /var/log/ecs:/log -p 127.0.0.1:51678:51678 --env-file /etc/ecs/ecs.config -e ECS_LOGFILE=/log/ecs-agent.log amazon/amazon-ecs-agent Но, в общем-то, установка Docker и агента на более-менее стандартный Линукс — задача тривиальная и неинтересная, поэтому Амазон уже сделал образы для виртуалок со всем необходимым, вот они:
Region
AMI Name
AMI ID
us-east-1
amzn-ami-2015.03.b-amazon-ecs-optimized
ami-d0b9acb8
us-west-2
amzn-ami-2015.03.b-amazon-ecs-optimized
ami-6b88b95b
eu-west-1
amzn-ami-2015.03.b-amazon-ecs-optimized
ami-ed7c149a
ap-northeast-1
amzn-ami-2015.03.b-amazon-ecs-optimized
ami-c6c609c6
ap-southeast-2
amzn-ami-2015.03.b-amazon-ecs-optimized
ami-39017e03
Итак, нам нужно запустить как-минимум одну такую виртуалку из панели управления EC2: 
На предыдущем шаге вам, возможно, понадобится создать IAM User, IAM Role и VPC. Что это, зачем и как создаётся можно почитать вот тут.
На следующем шаге убедитесь, что правила безопасности позволят доступ к порту 80 (мы ведь Вордпресс собирались поднимать, вы ещё помните?):
Ждём пару минут, пока наша виртуалка не перейдёт в состояние «Running»: 
Теперь на вкладке нашего кластера мы можем увидеть добавленную в него ноду: 
Если нужно больше машин — самое время их запустить, но нам пока хватит и одной.
Tasks Задачи — это описание того, что собственно будет работать в нашем кластере. Задача включает в себя один или несколько связанных Docker-контейнеров, описание их окружения, их требования к ресурсам, точки монтирования, маппинг портов, параметры запуска и т.д. Вот задача, которая описывает два связанных Docker-контейнера: один для Wordpress и второй для Mysql. { «containerDefinitions»: [ { «name»: «wordpress», «links»: [ «mysql» ], «image»: «wordpress», «essential»: true, «portMappings»: [ { «containerPort»: 80, «hostPort»: 80 } ], «memory»: 300, «cpu»: 10 }, { «environment»: [ { «name»: «MYSQL_ROOT_PASSWORD», «value»: «password» } ], «name»: «mysql», «image»: «mysql», «cpu»: 10, «memory»: 300, «essential»: true } ], «family»: «hello_world» } Давайте коротко опишем что тут где:
name — имя контейнера. Используется для ссылок одного контейнера на другой links — ссылка одного контейнера на другой. Обратите внимание — контейнер Wordpress ссылается на Mysql, это означает, что он сможет открыть порт сервера базы данных без дополнительного порт-маппинга image — ссылка на репозиторий контейнера на Docker Hub. В примере выше мы разворачиваем два образа: registry.hub.docker.com/_/wordpress и registry.hub.docker.com/_/mysql essential — отмечает «критичность» контейнера. Остановка «критического» контейнера может быть поводом для остановки всей задачи (и возможного её перезапуска). Остановка «некритичного» контейнера ни на что не влияет portMappings — проброс портов из контейнера на хост-машину. В примере выше мы открываем наружу 80-ый порт memory, cpu — требования к свободным ресурсам хост-машины. Память считается в мегабайтах, а вот ресурсы процессора — в условных попугаях, которых выделяется 1024 на каждое ядро виртуалки. Т.е. вы сможете запустить две контейнера с cpu=500 на одноядерной машине, но третий уже не запустится environment — переменные окружения, передаются контейнеру В документации больше параметров, часть из них (entryPoint, cmd, mountPoints) взята напрямую из документации Docker.
Давайте добавим задачу, описанную выше: 
Теперь задачу нужно запустить. Сделать это можно на странице нашего кластера, причём двумя способами:
Запустить задачу, как таковую (Cluster-Tasks-Run new task-<выбираем нашу задачу>-Run task) Запустить сервис, состоящий из нашей задачи (Cluster-Services-Create-<выбираем задачу, имя сервиса, количество задач>-Create service) Можно было бы подумать, что разница в том, что сервис позволяет задать запуск нескольких задач, но нет — это можно сделать и в первом способе. Разница в концепции: в первом случае считается, что мы запускаем некоторую «фоновую» задачу, которая должна отработать и умереть. Во втором же случае мы поднимаем некоторый сервис, который должен быть доступен извне продолжительное время, поэтому во-первых для сервиса мы можем сразу включить Elastic Load Balancer, а во-вторых упавшие задачи (и даже рухнувшие виртуалки) сервис будет переподнимать таким образом, чтобы поддерживать количество активных задач на заданном уровне.
Поскольку наш Wordpress — это скорее «сервис» в терминах ECS, то так его и запустим: 
Задача некоторое время повисит в состоянии «Pending» (всё же нужно скачать, собрать и запустить два контейнера) и перейдёт в «Running»:
Всё, можно взять в EC2 адрес нашей виртуалки и открыть его в браузере: 
