Как расположить микросервисы в репозитории?
Вопрос в следующем: будет N количество микросервисов, как их положить в ГИТ лучше всего?
Каждый микросервис в отдельный репозиторий или можно описывать все в одном репозитории?
В дальнейшем планируем подключать k8s, чтобы поднимать копии сервисов автоматом.
Правильно понимаю, что в Jenkins'e будут собираться образы для docker'a, а потом уже эти образы будут использоваться в k8s?
Если так, то как в Jenkins'e быть с тем, что я поменял только, например, 3-ий из 10 микросервисов и надо пересобирать только его, а остальные не трогать, а докер образ сделать только для 3-го микросервиса (в случае, если все микросервисы будут в одном репозитории).
Ответы (3 шт):
Каждый микросервис в отдельный репозиторий или можно описывать все в одном репозитории?
Существует концепция Twelve-Factor App, в рамках которой оптимальным считается "Одно приложение — один репозиторий".
Правильно понимаю, что в Jenkins'e будут собираться образы для docker'a, а потом уже эти образы будут использоваться в k8s?
Вариантов можно придумать много, но именно такой подход верный
Вопрос в следующем: будет N количество микросервисов, как их положить в ГИТ лучше всего?
Лучше или хуже? Вы собираетесь готовить или будите спрашивать только рецепты?
Каждый микросервис в отдельный репозиторий или можно описывать все в одном репозитории?
Этот вопрос скорее к Вам. Как Вам удобно. Можно и так и так. Блюд много вкусы разные. Я уверен что найдётся сторонники любой концепции.
В дальнейшем планируем подключать k8s, чтобы поднимать копии сервисов автоматом.
Правильно понимаю, что в Jenkins'e будут собираться образы для docker'a, а потом уже эти образы будут использоваться в k8s?
Это как вы настроите. Но идея любого CI-CD автоматизировать все повторяющиеся процессы и сконцентрироваться на основном.
Если так, то как в Jenkins'e быть с тем, что я поменял только, например, 3-ий из 10 микросервисов и надо пересобирать только его, а остальные не трогать, а докер образ сделать только для 3-го микросервиса (в случае, если все микросервисы будут в одном репозитории).
Ну смотрите, если вы решили приготовить кашу у вас соответственно не должна возникать задача после выделить гречку и блюда. Если вы решили готовить всё вместе то и употреблять будите также. Есть плюсы минусы у всего. Держать всё вместе легко готовить, накидал и вот тебе каша. Задействовано минимально инструментов. Готовить раздельно - это отдельные не большие блюда в отдельной посуде, готовить следить накладно но в результате вариаций на много больше. Обмануть не получится.
На сегодняшний день я б пошел другим путем.
- Сделал бы один репозиторий.
- Начал с монолита который очень хорошо разделён на слои и модули
- Довел бы его очень быстро до MVP с хорошим CI-CD
- Начал распиливать на микросервисы если возникает в этом необходимость (она может никогда не возникнуть между прочим), раскладывая каждый новый сервис в свою репу
- И каждый интегрировал отдельно к монолиту.
Ваше приложение будет неизбежно дописываться и переписываться частично или полностью на протяжении всей разработки. Не нужно этого боятся это часть жизни. Повар который боиться испортить блюдо не повар.
Если над проектом работает много людей, то для уменьшения количества конфликтов при merge логично использовать разные репозитории в git (один микросервис = один репозиторий), а то получится как в монолите.
А так это дело вкуса, каждый выбирает сам. Идеальной практики нету. Вы же все равно в CI/CD будете прописывать автоматизацию сборки.