Docker в 2014: от 1.0 до экосистемы за полгода

В июне вышел Docker 1.0 - первый релиз с заявленной «production ready» стабильностью. Это было примерно полгода назад. За эти полгода вокруг Docker выросло столько всего, что стоит остановиться и собрать картину вместе, потому что иначе она расплывается: слишком много движения одновременно.

Что изменилось в самом Docker

Docker 1.0 - это была точка зрения Docker Inc. на то, что API стабилизировался и можно строить поверх него инфраструктуру без страха, что всё сломается с минорным обновлением. С тех пор вышли 1.1, 1.2, 1.3 и в ноябре - 1.4.

Основная работа шла в трёх направлениях:

• Сеть. Режим --net=host заработал предсказуемо, port mapping стал устойчивее. Overlay-сети через flannel - это пока внешний инструмент, но разговоры о встроенной поддержке идут.
• Безопасность. В 1.3 появился docker exec, что закрыло часть кейсов, где раньше приходилось открывать sshd внутри контейнера. В 1.4 - улучшения в user namespace, хотя полноценного изолированного root там пока нет.
• Производительность. Devicemapper как storage driver стал вести себя лучше, overlay начали рекомендовать на новых ядрах. Время сборки образов заметно улучшилось за счёт более умного кеширования слоёв.

Ни один из этих шагов не революционный. Но в сумме за полгода Docker стал заметно плотнее - меньше сюрпризов при эксплуатации, больше предсказуемости.

Экосистема: три новых инструмента

Если сам Docker эволюционировал постепенно, то вокруг него выросло сразу три инструмента, которые меняют картину работы с контейнерами.

Fig стал Docker Compose. В октябре Docker официально взял Fig под крыло и переименовал в Compose. Мы уже писали про Fig - один YAML-файл для описания многоконтейнерного приложения, docker-compose up вместо трёх docker run с флагами, которые надо помнить. Переход с Fig на Compose у нас занял полчаса - команды те же, формат тот же, только бинарь другой. Все новые проекты сразу получают docker-compose.yml.

Docker Machine. Утилита для создания и управления хостами с Docker. Поддерживает VirtualBox, AWS, DigitalOcean, VMware - создаёт виртуалку, ставит Docker, настраивает TLS-доступ, добавляет DOCKER_HOST в окружение. docker-machine create --driver virtualbox dev - и через минуту у разработчика есть изолированная Docker-машина. Особенно актуально на macOS, где boot2docker со своими quirks начал раздражать. Machine решает задачу аккуратнее и обещает единый интерфейс для локального и облачного хоста.

Swarm. В конце года Docker анонсировал Swarm - инструмент кластеризации, который прячет группу Docker-хостов за единым API. Идея в том, что у вас есть обычный Docker CLI, но DOCKER_HOST указывает на Swarm-endpoint, а тот сам решает, на какой ноде запустить контейнер. Constraint-ы позволяют управлять размещением: «запусти на хосте с SSD», «не запускай рядом с этим контейнером». Swarm пока в статусе preview, и смотреть на него серьёзно рано - но сама идея честная: не городить новый API, а переиспользовать существующий.

Как это всё легло на наши проекты

В dev-окружении контейнеры прижились. Compose стал стандартом для новых сервисов, разработчики перестали спрашивать «как поднять локально», потому что ответ один: docker-compose up. Внутренний Registry работает без нареканий, образы не уходят на Docker Hub.

На staging контейнеры тоже появились, но там история сложнее. Часть проектов запускается через Ansible с явными docker run командами в плейбуках - это работает, но оркестрация рудиментарная. Если сервис надо перезапустить - Ansible идёт на хост и перезапускает. Никакого rolling update, никакой автоматической реакции на падение.

В production - единичные случаи. Один проект работает, и работает без проблем, но это зелёная лужайка: новый сервис, без legacy, небольшая команда, понимающая Docker. Переносить существующие клиентские сервисы в контейнеры мы пока не рискуем - не из-за Docker, а из-за оперативного контекста: инцидент в три часа ночи должен решаться тем, кто хорошо знает среду выполнения, а это пока не контейнеры в production.

Отдельный вопрос - мониторинг. Zabbix видит хост, но не контейнеры нормально. cAdvisor от Google появился и даёт метрики по контейнерам, но интеграции с нашим стеком нет. Это живая задача.

Где трение

Три вещи, на которые продолжаем наталкиваться:

• Сети на macOS. boot2docker создаёт VirtualBox VM, и сеть идёт через неё. Forwarded ports работают, но любой нетривиальный сценарий с несколькими контейнерами требует головы. Docker Machine решает часть проблем, но не все.
• Логи. docker logs хорошо для отладки, но для production нужна отдача логов в ELK. Это решается, но без стандартного способа - каждый проект велосипедит по-своему.
• Stateful-сервисы. Базы данных в контейнерах на production - это отдельная история с томами, резервными копиями и поведением при перезапуске. Пока держим базы на хостах, контейнеры - для stateless.

Что дальше

Два инструмента следующего года выглядят очевидно: Machine и Compose уже в работе, Swarm надо пощупать, как только выйдет что-то стабильнее preview. Параллельно смотрим, как Kubernetes развивается - Google открыл его в этом году, и идеи там интересные, хотя порог входа другой.

2015 будет показательным: либо контейнеры в production перестанут быть экзотикой, либо выяснится, что инструментарий для серьёзной эксплуатации ещё не готов. Пока ставим на первое, но осторожно.