×

Кто-то использует git submodules в docker контейнерах?

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті

Встал вопрос разбить проект на отдельные части. Так как doсker образ можно сделать из git репозитория, то встал вопросы разбить проект на отдельные repositories. Но в git есть такая фича, как submodules: git-scm.com/...​n/v2/Git-Tools-Submodules

Вот думаю, может кто-то использует. С удовольствием бы пообщался на эту тему.

Update: добавлю немного деталей. В целом git-сообщество сходится во мнении, что если у вас есть отдельные части не связанные между собой (или скажем по средствам API), то вы должны хранить их в отдельных репозиториях. Но бывают ситуацию, когда проект удобнее хранить в одном репозитории, но реально он разбит на части, которые будут собираться в отдельные docker-контейнеры.

Допустим есть такая структура

Project
|---Services
         |..... MicroService1
         |......MicroService2
         |.......

И вам нужно отдельно собирать каждый MicroServiceX в отдельный docker-контейнер.
1. Первый способ это сделать, просто собираю контейнер из папки — т.е. docker build -t /Project/Service/MicroService1
2. Второй вариант это разбить на отдельные репозитории и собирать отдельно — т.е. docker build -t /github.com/Project/MicroService1. Но тут уже нужно перестраивать проект
3. И третий вариант который меня интересует — можно ли собрать отдельные контейнеры, если все хранится в одном репозитории, но при этому не забирать все локально, а делать это все командой docker build ?

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Даю проверенный способ, которым я пользовался уже в 3х проектах.

Делаете либо отдельную папку — /project/docker в котором будут подпапки, в которых будет лежать Dockerfile, конфиги и куда будет копироваться бинарник/jar-ник/etc при билде, а еще лучше отдельную папку в каждом сервисе где будет находиться все необходимое.
В каждой папке делаете скрипт — build.sh, который будете вызывать для сборки контейнера.

Можно еще сделать скрипт build_all.sh, который будет вызывать либо все, либо указанные параметром контейнеры.

Что это дает:
1) Удобство, теперь чтобы собрать контейнер нужно всего лишь выполнить один скрипт.
2) Гибкость, сборка некоторых контейнеров может отличаться от сборки других.
3) Простота, вызвая скрипт не опечатаешься.

По сути это все равно вариант #1. Просто вы скриптуете билд процесс.

Ну так вариант #3 когда по команде docker build создаются несколько контнейнеров попросту не существует. Нужно либо сделать отдельные докерфайлы для каждого сервиса либо сгенерировать их как это делают с помощью — www.scala-sbt.org/sbt-native-packager.

p.s. А написать пару скриптов это что, плохое решение?))

Да все верно. Я не хочу создавать одной командой несколько контейнеров. Моя цель хранить контекст ВСЕХ контейнеров в одном репозитории и создавать контейнеры командой docker build, но я не хочу перед этим выполнять git pull, а возложить эту работу на сам docker build. Единственные способ это делать git submodules.

Что-то я пропустил видимо. docker build умеет из гит репозиториев сам чекаутить?

Да. Там уже указано в документации PATH или URL. docs.docker.com/...​erence/commandline/build

да, и давно уже. Nice. Но твою проблему это не решит, похоже, так как все равно один Dockerfile и из него больше одного образа одной командой не затагить. Или несколько docker build, что в принципе отличается от твоего первого способа только тем, что не нужно выливать сорцы предварительно.
В сторону docker-compose не смотрел? Он обычно удобнее когда больше одного образа нужно.

В сторону docker-compose не смотрел? Он обычно удобнее когда больше одного образа нужно.

Нашел статью по docker compose и git submodules. Буду разбираться, пока не совсем понятно.

git submodules скорее всего тут совершенно не при чем.

Для начала, что не удобно в варианте 1) и 2) сборки?

Результаты одной сборки используются в другой? Тогда возможно docker multistage build то, чего не хватает? Или внутреннего aftifactory/nexus/npm/whatever.

А git submodules — это костыль. Иногда относительно удобный, но всегда можно без него.

Нет, multistage это не совсем то. Результаты одной сборки не используются в другой.
Mutlistage — это если у вас есть контейнер для Development environment, а потом вы все потестировали и потом из него собрали Production версию, их которой убрали весь мусор не нужный для PROD.

можете раскрыть мотивацию?

Але за деяких обставин, цей код має знаходитися в одному контейнері

тобто, окремі модулі пишуть різні люди, проте використовуються вони як частини моноліту, а не як окремі докер контейнери, вірно?

Кожна сторінка окреме апп. яке запущене у окремому контейнері. Апп коли збираеться виконуе резолюцію залежностей. Апп — окремий репозіторій, деякі кастомні залежності — окремі репозіторіі. Збираеться через CI-CD Лінкуе все до купи головний проксі сервер.

«сторінки» досить складні і розподяленні на декілька команд розробників. Тобто сенс е у керуванні процесом розробки. Ризики деплою і підтримки також нижчі як до всіеї системи.
Бекенд також окремо і поділенний на купу контейнерів, які звязуються також на точці входу.

Гмм, но это же потребует заметно больше ресурсов для готового приложения + проблемы интеграции, нет?

як розпилити веб-морду на окремі контейнери, і чи має це сенс?

ну, я не знаю, чи це має сенс, тому і питаю :)

А можете описать процесс сборки. Я написал в основном топике пример, что бы мне хотелось.

кожен репозіторій мае свій докер файл і як результат сі один докерімадж. Також у нас е окремі репозіторіі з залежностями які ми самі і розробляем. Залежносі виконуються на етапі збирання у тому числі і з приватних репо.

С сабмодулями постоянно какие то бока вылазят. И мало вводных данных чтобы посоветовать что то.

А можете детально ? Какие проблемы ?

Несколько раз вылезали конфликты от которых гит впадал в ступор, все переставало работать и приходилось попотеть чтобы починить. Это кроме банального неудобства в использовании.

Ладно, я попробую поработать с submodules локально. Посмотрю, может действительно разбить на репозитории.

а как код подмодуля будет использоваться?
он деплоится в изолированный контейнер? а какой смысл встраивать его код(хоть через submodules, хоть через subtree) в код другого микросервиса?
он используется кодом «контейнера» напрямую? тогда, может, лучше интегрировать его через менеджер зависимостей? заодно версионность лучше будет контролироваться.

в моем опыте — микросервисы по отдельным репо лежали, реюзабельные компоненты публиковались как пакеты и подключались через собственный реестр пакетов.

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

Підписатись на коментарі