Настройка Jenkins CI / CD для системы микросервисов

Question

У меня есть система с десятками микросервисов, все они собираются и выпускаются одинаково - каждый из них находится в док-контейнере и развернут в кластере Kubernetes.

Существует несколько кластеров (Dev1, dev2, QA ... Prod)

Мы используем Jenkins для развертывания каждого микросервиса.Каждый микросервис имеет свой собственный конвейер, и эти конвейеры дублируются для каждой среды, например:

DEV1 (просмотр)

• dev1_microserviceA (job /pipline)
• dev1_microserviceB
• ...
• dev1_microserviceX

DEV2

• dev1_microserviceA
• dev1_microserviceB
• ...
• dev1_microserviceX

...

PROD

• dev1_microserviceA
• dev1_microserviceB
• ...
• dev1_microserviceX

каждый из этих конвейеров практически идентичен, различия на самом деле просто вопрос параметров, таких как среда, название микросервиса, название git repo.

Некоторый общий код находится в библиотеках, которые использует каждый конвейер.Это правильная / типичная настройка и наиболее измененная настройка?Я хотел бы избежать создания конвейера для каждого микросервиса и для каждого случая, но не уверен, каковы мои дальнейшие варианты рефакторинга.Я новичок в Дженкинс и Devops.

Я изучил параметризованные конвейеры, но я не хочу вводить параметр каждый раз, когда мне нужно построить, и мне также нужно иметь возможность объединять сборки и видеть результаты всех сборок навзгляд в каждой среде.

Answer 1

Я бы использовал декларативные конвейеры, где вы можете определить свою логику в локальном Jenkinsfile в своих репозиториях.

Используя Jenkins, вы можете иметь "master" Jenkinsfile и / или проект, который вы можетенаследовать, вызывая вышестоящий проект.Это позволит вам эффективно делиться своими инструкциями и уменьшить дублирование.

Что обычно не рассматривается, когда речь идет о CI / CD, так это «управление» развертываниями.Поскольку большинство служб CI / CD не имеют состояния, у них нет понятия о развернутых приложениях.

GitLab прошел долгий путь с этим, но Дженкинс сильно отстал.

В конце дня вы будетенужно либо создать отдельный проект для каждого репозитория / цели из-за того, как работает Jenkins, ИЛИ (рекомендуется) иметь «главный» проект, который позволяет передавать такие вещи, как имя проекта, URL-адрес git-репо, конкретные переменные и значения приложения и так далее.