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