Docker 1.9 + overlay-сети: перевели первое приложение на Swarm-кластер

Когда мы в сентябре пробовали Swarm 1.0 на тестовом стенде, главный незакрытый вопрос звучал так: как контейнеры на разных хостах вообще будут между собой разговаривать? Нативного ответа не было. Можно было прокинуть порты наружу и ходить через внешний IP хоста, можно было поднять flannel или weave поверх - но это уже свой слой поверх слоя, своя поломка и своя ответственность. Docker 1.9 закрыл этот вопрос изнутри.

Вышел он на прошлой неделе, и ключевая фича - multi-host overlay-сети. Контейнеры на разных физических (или виртуальных) хостах можно положить в одну виртуальную сеть, и они будут видеть друг друга по именам, как будто сидят рядом. Под капотом - VXLAN поверх существующей сети хостов, etcd или Consul как хранилище состояния. Прозрачно для приложения, без правки /etc/hosts вручную.

Мы решили не ждать и перевели на двухнодовый Swarm первое живое приложение из наших managed-проектов.

Что за приложение и почему именно оно

Выбирали сознательно: Python-приложение, несколько stateless-сервисов (веб-процесс + воркеры), PostgreSQL на отдельном хосте уже был вынесен на dedicated VM ещё до нас. Идеальный кандидат - нет состояния внутри контейнеров, нет требований к sticky sessions, трафик невысокий, но живой.

До перехода оно стояло на одном хосте в Docker Compose. Работало нормально, но хост был единой точкой отказа, и масштабировать воркеры можно было только вертикально.

Что потребовалось поднять

Overlay-сети в Docker 1.9 требуют внешнего key-value store для хранения сетевого состояния. Мы выбрали Consul - уже был в инфраструктуре для service discovery. Если Consul нет - подходит etcd или ZooKeeper, логика та же.

Схема простая:

[ consul-агент ] <-- оба хоста видят один кластер Consul

[ хост-1 ]                [ хост-2 ]
  swarm manager             swarm worker
  web-контейнеры            web-контейнеры
      |                         |
      +------overlay-сеть-------+
            (myapp_net)

Docker daemon на обоих хостах запускается с параметрами --cluster-store consul://... и --cluster-advertise <IP>:2376. Потом создаётся overlay-сеть:

docker network create --driver overlay myapp_net

И дальше любой контейнер, подключённый к myapp_net, видит другой контейнер в этой же сети по имени - вне зависимости от того, на каком физическом хосте он запущен.

Как прошёл сам переезд

Честно - несколько часов возни. Не из-за overlay-сетей как таковых, а из-за деталей окружения.

Первое - версия Docker должна быть 1.9 на всех нодах без исключения. У нас на одном хосте стояло 1.8, и Swarm отказывался добавлять его в кластер. Обновление заняло минуты, но надо помнить.

Второе - --cluster-advertise надо указывать правильный интерфейс. Мы сначала указали внешний IP, хотя ноды ходят между собой через внутреннюю сеть. Получили красивые таймауты при регистрации контейнера в overlay. После правки на внутренний IP - всё заработало.

Третье - Compose-файл потребовал небольших правок. Добавили networks: секцию, указали external: true для нашей overlay-сети, прописали сервисы в неё. Без этого сервисы поднимаются в дефолтной bridge-сети конкретного хоста и не видят друг друга через кластер.

После всех правок docker-compose up на Swarm-менеджере поднял контейнеры по двум хостам. web-контейнер на хосте-1 без проблем достучался до worker-контейнера на хосте-2 по имени сервиса. Это работало.

Что не работает ещё

Rolling update через Compose в этой конфигурации не такой гладкий, как хотелось бы. Мы деплоим через docker-compose up -d с пересозданием нужных контейнеров, что не идеально для zero-downtime - контейнер на несколько секунд уходит в рестарт.

Ещё момент - overlay-сети создают заметный overhead на диагностику. docker ps на одном хосте показывает только то что запущено на нём. Чтобы увидеть картину целиком - нужно идти на Swarm-менеджер и делать docker -H swarm:2375 ps. Если привык к одному хосту - придётся перестраивать привычки.

Мониторинг пришлось подправить отдельно: Zabbix-агент смотрел на контейнеры по именам на конкретном хосте, часть имён съехала на второй хост. Полчаса на правку шаблонов.

Итог

Overlay-сети убрали главный практический барьер к multi-host деплою. Раньше межхостовая сеть для контейнеров была отдельным проектом - flannel, weave, своя автоматизация, свой мониторинг. Теперь это одна команда и секция в Compose-файле.

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

Kubernetes умеет больше, и мы за ним следим. Но для stateless-приложений умеренного масштаба Swarm с overlay-сетями - это работающее решение без лишнего слоя сложности.