Ads
Comments 63
Не раз уже говорилось о том, что у Docker не так всё гладко с stateful-сервисами. Мы пробовали flocker, но он показался очень сырым, плагин постоянно «отваливался» по непонятным причинам.
Так же слышал про эту проблему. Это очень серьезная проблема, если вдруг у базы данных оторвется диск.
Тут гарантирована потеря данных и простой сервиса. То есть решение не подходит для прода?

Как быть? Поднимать базу отдельно в виртуалке вне докера?
Это хорошо, но имхо у базы все равно должен быть локальный диск. Иначе с какой скоростью она будет работать?
И как обеспечить, что это хранилище так же не оторвется?
Я, например не сторонник связывания контейнеров между собой, поэтому постгрес/мускуль у меня живут отдельно, и докеризированный apache+php с вордпрессами у меня бегают в SQL по IP. да, при рестарте ip меняется, поэтому у меня "обвязка" которая при запуске контейнера обновляет его IP в локальной DNS зоне
А где мускуль данные хранит? Куда пых закачивает картинки?
Вам же все равно надо как-то пробросить локальный каталог в контейнер.
Да, Вы правы. есть проброс каталога с ноды в /var/www/html контейнера.
А SQL вертится отдельно в полноценном окружении, с бекапами мониторингом и все такое, чего нельзя сделать в docker'ной виртуалке
Посмотрите в сторону weave или того же consul'а — у них есть встроенные dns-сервера, которые получают данные о сервисах не от самих сервисов, а слушая docker-сокет, что избавляет от необходимости самому делать обновление DNS и обработку, например, падения контейнера.

У себя я тоже полностью отказался от связывания и сейчас использую weave — доволен им: во-первых, есть внутренняя сеть контейнеров, независимая от внешней топологии и позволяющая связывать разнородные сети, в том числе, разные датацентры; во-вторых, есть надежное автообновление DNS при старте-остановке контейнера, которое позволяет реализовать красивую автобалансировку.
У меня заморочка в том, что образ apache+php один, а вот тонна контейнеров с примонтированными к ноде /var/www/html и контент сайтов у всех разный, как и "доменные" имена. поэтому я пока не могу понять как мне поможет консул. где один контейнер — один сайт
(Да, я про шаредхостинг)
Нууу… В принципе, если все настроено и работает, то шило на мыло менять смысла действительно нет :)

Но если этот шаредхостинг надо будет активно масштабироваться (новые домены подключать и отключать), то может и помочь в том плане, что единожды настроенный, он будет отслеживать создание-удаление контейнеров и под них создавать-удалять vhost'ы на фронтэнде/прокси (домены можно будет прописывать или в переменных окружения для каждого контейнера из той тонны сайтов, или в лейблах для них же).
Тоже думал над решением этой проблемы, пока что в качестве "универсального и надежного" решения вижу только репликацию средствами самой БД, при которой если одна нода падает, перевыбирается новый мастер и все продолжается дальше.
Кстати, чуть выше el777 написал про пыха, который куда-то должен закачивать картинки, и вот в этом как раз у нас и получилась проблема на одном из сервисов — классический портал, на котором медиа-файлы закачиваются на себя же. И если с базами есть репликация на уровне приложения, то тут несколько печальней — свой велосипед пилить не хочется, glusterfs с бухты-барахты в продашкшен пихать тоже не очень, а из остального пока что вижу только либо что-то вроде S3, либо GridFS от MongoDB.
На самом деле я глубоко "за" хранение картинок во внешнем сервисе — у нас сделан свой сторадж для этого.
Но вот хранение базы на удаленном диске или ее обновление по webdav — представляю с трудом.
На самом деле, я тоже за, только в моём случае полпроекта придётся переписать для использования внешнего хранилища ;)
Я выше и описал же, что да, проброс каталогов есть. Правда, сейчас проблема выбора кластерной фс.
Почему swarm, а не nomad?

