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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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