Docker compose и объединение проектов с помощью mixer-a

[@kvaps]

Вам наверное будет интересно узнать о существовании такого инструмента как Crane.
Правда объединять конфиги он не умеет, но зато в нем можно полностью описать весь ваш проект, а так же:

• разделить его на группы
• на одтельном уровне конфига описать все ваши сети, волумы, а так же хуки
• ссылаться к ним при описании ваших групп и контейнеров
• проставлять зависимости

[@ZmeeeD]

Интересный проект но немножко о другом. Crane скорее `другой` docker-compose нежели чем mixer.

[@dvapelnik]

как-то не особо понял в чем была проблема

если у Вас один проект с файлом docker-compose.yml, то в нем, видимо, Вы прописываете и конфигурируете подсервисы ( database server , cache-server , proxy-server ), которые будут слинкованы с application-контейнером, который также сконфигурирован в этом же файле docker-compose.yml

если у Вас несколько проектов, то они, по идее, не должны пересекаться (разве что у Вас один и тот же контейнер используется разными проектами, к примеру, database-server ), тем более на стадии разработки.

docker-compose выдает префиксы для имен контейнеров и у Вас не должны пересекаться названия контейнеров. к примеру, у Вас есть проект project_A и он использует db , то контейнер будет иметь имя, соответственно, project_A_db_1 . и так далее

лично я еще сталкивался с ситуацией, когда у меня возникала подобная проболема с несколькими проектами, которые используют по несколько контейнеров. в разработке я использую как минимум по два контейнера: database + application

не могбы бы Вы описать практическую ситуацию из жизни на стадии разработки чтобы представить когда нужно будет использовать этот подход?

спасибо

[@romario13]

Привет Дмитрий!

У нас аналогичные задачи возникают. В идеале хотелось бы что-то похожее на такие слои:

— есть PostgreSQL в кластере. Ее настройкой занимаются администраторы баз данных. Они поддерживают конфигурацию и docker-compose файл для ее запуска.
— на следующем слое у нас система управления процессами (Taskurotta). Ей нужна база данных для работы. У нее свои владельцы. У них свой docker-compose для разворачивания системы в кластере. При этом база данных для этих людей может быть черным ящиком. Достаточно compose файл БД подгрузить к проекту, например, с помощью git submodules указав требуемую версию и они вместе стартанут. Владельцы этой системы запускают автоматические тесты на данном окружении.
— на следующем уровне абстракции есть прикладные микросервисы которым нужна Taskurotta которой нужна база данных. Они так-же пишут автоматические тесты и хотят использовать нужной версии систему управления процессами. И как черный ящик, потому как владельцы не они и им достаточно чтобы система была доступна по нужному порту. И групп таких микросервисов много со своими владельцами.
— на следующем уровне фронтенд разработка с REST сервисами, которым нужны несколько групп микросервисов, которым… которым нужен дом, который построил Джек :) Им уже тем более тяжело знать все нюансы настройки бэкенд систем. Им нужно свои тесты прогнать подключив бэкенд как черный ящик с торчащими на ружу точками взаимодействия.

На большом проекте в микросервисной архитектуре уже тяжело знать про всё. Хочется разделять всё на подсистемы со своими владельцами. Но при этом иметь возможность легко собрать окружения для выполнения автоматических тестов.

[@dvapelnik]

ага, тоесть из-за такой инкапсуляции работы отдельных команд над отдельными компонентами Вам и приходится в результате собирать единый docker-compose.yml файл для финишного тестирования и разварачивания конечной плаформе…

спасибо Вам

мне стало яснее где можно это применить

[@ZmeeeD]

В целом да — мы примерно тоже самое и делаем