Есть несколько микросервисов. Все они сейчас написаны на PHP. Есть окружение которое собирается и деплоится, в ней есть отдельно контейнер с веб-сервером и с интерпритатором, по факту это общие 2 контейнера для всех микросервисов, и получается что при деплое ногового сервиса мы копируем код в оба контейнера, да, код не шарится с хост машины. Из недостатков такого подхода:
1. Незабыть везде скопировать
2. Неудобно управлять правами
3. Нету контроля над конкретным сервисом (это например деплой новой версии или перезапустить процесс внутри)
4. Изминения одного сервиса аффектят все что есть внутри
Плюс: проще сетапить балансер
Почему встал такой вопрос, сервисов много и некоторые переводятся на новую версию интерпритатора, а другие ее не поддерживают и нужны кастомные модули и т.п., ясно что можна поднять другие ноды и там развернуть нужную версию, и пока оно так и работает, но нужна оптимизация
Есть 2й вариант, но пока не реализован, это вебсервер и интерпретатор поместить в один контейнер, да это не по "философии докера", но у такого подхода есть ряд преймуществ
Минус: сложнее сетапить балансер
Плюсы:
1. Полностью инкапсулирован микросервис
2. Есть контроль над ним (можна передеплоить или ребутнуть, стопнуть, другая версия пыхи, кастомный модуль и т.п.)
3. Не аффектит другие сервисы при maintenance
Сейчас есть репозиторий с енвом и там куча конфигов и когда нужно добавить новый микросервис или чета поменять в деплое то нужно лезть в эту репу и вносить сначала там правки и запускать пересборку или что-то еще передавая конкретный список сервисов и лопатить все что в списке, хотя нужно по факту только один сервис
Сейчас же планирую сделать так:
1. Репа с энвом останется но в ней будет обий набор для сборки базовых имеджей с настройками
2. У кажного сервиса в репе появится папочка docker где будет лежать все что нужно для сборки и запуска конкретного сервиса
не знаю поможет тебе или нет мой опыт, но я делал следующее
1. репо сервиса, содержит докер файл и гитлаб сий скрипт сборки, деплой сервиса выполняет этапы сборки и тегируя нужной версией контейнер складывает его в реджистри (соответственно таких сервисов н штук)
2. репо деплоя, ансибл который доставляет композ файл на хостовую машину, занимается пуллингом контейнеров и настройкой версий (энвироменты, которые зацеплены в композ файле) , так же через этот репозиторий я управляю энвироментами внутри самих сервисов, бренчи репозитория различаются по настройкам и отвечают за выкатку на разные стенды.
Что мне нравится в этой архитектуре, выкатка релиза происходит единомоментно, нет ситуации когда первый апдейченый сервис уехал пол часа назад и все лежит пока не приедет последний...
что мне не нравится, больше телодвижений чем обычно, для кластерного деплоя надо додумывать эту схему.
Выглядит неплохо, но вопрос немного не об этом, суть как бы в том что делать с php+nginx
Положить их в один контейнер что не по феншую как бы или разделять как сейчас
Средний
Простой
Средний
