Руководство по Jenkins

В руководстве мы расскажем, зачем нужен Jenkins, а также покажем, как установить Jenkins на Ubuntu.

Jenkins — это сервис, с помощью которого можно автоматизировать процесс непрерывной интеграции программного обеспечения. Непрерывная интеграция (Continuous Integration) — один из этапов разработки, на котором происходит сборка рабочих копий проекта в единый макет-черновик, их тестирование, доставка или развёртывание программного обеспечения. Во время интеграции можно выявить слабые места и возможные ошибки в проекте и сразу их исправить.

На этапе интеграции разработчики объединяют код вручную, что занимает много времени. Jenkins позволяет автоматизировать этот этап. Сервис подойдёт как для профессионалов, так и для начинающих специалистов.

• имеет открытый исходный код, написанный на Java;
• поддерживает свыше 1000 плагинов для интеграции с инструментами тестирования, разработки и деплоя;
• работает больше чем в двух средах одновременно без потери эффективности;
• Jenkins хорошо подойдёт для проектов, которые написаны на Python;
• оптимизирует рабочий процесс: вам не нужно нанимать штат профессиональных программистов, в Jenkins можно разобраться даже без специальной подготовки;
• выявляет и устраняет нестандартные ошибки без привлечения человека;
• минимизирует количество ошибок, возникающих в связи с человеческим фактором.

Jenkins можно установить на Windows, macOS, Debian, Ubuntu, CentOS и другие операционные системы. Также Jenkins можно установить через системные пакеты, Docker или запустить автономно на любом компьютере с настроенной Java Runtime Environment (JRE).

Jenkins можно установить с официального сайта одним из двух способов: скачать из раздела «Download» или использовать команды из раздела «Documentation». Для Jenkins документация на русском не разработана, однако именно в этом разделе можно найти рекомендации для быстрой установки. Поэтому установим Jenkins на Ubuntu версий 16.04/18.04/20.04 вторым способом.

Как установить Jenkins

Для Jenkins системные требования следующие:

• 256 Мб оперативной памяти,
• минимум 1 Гб дискового пространства при установке на ОС и 10 Гб при запуске в качестве контейнера Docker.

3) Скачать и установить Jenkins

Jenkins может быть установлен на платформе Windows или Unix, но мы сосредоточимся только на установке Windows.

Предпосылки:

Прежде чем приступить к установке Jenkins в вашей системе Windows, есть некоторые предварительные условия для установки Jenkins на ваш компьютер.

Требования к оборудованию:

• Вам нужно минимум 256 МБ оперативной памяти на вашем компьютере или ноутбуке для установки Jenkins
• Вам нужно как минимум 1 ГБ места на жестком диске для Jenkins.

Требования к программному обеспечению:

• Поскольку Jenkins работает на Java, вам нужна либо последняя версия Java Development Kit (JDK), либо Java Runtime Environment (JRE).

Типы релизов

Jenkins выпускает два типа версий в зависимости от потребностей организации.

• Долгосрочная поддержка релиза
• Еженедельный выпуск

Долгосрочная поддержка релиза (LTS):

Долгосрочные релизы поддержки доступны каждые 12 недель. Они стабильны и широко тестируются. Этот выпуск предназначен для конечных пользователей.

Еженедельный выпуск:

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

Мы будем использовать релиз LTS, хотя процесс будет таким же, как и для еженедельного выпуска.

Как скачать Дженкинс?

Для успешной установки Jenkins необходимо выполнить следующие шаги:

Шаг 1) Перейдите на https://jenkins.io/download/ и выберите платформу. В нашем случае Windows

Шаг 2) Перейдите в папку загрузки с локального компьютера и разархивируйте загруженный пакет. Дважды щелкните по разархивированному jenkins.msi . Вы также можете Jenkin, используя WAR (веб-приложение ARchive), но это не рекомендуется.

Шаг 3) На экране установки Jenkin нажмите Далее.

Шаг 4) Выберите место, где вы хотите установить экземпляр Jenkins (по умолчанию это C: \ Program Files (x86) \ Jenkins), затем нажмите кнопку Next .

Шаг 5) Нажмите на кнопку Установить.

Шаг 6) После завершения установки нажмите «Готово».

