Как расположить микросервисы в репозитории?

Вопрос в следующем: будет N количество микросервисов, как их положить в ГИТ лучше всего?

Каждый микросервис в отдельный репозиторий или можно описывать все в одном репозитории?

В дальнейшем планируем подключать k8s, чтобы поднимать копии сервисов автоматом.

Правильно понимаю, что в Jenkins'e будут собираться образы для docker'a, а потом уже эти образы будут использоваться в k8s?

Если так, то как в Jenkins'e быть с тем, что я поменял только, например, 3-ий из 10 микросервисов и надо пересобирать только его, а остальные не трогать, а докер образ сделать только для 3-го микросервиса (в случае, если все микросервисы будут в одном репозитории).


Ответы (3 шт):

Автор решения: ittx

Каждый микросервис в отдельный репозиторий или можно описывать все в одном репозитории?

Существует концепция Twelve-Factor App, в рамках которой оптимальным считается "Одно приложение — один репозиторий".

Правильно понимаю, что в Jenkins'e будут собираться образы для docker'a, а потом уже эти образы будут использоваться в k8s?

Вариантов можно придумать много, но именно такой подход верный

→ Ссылка
Автор решения: Aziz Umarov

Вопрос в следующем: будет N количество микросервисов, как их положить в ГИТ лучше всего?

Лучше или хуже? Вы собираетесь готовить или будите спрашивать только рецепты?

Каждый микросервис в отдельный репозиторий или можно описывать все в одном репозитории?

Этот вопрос скорее к Вам. Как Вам удобно. Можно и так и так. Блюд много вкусы разные. Я уверен что найдётся сторонники любой концепции.

В дальнейшем планируем подключать k8s, чтобы поднимать копии сервисов автоматом.

Правильно понимаю, что в Jenkins'e будут собираться образы для docker'a, а потом уже эти образы будут использоваться в k8s?

Это как вы настроите. Но идея любого CI-CD автоматизировать все повторяющиеся процессы и сконцентрироваться на основном.

Если так, то как в Jenkins'e быть с тем, что я поменял только, например, 3-ий из 10 микросервисов и надо пересобирать только его, а остальные не трогать, а докер образ сделать только для 3-го микросервиса (в случае, если все микросервисы будут в одном репозитории).

Ну смотрите, если вы решили приготовить кашу у вас соответственно не должна возникать задача после выделить гречку и блюда. Если вы решили готовить всё вместе то и употреблять будите также. Есть плюсы минусы у всего. Держать всё вместе легко готовить, накидал и вот тебе каша. Задействовано минимально инструментов. Готовить раздельно - это отдельные не большие блюда в отдельной посуде, готовить следить накладно но в результате вариаций на много больше. Обмануть не получится.

На сегодняшний день я б пошел другим путем.

  1. Сделал бы один репозиторий.
  2. Начал с монолита который очень хорошо разделён на слои и модули
  3. Довел бы его очень быстро до MVP с хорошим CI-CD
  4. Начал распиливать на микросервисы если возникает в этом необходимость (она может никогда не возникнуть между прочим), раскладывая каждый новый сервис в свою репу
  5. И каждый интегрировал отдельно к монолиту.

Ваше приложение будет неизбежно дописываться и переписываться частично или полностью на протяжении всей разработки. Не нужно этого боятся это часть жизни. Повар который боиться испортить блюдо не повар.

→ Ссылка
Автор решения: Виктор Веретнов

Если над проектом работает много людей, то для уменьшения количества конфликтов при merge логично использовать разные репозитории в git (один микросервис = один репозиторий), а то получится как в монолите.

А так это дело вкуса, каждый выбирает сам. Идеальной практики нету. Вы же все равно в CI/CD будете прописывать автоматизацию сборки.

→ Ссылка