Нужен ли оркестратор для запуска одного контейнера для отдельном сервере?
Наш проект работает на стеке nginx + php-fpm + mysql + redis.
Каждое приложение в отдельном контейнере, но все крутится на одном физическом сервере, и поднимается через docker-compose.
Возникла необходимость реплицировать базу данных на отдельный сервер (master + 2 slave), мастер остается на текущем сервере, и два слейва нужно разворачивать на двух отдельных серверах.
Вопрос: здесь обязательно нужен оркестратор? Можно ли без него?
Если нет, то как это сделать через docker-swarm?
topuserman, потому что:
1. Экземпляр БД нельзя безопасно перенести с одной машины на другую, тк он привязан к данным на диске
2. СУБД очень привязаны к производительности ФС и сети, которая падает при использовании контейнеров
3. Всякие Master-Slave/Master-Master репликации привязаны к настройкам СУБД, по тому ты не сможешь реплицировать только мощностями оркестратора, тебе всё равно придётся либо ещё какую-то автоматизацию с боку прикручивать, либо добавлять человеческий фактор.
4. А ещё настройки СУБД привязаны к конкретной машине, её процессору и памяти, чтобы планировщик запросов лучше понимал, как исполнять запрос для максимальной эффективности.
topuserman, на самом деле базы в контейнерах делают, более того, в сложных проектах даже используют "операторы", которые позволяют разворачивать базу, нафаршировав её резервированиями-репликациями (см. например в гугле postgres operator). Но это делают в действительно сложных проектах, в которых базы дробят на мелкие по каким-то существенным причинам и где умеют разбираться в том, как соблюсти надёжность и производительность на нужном уровне. И да, это задача как раз для сложной оркестрации. Если ваш проект дорастёт до такого уровня, вы сами поймёте это.
Для обычных проектов с 1-2 базами проще действительно базу на хосте. Это и быстрее, и надёжнее, и проще в обслуживании. Базу не деплоят с каждым релизом заново, изменения в её конфигах проще делаются на хосте, на базу на хосте часто проще накатывать миграции (хотя это можно оспорить - не так сложно мигратор запускать в контейнере).
topuserman, докер композ по умолчанию стартует все прописанные контейнеры в файле настроек. Достаточно 1 раз его запустить и дальше система будет сама его поддерживать. И запускать при перезагрузке
topuserman, можно и без него, если контейнеры на тех других серверах найдут. Так часто делают в проектах не очень большого размера (почесал свои 2000 контейнеров в docker-compose на двух серверах).
Например, есть два сервера, нужные сервисы публикуем на каких-то портах этих серверов, а в других контейнерах через env или через описания в конфигах передаём их адреса с портами.
topuserman, можно с одного хоста управлять Docker-ом на сескольких, только сертификаты надо прикрутить и заставить Docker демон слушать на TCP порту.
В прочем можно и через SSH
Средний