Шаг 7) Во время процесса установки может появиться информационная панель, информирующая пользователя о том, что для полной настройки система должна быть перезагружена в конце текущей установки. Нажмите кнопку ОК, когда всплывет информационная панель:

Как разблокировать Дженкинс?

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

Шаг 1) После завершения процесса установки Jenkins откроется вкладка браузера с запросом начального пароля администратора. Чтобы получить доступ к Jenkins, вам нужно перейти по следующему пути в вашем веб-браузере.

HTTP: // локальный: 8080

Если вы можете получить доступ к указанному выше URL-адресу, это подтверждает, что Jenkins успешно установлен в вашей системе.

Шаг 2) Исходный пароль администратора должен быть найден в пути установки Jenkins (задается на шаге 4 в разделе Установка Jenkins).

Для расположения по умолчанию C: \ Program Files (x86) \ Jenkins, файл с именем initialAdminPassword можно найти в C: \ Program Files (x86) \ Jenkins \ secrets.

Однако, если был выбран пользовательский путь для установки Jenkins, вам следует проверить это местоположение для файла initialAdminPassword .

Шаг 3) Откройте выделенный файл и скопируйте содержимое файла initialAdminPassword .

Шаг 4) Вставьте пароль во всплывающую вкладку браузера ( http: // localhost: 8080 / login? Form =% 2F ) и нажмите кнопку «Продолжить».

Настроить Дженкинс

Вы также можете настроить свою среду Jenkins, выполнив следующие действия:

Шаг 1) Нажмите кнопку «Установить предложенные плагины», чтобы Jenkins извлекла и установила необходимые плагины

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

Примечание . Вы можете выбрать опцию «Выбрать подключаемые модули для установки» и выбрать подключаемые модули, которые хотите установить.

Шаг 2) После установки всех предложенных плагинов откроется панель «Создать первого администратора». Заполните все поля нужными реквизитами и нажмите кнопку « Сохранить и завершить ».

Шаг 3) После того, как вы заполните указанные выше данные, наконец, он запросит информацию URL, где вы можете настроить путь к экземпляру по умолчанию для Jenkins. Оставьте это как есть, чтобы избежать путаницы позже. Однако, если другое приложение уже использует порт 8080, вы можете использовать другой порт для Jenkins и, наконец, сохранить настройки, и вы закончили установку Jenkins. Нажмите кнопку « Сохранить и продолжить »:

Поздравляем! Мы успешно установили новый сервер Jenkins. Нажмите кнопку «Начать использовать Дженкинс».

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

Настроика Jenkins клиента на Windows (Slave node for Jenkins)

Как подключить Windows к Jenkins? Как настроить Windows slave node on Jenkins. Есть известная проблема с подключением Windows агента к Jenkins, поэтому используем Java с установкой его в автозагрузку. Работает отлично и стабильно если все сделать по инструкции ниже. Инструкция по английски, но все предельно понятно. Если что не понятно — пишите.

1. Create, activate and update a new Windows VM (если это VM)

2. Create a local user “jenkins” with password “jenkins”.

3. Disable password policy (optional): start > type Local security policy > Account Polices > password policy > Meet complexity = disable)

4. Setup user’s auto login. Run command “netplwiz”, uncheck checkbox, select user “jenkins” and apply changes, enter password “jenkins” two times

5. Setup time sync server time.domain.com (локальный сервер времени — желательно чтобы Jenkins сервер использовал тот же сервер для синхронизации времени)

6 .Отключаем котроль подтверждения операций для установки приложений. Go to startup menu, and enter UAC — “Users Account Control Settings”. Turn the slider to down — OFF in the window that pops up. This will disable UAC warnings. (windows 10/2012 — http://winaero.com/blog/how-to-turn-off-and-disable-uac-in-windows-10/)

Download and install:

2. Git https://git-scm.com/download,

3. Install Git, select “3-th” option in a first window

Create folder C:\jenkins

Create empty bat file C:\jenkins\start_agent.bat

Add shortcut (ярлык) to Startup folder:

login as jenkins, create shortcut for C:\jenkins\start_agent.bat on Desktop,

run shell:startup, paste shortcut in opened folder.

Setup Git — настройки зависят от вашего Git, здась пример с авторизацией по ключу.

Run cmd and copy/paste code below:

git config —global user.name «Jenkins»

git config —global user.email » Этот e-mail адрес защищен от спам-ботов, для его просмотра у Вас должен быть включен Javascript «

ssh-keygen -t rsa -C » Этот e-mail адрес защищен от спам-ботов, для его просмотра у Вас должен быть включен Javascript » (don’t enter password)

Copy content from file %username%/.ssh/id_rsa.pub and paste as a key in http://local-gerrit.com for user jenkins

При необходимости — Create a file in folder %username%/.ssh/config

Hostname local-gerrit.com (ваш git)

Port 29418 (порт на катором отвеяает ваш git)

Test an ability to clone repository

git clone ssh:// Этот e-mail адрес защищен от спам-ботов, для его просмотра у Вас должен быть включен Javascript :29418/project

On Jenkins server — create a new node on Jenkins as “Dumb Slave”.

Choose “Launch slave agents via Java Web Start”

Copy command with particular -secret key

Open C:\jenkins\start_agent.bat and paste command with particular key:

Net start w32time

start /min java -jar slave.jar -jnlpUrl http://jenkins.domain.com/computer/node-name/slave-agent.jnlp -secret qwerty12

Все. Если Нода активна, можете запускать на ней работу.

Учимся разворачивать микросервисы. Часть 4. Jenkins

Это четвертая и заключительная часть серии статей «Учимся разворачивать микросервисы», и сегодня мы настроим Jenkins и создадим пайплайн для микросервисов нашего учебного проекта. Jenkins будет получать файл конфигурации из отдельного репозитория, собирать и тестировать проект в Docker-контейнере, а затем собирать Docker-образ приложения и пушить его в реестр. Последней операцией Jenkins будет обновлять кластер, взаимодействуя с Helm (более подробно о нем в прошлой части).

План серии статей:

Ключевые слова: Java 11, Spring Boot, Docker, image optimization

Ключевые слова: Kubernetes, GKE, resource management, autoscaling, secrets

Ключевые слова: Helm 3, chart deployment

Настройка Jenkins и пайплайна для автоматической доставки кода в кластер

Ключевые слова: Jenkins configuration, plugins, separate configs repository

Jenkins — это сервер непрерывной интеграции, написанный на Java. Он является чрезвычайно расширяемой системой из-за внушительной экосистемы разнообразных плагинов. Настройка пайплайна осуществляется в декларативном или императивном стиле на языке Groovy, а сам файл конфигурации (Jenkinsfile) располагается в системе контроля версий вместе с исходным кодом. Это удобно для небольших проектов, однако, часто более практично хранить конфигурации всех сервисов в отдельном репозитории.

Код проекта доступен на GitHub по ссылке.

Установка и настройка Jenkins

Установка

Существует несколько способов установить Jenkins:

• Из war-архива
• Напрямую из Docker-образа
• Развернуть в Kubernetes

War-архив с программой можно запустить из командной строки или же в контейнере сервлетов (№ Apache Tomcat). Этот вариант мы не будем рассматривать, так как он не обеспечивает достаточной изолированности системы.

Устранить этот недостаток можно, установив Jenkins в Docker. Из коробки Jenkins поддерживает использование докера в пайплайнах, что позволяет дополнительно изолировать билды друг от друга. Запуск докера в докере — плохая идея (здесь можно почитать почему), поэтому необходимо установить дополнительный контейнер ‘docker:dind’, который будет запускать новые контейнеры параллельно контейнеру Jenkins’а.

Также возможно развернуть Jenkins в кластере Kubernetes. В этом случае и Jenkins, и дочерние контейнеры будет работать как отдельные поды. Любой билд будет полностью выполняться в собственном контейнере, что максимально изолирует выполнения друг от друга. Из недостатков этот способ имеет довольно специфичную конфигурацию. Из приятных бонусов Jenkins в Google Kubernetes Engine может быть развернут одним кликом.

Хоть третий способ и кажется наиболее продвинутым, мы выберем прямолинейный путь и развернем Jenkins в Docker напрямую. Это упростит настройку, а также избавит нас от нюансов работы со stateful приложениями в Kubernetes. Хорошая статья для любопытствующих про Jenkins в Kubernetes.

Так как проект учебный, то мы установим Jenkins на локальной машине. В реальной обстановке можно посмотреть в сторону, например, Google Compute Engine. В дополнение замечу, что изначально я пробовал использовать Jenkins на Raspberry Pi, но из-за разной архитектуры «малинки» и машин кластера они не могут использовать одни и те же Docker-образы. Это делает невозможным применение Raspberry Pi для подобных вещей.

После установки Jenkins открываем http://localhost:8080/ и следуем инструкциям. Настроить Jenkins можно через UI, либо программно. Последний подход иногда называют «инфраструктура как код» (IaC). Он подразумевает описание конфигурации сервера с помощью хуков — скриптов на Groovy. Оставим этот способ настройки за рамками данной статьи. Для интересующихся ссылка.

Плагины

Меню работы плагинов доступно из настроек (Manage Jenkins -> Manage Plugins). Многие полезные плагины уже установлены. Особо среди них выделю ‘Blue Ocean’, предоставляющий удобный интерфейс для работы с вашими пайплайнами.

Для нашего проекта нам понадобится установить два плагина: Remote File Plugin и Kubernetes CLI. Remote File Plugin позволяет хранить Jenkinsfile в отдельном репозитории, а Kubernetes CLI предоставит доступ к kubectl внутри нашего пайплайна.

Установка Helm

Так как наше приложение развернуто с помощью Helm-чарта, то для обновления кластера нам нужно установить еще и Helm. Плагина для Helm я не нашел, поэтому стоит установить его вручную. Для этого коннектимся к контейнеру ( docker exec -it jenkins-blueocean bash ), скачиваем бинарник по ссылке с официального сайта и помещаем его в /usr/bin. Далее надо зарегистрировать наш Helm-репозиторий:

Глобальные переменные среды

Так как у нас два сервиса, то мы создадим два пайплайна. Некоторые данные у них будут совпадать, поэтому логично вынести их в одно место. Это можно сделать, задав глобальные переменные среды, которые будут установлены перед выполнением любого билда на сервере Jenkins. Отмечу, что не стоит с помощью этого механизма передавать пароли — для этого существуют секреты.

Установим следующие глобальные переменные среды (Manage Jenkins -> Configure System -> Global properties -> Environment Variables):

• CLUSTER_URL — адрес мастер-ноды Kubernetes. Можно получить командой kubectl cluster-info
• CLUSTER_NAMESPACE — неймспейс нашего кластера
• HELM_PROJECT — имя инсталляции Helm
• HELM_CHART — имя Helm-чарта. В нашем случае это ‘msvc-repo/msvc-chart’

Секреты

В Jenkins для хранения конфиденциальной информации существуют секреты нескольких типов, например, связка логин-пароль, секретный текст, секретный файл и др. Установим следующие секреты через меню Credentials -> System -> Global credentials -> Add Credentials:

Имя секрета	Тип	Описание
github-creds	username with password	Логин/пароль от git-репозиториев
dockerhub-creds	username with password	Логин/пароль от реестра Docker-образов
kubernetes-creds	secret text	Токен сервисного аккаунта нашего кластера

В предыдущей части в файле NOTES.txt нашего чарта мы описали последовательность команд для получения токена сервисного аккаунта. Вывести эти команды для кластера можно, запросив статус Helm-инсталляции ( helm status msvc-project ).

Конфигурация пайплайна

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

В Jenkins процесс выполнения пайплайна (билд) поделен на ряд шагов (stage). Каждый шаг выполняется определенным агентом (agent).

Наши пайплайны будут состоять из следующих шагов:

1. Build. Компиляция проекта
2. Test. Выполнение тестов. В проекте у нас только модульные тесты, но с помощью Maven нетрудно сделать отдельный шаг и для интеграционных тестов
3. Package. Сборка jar-архива
4. Push Images. Создание Docker-образов и их загрузка в реестр образов. Мы будем пушить два образа — с тегом latest и конкретной версией
5. Trigger Kubernetes. Команда Kubernetes обновить Docker-образ в подах кластера

Структура файла конфигурации

Файл конфигурации будет иметь следующую структуру:

Агенты в Jenkins подчиняются типичным правилам «наследования» — если в шаге не определен агент, то будет использован агент родительского шага. Тег pipeline может рассматриваться как корневой шаг для всех остальных. Корневой шаг мы используем для объявления переменных среды и опций, которые по тому же правилу наследования будут иметь силу для всех вложенных шагов. Поэтому для тега pipeline установлен агент ‘none’. Использование этого агента подразумевает, что вложенные шаги обязаны переопределить этот агент для выполнения каких-либо полезных действий.

Шаги Build, Test и Package будут выполняться в отдельном Docker-контейнере для изоляции билдов друг от друга. Также использование Docker-образа избавляет нас от необходимости настраивать для наших сервисов Java 11 (Jenkins поставляется с Java 8). Для того чтобы выполнить эти шаги в едином контейнере, мы вложим их в шаг ‘Prepare container’ с агентом ‘docker’. В параметре args мы привяжем директорию .m2 в создаваемом контейнере к одноименной директории в контейнере Jenkins’а. В папке .m2 содержатся зависимости системы сборки Maven, которые будет переиспользоваться между билдами, что здорово сократит время выполнения.

Агент в шагах Push Images и Trigger Kubernetes равен ‘any’. Это значит, что шаг может быть выполнен на любом доступном агенте. В простейшем случае это означает выполнение в контейнере Jenkins’а. Также эти шаги будут выполнены только для коммитов в мастер-ветку ( when < branch 'master' >).

Далее мы более пристально посмотрим на каждый из шагов, а также на блоки options и environment.

Опции

Блок опций может быть использован для настройки выполнения пайплайна или же отдельного шага. Мы используем следующие опции:

skipStagesAfterUnstable заставит Jenkins сразу прервать билд, eсли тесты были провалены. Поведение по умолчанию предусматривает установку статуса билда в UNSTABLE и продолжение выполнения. Это позволяет в сложных случаях более гибко обрабатывать подобные ситуации.

skipDefaultCheckout отключает автоматический чекаут репозитория проекта. Дефолтно Jenkins делает force чекаут репозитория для каждого шага с собственным агентом (в нашем случае Prepare Checkout, Push images и Trigger Kubernetes). То есть по сути затирает все изменения. Это может быть полезно при использовании пайплайна с несколькими различными образами. Однако нам нажно получить исходники с репозитория только единожды — на шаге Build. Применив опцию skipDefaultCheckout, мы получаем возможность произвести чекаут вручную. Также стоит заметить, что Jenkins будет автоматически переносить артефакты между шагами. Так, например, скомпилированные исходники из шага Build будут полностью доступны в шаге Test.

Переменные среды

Переменные среды могут быть также объявлены как для всего пайплайна, так и для отдельного шага. Их можно использовать, чтобы вынести какие-то редкоизменяемый свойства. В этом блоке мы определим имя файла докера и имена создаваемых Docker-образов.

В предыдущих статьях при работе с кластером мы всегда использовали наиболее свежие latest образы, но напомню, что это не лучший вариант из-за проблем при откатах к предыдущим версиям. Поэтому мы предполагаем, что в начальный момент времени кластер создается из самых свежих образов, а потом уже будет обновляться на конкретную версию. Тег IMAGE_TAG будет зависеть только от номера билда, который можно получить из предустановленной глобальной переменной среды BUILD_NUMBER. Таким образом наши версии будут составлять монотонную последовательность при условии того, что пайплайн не будет пересоздаваться (это приведет к сбросу номера билда). При неуспешных билдах BUILD_NUMBER также будет инкрементирован, следовательно последовательность версий образов может содержать «пробелы». Основное преимущество такого подхода к версионированию — его простота и удобство восприятия человеком. В качестве альтернативы можно подумать об использовании метки времени, чексуммы коммита или даже внешних сервисов.

Компиляция, тестирование, сборка

Чисто технически фазы компиляции, тестирования и сборки возможно объединить в один шаг, но для лучшей наглядности мы опишем их как отдельные шаги. С помощью плагинов Maven можно с легкостью добавлять дополнительные фазы, такие как статический анализ кода или интеграционное тестирование.

На первом шаге мы выполняем чекаут репозитория проекта командой checkout scm . Адрес репозитория мы укажем после, при настройке пайплайна в Jenkins. Далее запускаем bash-команду на компиляцию проекта.

В фазе тестирования командой junit ‘**/target/surefire-reports/TEST-*.xml’ мы указываем Jenkins’у на файл с результатами тестов. Это позволит их отобразить прямо в веб-интерфейсе.

На последнем шаге мы генерируем jar-архив с нашим приложением.

Создание и отправка Docker-образа в реестр

На следующем шаге мы должны собрать Docker-образы и запушить их в реестр. Мы будем делать это средствами Jenkins, но в качестве альтернативы можно реализовать это и с помощью Maven-плагина.

Для начала нам надо доработать докер-файлы наших сервисов, которые мы разработали в первой статье цикла. Эти докер-файлы собирали приложение из исходников прямо в процессе создания образа. Сейчас же у нас имеется протестированный архив, следовательно один из шагов создания образа уже выполнен средствами Jenkins. Мы назовем этот новый файл Dockerfile-packaged.

Докер-файл для микросервиса шлюза аналогичен.

Шаг Push Images:

Изначально Jenkins поддерживал описание пайплайна только в императивном стиле, а поддержка декларативного подхода появилась намного позже. Разработчики Jenkins рекомендуют использовать именно декларативный подход как более выразительный, однако некоторые функции удобно вызывать внутри блока императивного кода командой script .

Командой docker.build мы собираем образ. Имя образа (уже включающее тег) может быть получено из переменных среды конструкцией $ . Во втором аргументе команды docker.build мы передаем опции для команды докера, а именно имя используемого докер-файла.

Команда docker.withRegistry(», ‘dockerhub-creds’) осуществляет подключение к реестру образов, используя данные из секрета ‘dockerhub-creds’. Внутри этого блока мы пушим образ дважды, во втором случае переопределяя тег на ‘latest’. Далее выводится диагностическое сообщение командой echo .

В конце шага происходит удаление установленных локально образов.

Обновление кластера Kubernetes

Финальным шагом осталось сообщить Kubernetes, что в реестре появился новый образ, и необходимо запустить процедуру обновления подов одного из микросервисов.

Команда withKubeConfig предоставляется плагином Kubernetes CLI и позволяет подключить kubectl к кластеру. После остается только прописать команду обновления свойств Helm-инсталляции. Также обращу внимание на использование предварительно объявленных глобальных переменных Jenkins, как, например, $ .

Итоговый Jenkinsfile

Jenkinsfile для микросервиса шлюза полностью аналогичен.

Подключение пайплайна

В Jenkins существует несколько видов пайплайнов. В данном проекте мы используем Multibranch pipeline. Как и следует из названия, билд будет запускаться для любого коммита в произвольной ветке.

После того как файлы конфигурации готовы, осталось настроить пайплайн в Jenkins. Это можно сделать в меню New Item -> Multibranch Pipeline. Интересующие нас разделы:

Branch sources. Выбираем GitHub, в графе ‘Credentials’ выбираем секрет с логином/паролем от аккаунта и указываем URL репозитория с исходным кодом микросервиса.

Build Configuration. В Mode выбираем ‘by Remote File Plugin’, основное поле — Repository URL, в котором надо указать адрес репозитория с Jenkinsfile, а также Script Path с путем к этому файлу.

Scan Repository Triggers. В этом разделе настроим период, с которым Jenkins будет проверять, появились ли какие-то изменения в отслеживаемом репозитории. Недостаток этого подхода в том, что Jenkins будет генерировать трафик, даже когда в репозитории ничего не менялось. Более грамотный подход — настроить веб-хуки. При этом хранилище исходного кода само будет инициировать запуск билда. Очевидно, что сделать это можно, только если Jenkins доступен по сети для хранилища исходных кодов (они должны быть либо в одной сети, либо Jenkins должен иметь публичный IP-адрес). Подключение веб-хуков оставим за рамками данной статьи.

Запуск

После того как наш пайплайн настроен, можно его запустить. Наиболее удобно это сделать из меню Blue Ocean (Open Blue Ocean). Первый запуск может занять продолжительное время, так как потребуется время на загрузку Maven-зависимостей. После выполнения билда можно подключиться к кластеру и убедиться в том, что тег образа микросервиса был изменен ( helm get values msvc-project ).

В дальнейшем Jenkins будет отслеживать изменения в репозитории микросервиса и запускать билд автоматически.

Заключение

Jenkins — очень гибкая система, позволяющая реализовывать процесс непрерывной интеграции и развертывания любой сложности. В этой статье мы только коснулись этого инструмента, создав простенький пайплайн для микросервисов нашего проекта. В будущем этот пайплайн можно значительно дорабатывать и улучшать, например, добавив уведомления, дополнительные шаги, веб-хуки и многое-многое другое.