Комментарии 63
Не раз уже говорилось о том, что у Docker не так всё гладко с stateful-сервисами. Мы пробовали flocker, но он показался очень сырым, плагин постоянно «отваливался» по непонятным причинам.
Так же слышал про эту проблему. Это очень серьезная проблема, если вдруг у базы данных оторвется диск.
Тут гарантирована потеря данных и простой сервиса. То есть решение не подходит для прода?
Как быть? Поднимать базу отдельно в виртуалке вне докера?
Или поднимать такие вещи как Ceph, Amazon S3 или подобные решения. Мы, к сожалению, не использовали их.
Здесь немного написано о текущих поддерживаемых платформах https://docs.docker.com/registry/storagedrivers/
Здесь немного написано о текущих поддерживаемых платформах https://docs.docker.com/registry/storagedrivers/
Я, например не сторонник связывания контейнеров между собой, поэтому постгрес/мускуль у меня живут отдельно, и докеризированный apache+php с вордпрессами у меня бегают в SQL по IP. да, при рестарте ip меняется, поэтому у меня "обвязка" которая при запуске контейнера обновляет его IP в локальной DNS зоне
А где мускуль данные хранит? Куда пых закачивает картинки?
Вам же все равно надо как-то пробросить локальный каталог в контейнер.
Вам же все равно надо как-то пробросить локальный каталог в контейнер.
Радует, что мы не одни такие.
Почему swarm, а не nomad?
PS Поправте по мелочи форматирование статьи :) Например баш портянка.
PS Поправте по мелочи форматирование статьи :) Например баш портянка.
Простите, но картинки размером по высоте на половину\полный экран не располагают к чтению, мягко говоря. Это ведь не вконтакте.
Вот все пишут о настройке, но мало кто пишет об обслуживании.
Вот у меня до сих пор много вопросов по последующему развертыванию релизов и zero-downtime, откату, отслеживанию обновления вышестоящих образов, в том числе ОС, обновления всех нижестоящих, по этому событию
Вот у меня до сих пор много вопросов по последующему развертыванию релизов и zero-downtime, откату, отслеживанию обновления вышестоящих образов, в том числе ОС, обновления всех нижестоящих, по этому событию
Тоже не очень понятно как делать стейджинг или хотя бы просто обновление приложения.
Рядом разворачивать второе? Потом переключать?
Как я понимаю, docker — это реализация концепции Immutable Server, возведенная в абсолют. То есть мы никогда не делаем обновления чего бы то ни было — мы просто разворачиваем с нуля новое. Ок, имеет право на жизнь. Но как сделать "безшовный переход" от старого к новому?
Рядом разворачивать второе? Потом переключать?
Как я понимаю, docker — это реализация концепции Immutable Server, возведенная в абсолют. То есть мы никогда не делаем обновления чего бы то ни было — мы просто разворачиваем с нуля новое. Ок, имеет право на жизнь. Но как сделать "безшовный переход" от старого к новому?
Всё что я вычитал — нужно ставить балансировщик сверху, разворачить рядом новое, и тут опять вопрос: как это сделать на плавно n-количестве контейнеров.
Сверху == вне докера?
Как он тогда будет угадывать куда направлять запрос, если внутри докера все будет динамически "плясать" — сейчас на одном порту, завтра на другом?
Как он тогда будет угадывать куда направлять запрос, если внутри докера все будет динамически "плясать" — сейчас на одном порту, завтра на другом?
у меня в проекте шаредхостинга логика достаточно простая:
1+n нод с контейнерами образа (apache + php). на ноде nginx, между нодами ospf для серой сети с айпишниками контейнеров.
Локальная dns зона, куда при старте контейнера обновляется ip адрес, потом nginx reload
в случае например обновить образ на ноде — ну ок, запускаем эти же контейнеры на другой ноде, первую выводим из обслуживания, обновляем образ, пересоздаем контейнеры, запускаем, работаем.
Пока не выбрал только кластерную fs для репликации клиентского контента
1+n нод с контейнерами образа (apache + php). на ноде nginx, между нодами ospf для серой сети с айпишниками контейнеров.
Локальная dns зона, куда при старте контейнера обновляется ip адрес, потом nginx reload
в случае например обновить образ на ноде — ну ок, запускаем эти же контейнеры на другой ноде, первую выводим из обслуживания, обновляем образ, пересоздаем контейнеры, запускаем, работаем.
Пока не выбрал только кластерную fs для репликации клиентского контента
первую выводим из обслуживания, обновляем образ, пересоздаем контейнеры, запускаем, работаем.
руками всё это? а если контейнеров много? Ведь нужно учитывать ревизию + возможность отката
Ну дело Ваше — хотите руками, хотите — автоматизируйте.
Я вот насмотрелся на все эти панели хостинга на PHP, что платные, что бесплатные, и делаю теперь сам, на рельсах, кластерный шарехостинг, ибо надоело — в платных "да, мы знаем про этот баг, покупайте новую версию за стотыщ денег, в которой он пофикшен", в бесплатных "ой, тут баг висит второй год, и черт с ним, закрыли"
Я вот насмотрелся на все эти панели хостинга на PHP, что платные, что бесплатные, и делаю теперь сам, на рельсах, кластерный шарехостинг, ибо надоело — в платных "да, мы знаем про этот баг, покупайте новую версию за стотыщ денег, в которой он пофикшен", в бесплатных "ой, тут баг висит второй год, и черт с ним, закрыли"
Я уже просто не в первый раз рыскаю в инете в поисках адекватного ПО для деплоя контейнеров (аналогичного mina, capistrano). Возможно нужен какой-то другой подход.
ansible?
мне нужно, чтобы ci это делал, а не cm.
И в чем проблема?
Мне кажется смешивать puppet и ansible будет излишне.
на одном из прошлых проектов ci после тегирования коммита как релиз сама ансиблом пинала балансер, выводила ноду из экспуатации, загружала туда джанговый проект, запускала чо нужно и так дальше, по всем нодам.
не вижу принципиальной разницы между деплоем джанго проекта и контейнера
не вижу принципиальной разницы между деплоем джанго проекта и контейнера
Кстати да.
С балансировкой — хорошая мысль. А если это swarm? Поидее нужно через docker API подключаться и тормозить по очереди… Вот такое ПО я ищу.
Чем вам perl/bash/curl не угодили? меня они вполне устроили.
В swarm помнится те же docker команды умеет, только играет роль прослойки.
В swarm помнится те же docker команды умеет, только играет роль прослойки.
Стоп, или я не могу уловить вашу боль, или Consul template. В моем случае ansible+consul+consul template.
Боль в том, что допустим у меня в кластере swarm 20+ нод. Мне нужно подключиться по docker API, погасить по очереди нужные контейнеры, скачать правильные новые(по номеру релиза), и мягко пиная балансировщик, обновлять.
Опять же, я не вижу проблемы, особенно при грамотно организованной базе consul. Имена контейнеров я из нее и беру.
Если воспользоваться советом — и писать своё — то вопросов нет.
а capistrano, ты сам логику не пишешь разве?
У меня минимум каких-либо вызовов, и все завернуто в ansible. Смысла искать что-либо нет. Еще один лишний продукт, который не будет решать ничего, что нельзя решить текущими.
У меня минимум каких-либо вызовов, и все завернуто в ansible. Смысла искать что-либо нет. Еще один лишний продукт, который не будет решать ничего, что нельзя решить текущими.
привязка к конкретным машинам
consul
Да, согласен, но все же это будет запуск контейнера на машине, в не в swarm.
если я верно помню swarm (у нас сейчас ручная балансировка и внедряем nomad), то там главное, чтобы нода была в swarm, а дальше ты работаешь так же командой docker.
На текущий момент, если ничего не найду — буду писать плагин к mina для работы через docker api. Благо есть gem. Вот ещё нашел — https://github.com/newrelic/centurion, но пока не присматривался
Ну такое для меня лишнее.
сие:
в паре с указанным выше решает мои проблемы.
сие:
Назначаем демону ноды метку:
`docker daemon --label com.example.storage=«ssd»`
Запускаем PostgreSQL с фильтром у указанной метке:
`docker run -d -e constraint:com.example.storage=«ssd» postgres`
в паре с указанным выше решает мои проблемы.
И остаётся вопрос актуализации образов. Нашел, что раньше можно было ставить свои hook на базовые образы(из library). Сейчас нельзя. Ну дальше по цепочке обновлять все образы зависимые.
В моем случае тут все решает Bamboo (если угодно Jenkins или teamcity).
хуки на дочерние образы? Но если например обновился debian образ — тут не отследишь автоматически.
А, я понял вас. Вот она сила привычки. :)
У меня следующая схема (в ci)
job1 — через packer собираю базовый образ (в моем случае ubuntu 14.04)
Далее триггеры CI пересобирают базовые сервисные образы.
Если деплой уже был, то новые образы выливаются на следующий день с основным деплоем (иногда проводим синхронизацию базовых образов на целевые машины). Если обновляем что-то блокерное, то идем по регламенту штатного деплоя.
У меня следующая схема (в ci)
job1 — через packer собираю базовый образ (в моем случае ubuntu 14.04)
Далее триггеры CI пересобирают базовые сервисные образы.
Если деплой уже был, то новые образы выливаются на следующий день с основным деплоем (иногда проводим синхронизацию базовых образов на целевые машины). Если обновляем что-то блокерное, то идем по регламенту штатного деплоя.
То есть я независим от Docker Hub. У меня заведена политика минимальной зависимости от внешних источников софта, в том числе и по причине отслеживания версий.
Вот тут в комментариях красиво развернули тему обновления контейнеров https://habrahabr.ru/post/277699/
А как мониторите это хозяйство?
(метрики, распределение контейнеров)
Как определяете, что надо произвести ребалансировку?
(метрики, распределение контейнеров)
Как определяете, что надо произвести ребалансировку?
Пока все спецы по докеру не разбежались, поспрашиваю вас.
1) docker daemon запускается с указанием локального consul. Если контейнер с консулом умирает по любой причине, то наша нода теряется для кластера? Думал над тем, чтобы прятать консулы за балансером.
2) Как правильно масштабировать приложение? Запустили N контейнеров, а перед ними haproxy/nginx и consul-template. Но теперь у нас нод больше чем одна и что дальше? Получается перед балансировщиком ставим ещё один балансер?
3) Оверлейная сеть. Запускать все проекты в одной сети кажется не очень безопасным. Пока на каждый проект создаю свою подсеть. Здраво ли?
1) docker daemon запускается с указанием локального consul. Если контейнер с консулом умирает по любой причине, то наша нода теряется для кластера? Думал над тем, чтобы прятать консулы за балансером.
2) Как правильно масштабировать приложение? Запустили N контейнеров, а перед ними haproxy/nginx и consul-template. Но теперь у нас нод больше чем одна и что дальше? Получается перед балансировщиком ставим ещё один балансер?
3) Оверлейная сеть. Запускать все проекты в одной сети кажется не очень безопасным. Пока на каждый проект создаю свою подсеть. Здраво ли?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Наш опыт знакомства с Docker