Docker 1.0: первый стабильный, но в продакшн не спешим

На этой неделе Docker.inc объявили 1.0. Событие по-своему знаковое: после больше года публичной разработки через 0.x-серию авторы впервые говорят «API стабилен, можно использовать в продакшне». Мы следим за Docker с марта и апробировали 0.10/0.11, так что было интересно посмотреть что именно изменилось.

Если коротко: изменилось меньше чем ожидали, но в правильную сторону.

Что принёс 1.0

Changelog 1.0 не столько про новые возможности, сколько про стабилизацию того что было. Несколько конкретных вещей, которые нас интересовали:

• Стабильный Remote API. Docker взаимодействует с внешними инструментами через HTTP API. До 1.0 авторы оговаривались: API может поменяться в любой момент. Теперь обещают обратную совместимость в рамках мажорной версии. Для инструментов автоматизации это принципиально.
• Официальный реестр Docker Hub. Публичный реестр образов был и раньше, но с 1.0 он получил имя, нормальный интерфейс и организационные аккаунты. Тянуть официальные базовые образы Ubuntu, CentOS, Debian теперь с понятной точки.
• Улучшенная работа с томами. docker cp для копирования файлов из остановленных контейнеров - мелочь, но удобная.
• Поддержка RHEL. Docker.inc подписали партнёрское соглашение с Red Hat и официально поддерживают RHEL 6.5 и 7. До этого RHEL-пользователи работали с Docker на свой страх и риск.

На практике для нас самое ощутимое - стабильность API. Скрипты автоматизации, которые мы писали под 0.10 и 0.11, с 1.0 работают без изменений. Это было бы нормой, но в пре-релизной серии случалось по-разному.

Где запустили прямо сейчас

После выхода 1.0 мы обновили наш тестовый стенд и запустили Docker в двух местах, где он реально имеет смысл сегодня.

Jenkins-агенты для CI. Каждый прогон тестов запускается в свежем контейнере. Образ содержит нужные зависимости - версию Ruby, набор gem-ов, переменные окружения. Агент берёт задание, поднимает контейнер, прогоняет тесты, контейнер удаляется. Следующий прогон начинается с чистого состояния. Это решает хорошо знакомую проблему: накопление мусора на CI-сервере после сотни прогонов с разными версиями зависимостей.

Плюс неожиданный бонус: сборочное окружение теперь описано в Dockerfile и лежит рядом с кодом в репозитории. Раньше состояние Jenkins-агентов существовало только в виде ручных установок, которые никто не документировал.

Dev-стенды разработчиков. Несколько коллег попробовали запускать локальные зависимости (PostgreSQL, Redis) в контейнерах вместо установки на хост. Работает чище: завёл контейнер, поработал, снёс. Машина не обрастает несколькими параллельными версиями PostgreSQL для разных проектов.

Почему в продакшн не идём

Это вопрос который задают, и ответ у нас есть.

Docker 1.0 - это стабильный одиночный демон на одном хосте. Если нужен один контейнер на одной машине - всё отлично. Но реальная инфраструктура так не устроена. Нам нужно:

• Запустить контейнер на одном из нескольких хостов в зависимости от нагрузки.
• Перезапустить контейнер на другом хосте если текущий упал.
• Обновить образ без простоя сервиса.
• Сбалансировать трафик между несколькими экземплярами.

Ничего из этого Docker 1.0 сам по себе не умеет. Это задача оркестратора - инструмента, который управляет несколькими хостами и контейнерами на них. Инструменты такие существуют и активно разрабатываются - Fleet от CoreOS, Mesos, несколько других экспериментальных проектов. Но ни один из них не имеет того уровня зрелости, который у нас есть например у Ansible или VMware для виртуальных машин. Это честная оценка состояния на сегодня, не критика.

Второй момент - сеть. Контейнеры на разных хостах не видят друг друга без дополнительных overlay-сетей. Решения есть - pipework, rudder (экспериментальный overlay от CoreOS), - но они тоже не вышли за пределы «попробуй и расскажи что получилось».

Третий момент - логирование и мониторинг. В нашем ELK-стеке всё работает через файловые логи и Logstash-агенты на хостах. Docker разрывает эту схему: логи контейнеров живут в /var/lib/docker/containers/ в JSON-формате, Logstash-агент на хосте их не подхватывает автоматически. Можно настроить - мы пробовали - но это дополнительный слой конфигурации, который надо поддерживать.

Суммируя: сам Docker 1.0 готов к серьёзной работе. Инфраструктура вокруг Docker для продакшн-использования - нет, и говорить «это стабильно для продакшна» значит либо иметь в виду очень простой сценарий, либо быть готовым к серьёзной инженерной работе без гарантированного результата.

Что с нашим стендом на трёх контейнерах

В майском посте жаловались на порядок запуска - Flask падал если Postgres ещё не поднялся. В 1.0 это не исправили и правильно: это не проблема Docker, это проблема порядка запуска сервисов, и решать её должно приложение или оркестратор. Наш workaround с pg_isready в entrypoint так и остался.

Что реально улучшилось - стабильность самого демона. За три месяца с 0.9 по 0.11 docker daemon у нас пару раз уходил в странное состояние, когда docker ps зависал на несколько секунд и контейнеры не стартовали. С 1.0 за первые две недели таких случаев не было. Выборка маленькая, но направление понятно.

Куда смотрим дальше

Команда Docker анонсировала три проекта которые пойдут поверх 1.0: Swarm (кластеризация), Compose (описание многоконтейнерных приложений, развитие Fig) и Machine (управление хостами). Это то что нужно для реального применения. Но всё это пока в статусе «скоро» без конкретных дат и без публичного кода - так что наблюдаем.

На наш взгляд Docker 1.0 - это точка где инструмент перестал быть игрушкой и стал рабочим. CI-агенты и dev-окружения - вполне себе продуктивное использование. Продакшн сервисы с требованиями к доступности - рано, и мы торопиться не будем.