Docker-экосистема в середине 2015: Compose, Machine, Swarm, Registry

Год назад вышел Docker 1.0 - официально стабильный, готовый к продакшну. С тех пор вокруг него выросла целая экосистема инструментов, и Docker Inc. активно продвигает её как единый стек: Compose для описания сервисов, Machine для создания хостов, Swarm для кластеризации, Registry для хранения образов. Звучит стройно. По факту - каждый инструмент находится на своей стадии зрелости, и слепо доверять этому набору не стоит.

Мы используем Docker в нескольких интеграционных проектах и к середине 2015-го сложилось достаточно чёткое понимание, чему можно доверять прямо сейчас, а где надо держать руку на пульсе.

Docker Compose: единственный, кто готов к работе

Compose - это история успеха из всего набора. Мы писали про него в январе ещё как про инструмент для локальных стендов, но с тех пор он заметно вырос. Версия 1.2 добавила поддержку подстановки переменных окружения и расширения через extends - это уже позволяет переиспользовать базовый docker-compose.yml между dev, test и prod без дублирования.

На практике схема такая: базовый файл описывает сервисы и образы, отдельные оверлеи переопределяют переменные окружения и volumes. docker-compose -f base.yml -f prod.yml up -d - и поднимается нужный стек. Это не идеально, но работает предсказуемо.

Compose мы ставим в prod на небольших проектах без сложной кластеризации. Один хост, несколько контейнеров, нормальный restart policy. Для этого сценария Compose - правильный выбор: читаемый YAML, простые команды, не нужно учить новый оркестратор.

Docker Swarm: для простых задач, осторожно

Swarm мы гоняли в мае на трёхнодовом кластере и выводы не поменялись. Версия 0.3/0.4 закрывает один сценарий: несколько stateless-сервисов, внешний балансировщик уже есть, требования к автовосстановлению минимальные. Если всё это так - Swarm работает и главный его козырь реален: тот же docker run, тот же CLI, нулевой порог входа для команды.

Проблемы начинаются как только появляются требования к scheduling по реальной нагрузке, health checks с перезапуском на другой ноде, или stateful-сервисы. Там Swarm не отвечает. Это не критика - это честная оценка того, что инструмент умеет на сегодня.

Для более сложных сценариев мы смотрим в сторону Mesos + Marathon. Это другой уровень операционной сложности, но там есть и нормальный планировщик, и автовосстановление, и работа с задачами в общем смысле, не только контейнерами. Ещё один кандидат - Kubernetes, который сейчас активно обсуждается в сообществе. Мы его не трогали в production-контексте, но держим в поле зрения.

Docker Machine: полезный, но не для постоянных серверов

Machine закрывает конкретную задачу: быстро поднять Docker-хост для тестовой среды. Мы используем его с марта для тестовых и QA-стендов с коротким жизненным циклом. Там он работает хорошо.

Для постоянных серверов - нет. Machine не заменяет нормальный провизионинг. Наш Ansible-стек остаётся для управления конфигурацией на долгоживущих серверах; Machine работает поверх для Docker-специфичных операций или рядом для временных хостов.

Кроме того, Machine в текущем виде не умеет управлять конфигурацией Docker daemon после создания хоста. Захотел добавить registry mirror или кастомные флаги - отдельный шаг через SSH или Ansible. Мы с этим уже живём, но надо держать в голове.

Private Registry: обязательный элемент

Это, пожалуй, самое недооценённое звено. Docker Hub удобен для публичных образов, но тащить docker pull из интернета в продакшн-пайплайне - плохая идея по нескольким причинам: зависимость от внешней сети, скорость, невозможность контролировать что именно лежит в теге.

Мы подняли private Docker Registry (v2) на внутреннем хосте. Схема простая: образы собираются в CI (Jenkins), пушатся в локальный registry, с него же тянутся при деплое. Hub используется только для базовых публичных образов (postgres, redis, nginx) - и то их зеркалируем локально через registry mirror.

Registry v2 работает надёжно. Единственная боль - авторизация: встроенного UI нет, управление доступом через HTTP basic auth с nginx-прокси. Нормальной ролевой модели нет из коробки, если нужно давать разный доступ разным командам - придётся городить.

Картина в целом

Если описать текущее состояние одним абзацем: экосистема Docker реальна, Compose готов к работе, остальное - с оговорками.

Инструментальная карта для наших проектов на сегодня:

• Compose - dev-окружение и однохостовый прод без сложной кластеризации. Идёт в работу.
• Machine - тестовые и QA-стенды с коротким жизненным циклом. Идёт в работу, не для постоянных серверов.
• Swarm - небольшой кластер stateless-сервисов без требований к advanced scheduling. Аккуратно, с пониманием ограничений.
• Registry v2 - обязательный элемент для любого серьёзного использования Docker. Без него нет смысла говорить про production.
• Mesos / Kubernetes - смотрим, пока не трогаем в production.

Главная ловушка середины 2015-го - воспринимать весь стек как однородно зрелый, потому что Docker 1.0 вышел год назад и звучит солидно. Сам Docker-демон - да, стабильный. Вокруг него - разная степень готовности, и это надо учитывать при выборе инструментов под конкретную задачу.