зачем один докер image? по имеджу на сервис.

да, docker-compose это про деплой.
А мне всё же хочется и разработку и деплой выстроить таким образом:
- Есть 5 репозиториев - 3 разных api (на разных языках), 1 frontend
- Разработчики работают с репозиториями, там настроенный CI и всё хорошо
- Настал момент релиза - нужно убедиться что все репозитории друг с другом нормально и без багов работают. (все репы в мастере имеют самый актуальный и оттестированный код)
- Я предпологаю что submodules позволят сделать коммит, который "зафиксирует версию" всех сервисов и разработчики продолжат работать в обычном режиме.
- Затем уже эти сервисы раскидываем на разные сервера в production, зная что они будут нормально взаимодействовать (свой docker compose на каждой машине)

При этом и в гугле и в чатах разработчиков вижу не любовь к submodules. Смотрю альтернативы.

Да, Глеб, я согласен, это не микросервисы. Вообще это понятие сложно 100% трактовать.
Это больше сервисы, которые, к сожалению (или к счастью), нельзя сделать единым монолитом.

Затем уже эти сервисы раскидываем на разные сервера в production, зная что они будут нормально взаимодействовать (свой docker compose на каждой машине)

Вот это как ты себе видишь?

тут решений может быть тьма

В таком случае действительно на CI для master/staging веток репозиториев сервисов собирайте docker image для каждого сервиса и кладите в registry по тегу версии. А в отдельном репе держите docker-compose, в котором прописанны конкретные тэги image'ей. Релиз будет представлять из себя изменение в docker-compose тэгов образов и последущая раскатка.

Когда у тебя есть образ докера с протестированным кодом в этом же окружении, ты ему просто говоришь запустись и все. какие репозитории git. от кода до работающего сервиса может быть еще куча всего

Это уже отдельная история :)
Пока пробую понять как организовать разработку, что бы у меня на выходе было 5 контейнеров которые заранее протестированы автотестами и QA.

твоя цель это запакованный код в образ.

на основе образа запускаешь контейнер там гоняешь тесты линтер и что там тебе еще нужно. если все ок разворачиваешь контейнра из образа на проде

Да, смотрю сейчас в том числе и на локальный docker registry, в котором всё хранить по тегам.
За идею про конкретные теги imag'ей спасибо. По сути тот же фикс версии

используя регистри ты получаешь не версии кода а версии готовых сервисов с окружением.

Да, и это то что мне надо, infrastructure as a code – в каждом отдельно взятом репозитории сервиса есть Dockerfile, который гарантирует что этот контейнер сбилдится и этот код в нём будет работать.
Потом только интеграционное тестирование, но это тоже отдельная история.

И всё же история ушла глубже, я просто хотел понять чем плохи git submodules 😁

тем что это вчерашний день

ну или их прменение сузилось до более конкретных кейсов

но ведь это не аргумент. Мы по прежнему пишем скрипты на баш, хотя сколько он уже существует

молоток изобретён кучу лет назад, он устарел и не выполняет своих функций от этого?

Ну просто поддержка этого дела гораздо больнее, чем работа через registry (хотя у registry заморочно настраивать права доступа)