PS Поправте по мелочи форматирование статьи :) Например баш портянка.
Спасибо, поправил.
Так стояла задача от клиента. Лично я наткнулся на него на сайте Docker и привлекло словосочетание native clustering system. Но nomad хотелось бы тоже попробовать.
Мы сейчас больше смотрим в сторону nomad, особенно потому, что он qemu умеет стартовать. По мелочи нам это будет нужно.
У swarm'а есть преимущество в том, что он работает прозрачно (хотя и не совсем, там есть проблемы с томами и портами при остановке контейнера), т.е. можно при помощи стандартного docker-клиента управлять всем кластером.

Кроме того, он может работать полностью как stateless-сервис, т.е. надо — запустил менеджер на какой-то ноде, поуправлял остальными, остановил, пошел кофе пить, потом пришел, запустил на другой ноде, поуправлял, остановил, опять пошел кофе пить :)

Да и проще с него начинать знакомиться с кластерами на контейнерах.

А nomad кажется интересной штукой, учитывая то, что он делается теми же, кем и consul, там должна быть хорошая интеграция. Надо будет как-нибудь попробовать.
На сколько я помню по документации, они почти идентичны по функционалу. В какой-то мере докерцы делали swarm с оглядкой на nomad. (не уверен, но где-то пробегало)
Простите, но картинки размером по высоте на половину\полный экран не располагают к чтению, мягко говоря. Это ведь не вконтакте.
Вот все пишут о настройке, но мало кто пишет об обслуживании.

Вот у меня до сих пор много вопросов по последующему развертыванию релизов и zero-downtime, откату, отслеживанию обновления вышестоящих образов, в том числе ОС, обновления всех нижестоящих, по этому событию
Тоже не очень понятно как делать стейджинг или хотя бы просто обновление приложения.
Рядом разворачивать второе? Потом переключать?

Как я понимаю, docker — это реализация концепции Immutable Server, возведенная в абсолют. То есть мы никогда не делаем обновления чего бы то ни было — мы просто разворачиваем с нуля новое. Ок, имеет право на жизнь. Но как сделать "безшовный переход" от старого к новому?
Всё что я вычитал — нужно ставить балансировщик сверху, разворачить рядом новое, и тут опять вопрос: как это сделать на плавно n-количестве контейнеров.
Сверху == вне докера?
Как он тогда будет угадывать куда направлять запрос, если внутри докера все будет динамически "плясать" — сейчас на одном порту, завтра на другом?
внутри докера, nginx или ha-proxy. Вопрос связей решается как статье описано (т.е по сути добавление контейнера как n+1)
у меня в проекте шаредхостинга логика достаточно простая:
1+n нод с контейнерами образа (apache + php). на ноде nginx, между нодами ospf для серой сети с айпишниками контейнеров.
Локальная dns зона, куда при старте контейнера обновляется ip адрес, потом nginx reload
в случае например обновить образ на ноде — ну ок, запускаем эти же контейнеры на другой ноде, первую выводим из обслуживания, обновляем образ, пересоздаем контейнеры, запускаем, работаем.

Пока не выбрал только кластерную fs для репликации клиентского контента
первую выводим из обслуживания, обновляем образ, пересоздаем контейнеры, запускаем, работаем.

