Ни для кого сегодня уже не является секретом (или даже новостью) успех технологий контейнеризации в общем и платформы Docker, как успешного практического решения, в частности. Каждый, кто хотя бы раз попробовал упаковать своё приложение в контейнер, испытал это ощущения чисто детского счастья от понимания того, что вот она — упакованная и готовая к работе компонента, которая развернется где-угодно, в каких-угодно количествах и заработает там так же хорошо, как работала на компьютере разработчика. Деплоймент стал удовольствием, а не наказанием. «Гибкость» и «масштабируемость» перестали быть маркетинговой чушью из рекламных буклетов и стали реально достижимыми вещами. Писать микросервисы стало не просто «модно», но попросту логично и практично. Контейнеры навсегда изменили мир. (Была, тут правда, вчера мысль о том, что контейнеры — это зло, но в комментариях вроде бы разобрались, что не в контейнерах конкретно беда, а в общем подходе к безопасности)

Не прошло и 100 лет, как это заметила компания Amazon, выпустив в конце 2014-го в бету свой новый сервис — Amazon EC2 Container Service. Общий смысл сервиса — дать возможность разворачивать Docker-контейнеры удобным способом. «Удобным» — означает без необходимости углубляться во внутренности Docker, да и вообще делать что-либо руками в консоли хост-машины. Вы просто создаёте новый кластер, добавляете в него виртуалки, на которых будут работать контейнеры, а потом указываете сколько и каких контейнеров нужно запустить. Всё остальное (выбор на какой машине запустить контейнер, права доступа, проброс портов) Амазон берёт на себя. Кроме того, вы можете использовать из Docker-контейнера всю инфраструктуру Амазона — сохранять файлы на S3, пользоваться очередями SQS, прикрутить на входе амазоновский балансировщик нагрузки, а на выходе — амазоновские логи и сервисы аналитики. Контейнеры могут «видеть» друг друга, делиться (или не делиться) ресурсами, стартовать и быть остановленными из консоли AWS (вручную либо по заданным правилам).



Давайте попробуем что-нибудь запустить в 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 адрес нашей виртуалки и открыть его в браузере: