Рабочий процесс в конвейере CI / CD - хранилище кода Jenkins, Kubernetes и SVN / GitHub

Question

Я пытаюсь использовать Jenkins, Kubernetes и мой репозиторий SVN для реализации конвейера CI / CD для развертывания моих микросервисов Spring Boot. Во время изучения я обнаружил, что при развертывании Jenkins + Kubernetes образ Docker извлекается из реестров образов. И когда я изучал пример реализации, я обнаружил этот вариант для автоматического построения изображений в Jenkins и варианты определения хранилища кода, такого как GitHub / SVN.

Что касается рабочего процесса Jenkins, я почувствовал сомнения и добавил сюда,

1. Если образ Docker извлекается из некоторых реестров образов для развертывания с использованием Jenkins и Kubernetes, то почему мы снова определяем исходную ссылку хранилища кода (GitHub / SVN) в Jenkins?

Причина сомнений- Я думаю, думая, что Кубернетес и Дженкинс зависят только от реестра образов для развертывания путем извлечения изображений. Поэтому у меня возникло сомнение, почему мы определяем нашу ссылку на репозиторий GitHub в Jenkins. Это единственная причина для этого сомнения. Пожалуйста, поправьте меня, если я думаю не в том направлении.

2. Когда я изучал, я обнаружил, что в Дженкинсе есть опция автоматического создания образа Docker с использованием некоторых сценариев (я не знаю точно точную работу, я обнаружил в вашем видео). Так что, если мы извлекаем изображение из реестра изображений, то почему мы снова используем автоматическую сборку образов Docker в Jenkins? Если это альтернативный вариант, в чем разница между извлечением изображений и автоматизированным построением изображений в Jenkins? Это все в соответствии с нашим требованием? Или за этим стоит какая-то другая концепция?

Answer 1

Мы работаем над проектом с открытым исходным кодом под названием Jenkins X , который является предлагаемым подпроектом фонда Jenkins, направленным на автоматизацию CI / CD на Kubernetes с использованием Jenkins и GitOps для продвижения.

Когда вы объединяете изменения в основную ветку, Jenkins X создает новый семантически версионный дистрибутив вашего приложения (pom.xml, jar, изображение докера, диаграмма руля). Затем конвейер автоматизирует генерацию запросов извлечения для продвижения вашего приложения через все среды с помощью GitOps.

Вот демонстрация того, как автоматизировать CI / CD с несколькими средами в Kubernetes, используя GitOps для продвижения между средами и Preview Environments по запросу Pull - с использованием приложений Spring Boot и nodejs (но мы поддерживаем много языков + рамки).

Обратите внимание, что сейчас Jenkins X поддерживает только git.

Answer 2

Извините, но я не до конца понял ваш вопрос. Я пытаюсь объяснить наш рабочий процесс CI / CD. Может быть, это поможет.

1. Разработчик передает код в GIT.
2. Дженкинс автоматически
   • проверяет репо
   • строит микросервисы с весенней загрузкой (тесты, покрытие кода и т. Д.)
   • сборка образа докера
   • фиксация образов докера в реестре

При различных параметрах переключателей / сборок разработчик может принять решение о сборке сборок SNAPSHOT, которые развертываются только в определенный реестр моментальных снимков только для разработчиков, или для создания реальных выпусков.

Разработчик также может решить развернуть образ Docker впоследствии в системе int или prod. В этом случае Kubernetes извлекает образ из реестра (который Дженкинс ранее развернул там).