руками всё это? а если контейнеров много? Ведь нужно учитывать ревизию + возможность отката
Ну дело Ваше — хотите руками, хотите — автоматизируйте.
Я вот насмотрелся на все эти панели хостинга на PHP, что платные, что бесплатные, и делаю теперь сам, на рельсах, кластерный шарехостинг, ибо надоело — в платных "да, мы знаем про этот баг, покупайте новую версию за стотыщ денег, в которой он пофикшен", в бесплатных "ой, тут баг висит второй год, и черт с ним, закрыли"
Я уже просто не в первый раз рыскаю в инете в поисках адекватного ПО для деплоя контейнеров (аналогичного mina, capistrano). Возможно нужен какой-то другой подход.
Не видел (или не заметил), что где-то есть папет.
В моем случае (мы выпиливаем puppet), смесь вполне работает. В целом, и на puppet можно все забацать.
на одном из прошлых проектов ci после тегирования коммита как релиз сама ансиблом пинала балансер, выводила ноду из экспуатации, загружала туда джанговый проект, запускала чо нужно и так дальше, по всем нодам.
не вижу принципиальной разницы между деплоем джанго проекта и контейнера
С балансировкой — хорошая мысль. А если это swarm? Поидее нужно через docker API подключаться и тормозить по очереди… Вот такое ПО я ищу.
Чем вам perl/bash/curl не угодили? меня они вполне устроили.
В swarm помнится те же docker команды умеет, только играет роль прослойки.
Тем что на это нужно время, ресурсы и тд. Смотрел видео от badoo — они писали свою систему.
Ну а я написал свою. Теперь вот, дело за вебмордой, это гораздо сложнее, чем нарисовать всю техническую часть обслуживающих скриптов и обвязок
Стоп, или я не могу уловить вашу боль, или Consul template. В моем случае ansible+consul+consul template.
Боль в том, что допустим у меня в кластере swarm 20+ нод. Мне нужно подключиться по docker API, погасить по очереди нужные контейнеры, скачать правильные новые(по номеру релиза), и мягко пиная балансировщик, обновлять.
Опять же, я не вижу проблемы, особенно при грамотно организованной базе consul. Имена контейнеров я из нее и беру.
а capistrano, ты сам логику не пишешь разве?
У меня минимум каких-либо вызовов, и все завернуто в ansible. Смысла искать что-либо нет. Еще один лишний продукт, который не будет решать ничего, что нельзя решить текущими.
Да, согласен, но все же это будет запуск контейнера на машине, в не в swarm.
если я верно помню swarm (у нас сейчас ручная балансировка и внедряем nomad), то там главное, чтобы нода была в swarm, а дальше ты работаешь так же командой docker.
Ну такое для меня лишнее.
сие:

Назначаем демону ноды метку:
`docker daemon --label com.example.storage=«ssd»`

Запускаем PostgreSQL с фильтром у указанной метке:
`docker run -d -e constraint:com.example.storage=«ssd» postgres`

в паре с указанным выше решает мои проблемы.
И остаётся вопрос актуализации образов. Нашел, что раньше можно было ставить свои hook на базовые образы(из library). Сейчас нельзя. Ну дальше по цепочке обновлять все образы зависимые.
хуки на дочерние образы? Но если например обновился debian образ — тут не отследишь автоматически.
А, я понял вас. Вот она сила привычки. :)

У меня следующая схема (в ci)
job1 — через packer собираю базовый образ (в моем случае ubuntu 14.04)
Далее триггеры CI пересобирают базовые сервисные образы.
Если деплой уже был, то новые образы выливаются на следующий день с основным деплоем (иногда проводим синхронизацию базовых образов на целевые машины). Если обновляем что-то блокерное, то идем по регламенту штатного деплоя.
То есть я независим от Docker Hub. У меня заведена политика минимальной зависимости от внешних источников софта, в том числе и по причине отслеживания версий.
А как мониторите это хозяйство?
(метрики, распределение контейнеров)

Как определяете, что надо произвести ребалансировку?
Пока все спецы по докеру не разбежались, поспрашиваю вас.

1) docker daemon запускается с указанием локального consul. Если контейнер с консулом умирает по любой причине, то наша нода теряется для кластера? Думал над тем, чтобы прятать консулы за балансером.

2) Как правильно масштабировать приложение? Запустили N контейнеров, а перед ними haproxy/nginx и consul-template. Но теперь у нас нод больше чем одна и что дальше? Получается перед балансировщиком ставим ещё один балансер?

3) Оверлейная сеть. Запускать все проекты в одной сети кажется не очень безопасным. Пока на каждый проект создаю свою подсеть. Здраво ли?
Only those users with full accounts are able to leave comments. , please.