Docker Swarm Replica/Global Mode + NFS or GlusterFS, как правильно подружить?
Господа, прошу помощи!
Строю систему оркестрации контейнеров на Docker Swarm. Дано: Ext.IP - haProxy - Docker Swarm (1 master, 5 nodes). Запускаю сервис, например jenkins, в режиме global (или replica 1+n), хранилищем конфигурации является примонтированный диск GlusterFS-Server, установленный на всех 6 машинах роя, хранилище подключаю через bind (заранее говорю, что подключение через созданный docker volume линкованный на шару, проблему не решает).
После запуска сайт работает неккоректно, не всегда догружает страницы, сбрасывается кэш, постоянно запрашивается ввод логина и пароля. Стоит запустить сервис в режиме replica = 1, или вовсе отдельным контейнером, так проблемы исчезают, все работает отлично.
Сначала хранилище строил на основе nfs. Был поднят отдельный сервер с быстрым диском, расшарен девайс, примонтировал ко всем нодам. Когда увидел проблему, задумался о блокировке файлов чтением/записью бэкендом jenkins'a, сопоставил с настройкой haProxy, он балансировал в roundrobin mode. Первое, что я предпринял, я отключил направление потоков на все ноды и оставил перенаправление трафика только на мастер - ситуация не исправилась, затем я сменил режим балансировки на leastconn, чтобы haProxy не переключал поток по порядку, а "привязывался" к последнему успешно работающему веб серверу - ситуация не исправилась. Как только я включаю репликацию или глобальный режим, то начинается чихарда страниц и нестабильная работа фронтэнда.
Далее, довольно много почитав на форумах, решил перестроить хранилище на GlusterFS, так как он рекомендован к использованию в Docker Swarm системе, позволяет не лету синхронизировать изменения и поддерживать отказоустойчивость шары. Однако, проблема так и не решилась.
Вопрос: Как правильно реализовать хранение и использование файлов конфигурации, файлы БД, логи сервисов Swarm в режиме реплик, или глобальном режиме? Как исключить конфликты блокировок файлов? Как правильно строить FailOver репликацию сервиса? Если оставить replica = 1, проблема решается и при падении ноды, Swarm, через некоторое время, успешно запустит сервис на другой ноде, но хотелось бы увидеть достоинства системы в нулевом простое. Заранее благодарен, на все дополнительные вопросы, с удовольствием, отвечу!
Возможно я не прав, так как реального опыта реализации указанной вами схемы у меня нет, но в случае с Jenkins, надо для начала убедится что он поддерживает такой режим работы. Основная проблема работы в кластере - это отсутствие нативной поддержки ))
scor2k, я думаю, если есть образ на публичном docker hub, разработанный самими производителями, который отлично работает в режиме обычного контейнера, или в режиме единичной реплики, то все в порядке с поддержкой. Тут вопрос в правильной реализации, потому что я более чем уверен, что я сам упускаю тонкости конфигурирования=) И. Jenkins - это к примеру, такая же проблема с Teamcity от JetBrains. Все равно спасибо за уделенное время=))) Будем ждать ответов от профессионалов.
apteryx,ну так в режиме единой реплики он у вас и так нормально работает? Разве нет? Проблемы начинаются при попытке заставить его работать с балансировщиком?
scor2k, да, в режиме единой реплики все работает нормально. Тут скорей я методом исключения считаю, что если несколько приложений не работают в режиме global or replica n+1, значит я не прав. А может Вы правы и балансировка не работает с этими приложениями.
apteryx, я более чем на 90% уверен что возможность работы в кластере необходимо закладывать при разработке ПО, хотя сам этого не делаю (благо мои мини-приложениям это особо не требуется). Опять же, единое сессионное хранилище - это минимум что надо в случае Jenkins...
Сложный
