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, через некоторое время, успешно запустит сервис на другой ноде, но хотелось бы увидеть достоинства системы в нулевом простое. Заранее благодарен, на все дополнительные вопросы, с удовольствием, отвечу!
  • Вопрос задан
  • 369 просмотров
Пригласить эксперта
Ответы на вопрос 1
@scor2k
Возможно я не прав, так как реального опыта реализации указанной вами схемы у меня нет, но в случае с Jenkins, надо для начала убедится что он поддерживает такой режим работы. Основная проблема работы в кластере - это отсутствие нативной поддержки ))

P.S. Буду рад ошибиться и подожду ответа )
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы