Комментарии 6
Вам наверное будет интересно узнать о существовании такого инструмента как Crane.
Правда объединять конфиги он не умеет, но зато в нем можно полностью описать весь ваш проект, а так же:
Правда объединять конфиги он не умеет, но зато в нем можно полностью описать весь ваш проект, а так же:
- разделить его на группы
- на одтельном уровне конфига описать все ваши сети, волумы, а так же хуки
- ссылаться к ним при описании ваших групп и контейнеров
- проставлять зависимости
как-то не особо понял в чем была проблема
если у Вас один проект с файлом
если у Вас несколько проектов, то они, по идее, не должны пересекаться (разве что у Вас один и тот же контейнер используется разными проектами, к примеру,
docker-compose выдает префиксы для имен контейнеров и у Вас не должны пересекаться названия контейнеров. к примеру, у Вас есть проект
лично я еще сталкивался с ситуацией, когда у меня возникала подобная проболема с несколькими проектами, которые используют по несколько контейнеров. в разработке я использую как минимум по два контейнера:
не могбы бы Вы описать практическую ситуацию из жизни на стадии разработки чтобы представить когда нужно будет использовать этот подход?
спасибо
если у Вас один проект с файлом
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 не могбы бы Вы описать практическую ситуацию из жизни на стадии разработки чтобы представить когда нужно будет использовать этот подход?
спасибо
Привет Дмитрий!
У нас аналогичные задачи возникают. В идеале хотелось бы что-то похожее на такие слои:
— есть PostgreSQL в кластере. Ее настройкой занимаются администраторы баз данных. Они поддерживают конфигурацию и docker-compose файл для ее запуска.
— на следующем слое у нас система управления процессами (Taskurotta). Ей нужна база данных для работы. У нее свои владельцы. У них свой docker-compose для разворачивания системы в кластере. При этом база данных для этих людей может быть черным ящиком. Достаточно compose файл БД подгрузить к проекту, например, с помощью git submodules указав требуемую версию и они вместе стартанут. Владельцы этой системы запускают автоматические тесты на данном окружении.
— на следующем уровне абстракции есть прикладные микросервисы которым нужна Taskurotta которой нужна база данных. Они так-же пишут автоматические тесты и хотят использовать нужной версии систему управления процессами. И как черный ящик, потому как владельцы не они и им достаточно чтобы система была доступна по нужному порту. И групп таких микросервисов много со своими владельцами.
— на следующем уровне фронтенд разработка с REST сервисами, которым нужны несколько групп микросервисов, которым… которым нужен дом, который построил Джек :) Им уже тем более тяжело знать все нюансы настройки бэкенд систем. Им нужно свои тесты прогнать подключив бэкенд как черный ящик с торчащими на ружу точками взаимодействия.
На большом проекте в микросервисной архитектуре уже тяжело знать про всё. Хочется разделять всё на подсистемы со своими владельцами. Но при этом иметь возможность легко собрать окружения для выполнения автоматических тестов.
У нас аналогичные задачи возникают. В идеале хотелось бы что-то похожее на такие слои:
— есть PostgreSQL в кластере. Ее настройкой занимаются администраторы баз данных. Они поддерживают конфигурацию и docker-compose файл для ее запуска.
— на следующем слое у нас система управления процессами (Taskurotta). Ей нужна база данных для работы. У нее свои владельцы. У них свой docker-compose для разворачивания системы в кластере. При этом база данных для этих людей может быть черным ящиком. Достаточно compose файл БД подгрузить к проекту, например, с помощью git submodules указав требуемую версию и они вместе стартанут. Владельцы этой системы запускают автоматические тесты на данном окружении.
— на следующем уровне абстракции есть прикладные микросервисы которым нужна Taskurotta которой нужна база данных. Они так-же пишут автоматические тесты и хотят использовать нужной версии систему управления процессами. И как черный ящик, потому как владельцы не они и им достаточно чтобы система была доступна по нужному порту. И групп таких микросервисов много со своими владельцами.
— на следующем уровне фронтенд разработка с REST сервисами, которым нужны несколько групп микросервисов, которым… которым нужен дом, который построил Джек :) Им уже тем более тяжело знать все нюансы настройки бэкенд систем. Им нужно свои тесты прогнать подключив бэкенд как черный ящик с торчащими на ружу точками взаимодействия.
На большом проекте в микросервисной архитектуре уже тяжело знать про всё. Хочется разделять всё на подсистемы со своими владельцами. Но при этом иметь возможность легко собрать окружения для выполнения автоматических тестов.
ага, тоесть из-за такой инкапсуляции работы отдельных команд над отдельными компонентами Вам и приходится в результате собирать единый
спасибо Вам
мне стало яснее где можно это применить
docker-compose.yml файл для финишного тестирования и разварачивания конечной плаформе…спасибо Вам
мне стало яснее где можно это применить
В целом да — мы примерно тоже самое и делаем
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Docker compose и объединение проектов с помощью mixer-a