> Zotonic не умеет работать с пулом серверов БД, он коннектится одному серверу при старте и дальше работает с ним. Если поднять отдельный контейнер с haproxy, который будет раскидывать трафик на несколько инстансов Zotonic'а, каждому из них нужен свой Pg, а это означает мультимастер репликацию, которая сейчас в Pg делается только костылями разной степени уродливости. Для настоящей HA нужно серьёзно допилить Zotonic, чтобы он писал только в мастер, а для чтения выбирал слейва из пула, при этом имел бы возможность на ходу переключаться на нового мастера. Подозреваю, вы плохо читали. http://docs.zotonic.com/en/latest/developer-guide/getting-st...
Да у них там есть докер, который пригоден для ознакомительных целей. В прод его нельзя. Вот тут они заботливо помогли с начальной точкой для организации приложения http://docs.zotonic.com/en/latest/developer-guide/docker.html обратите внимание что контейнеров уже 2.
То что фреймворк работает с одной точкой подключения к базе - это вообще не проблема. Точнее, это не проблема фреймворка. Вам нужен repmgr или pgpool чтобы построить докерезированный кластер постгреса. Эта задача со звёздочкой, потому что постгрес и отказоустойчивость... это каждый сам должен для себя делать. Докер тут скорее мешает, а не помогает. Собственно mysql-то почему популярен. Сколько его не ругай, а вот для таких задач он и создан.
Ну и самое главное. Хапрокся в отдельном контейнере... а на чём у вас там крутятся все эти контейнеры, что у вас ингресс-балансировку нужно изобретать как велосипед в отдельном контейнере... не важно. Видимо контейнерной среды нету толком никакой... В любом варианте, всё это прекрасно делается даже в форме:
2х haproxy+keepalived
2x zotonic
2-3x postgresql
Можно то же самое с мускулем, можно в докере, можно без. Вы себе все проблемы с HA сами придумали, особенно про костыли разной степени уродливости. Докер же поможет автоматизировать костылестроение.
> Можно, конечно, иметь один Pg на несколько Zotonic'ов, но это нихрена никакой не HA, к тому же производительность всей системы упрётся в производительность Pg.
Это как раз HA, это просто не LB. Балансировка соединений к базе - это вообще другая история. Это всегда делается ради производительности, а производительность LB на операциях UPDATE/DELETE в случае с LB на postgresql всегда оставляет желать лучшего. Оно медленнее чем одна нода в виду того, что такое постгрес, для чего он нужен и почему его не используют на таких задачах как CMS те, у кого есть задачи по высокой нагрузке. Если у приложения есть задача по балансировке колоссального наплыва пользовательских запросов, причем многие из которых могут что-то удалять или обновлять, то вон она какая Apache Cassandra есть.
http://zotonic.com/page/620/proven-and-powerful-database
Вот тут они пишут про то что 99.9% сайтов это не надо. Что как бы поясняет, для чего и для каких нагрузок эта штука. И про то что у них куча функций средствами RDBMS. Выбор в пользу постгреса у них тоже зачётный =)
Это я к тому что для Zotonic вам не нужен LB никогда. Если вам стал нужен LB вам нужно выбросить Zotonic. Сидеть при этом без HA, потому что нету LB из коробки, как-то странно...
