Jenkins download and deployment

The Jenkins project produces two release lines: Stable (LTS) and regular (Weekly). Depending on your organization’s needs, one may be preferred over the other. See the links below for more information and recommendations about the release lines.

Stable (LTS)

Long-Term Support (LTS) release baselines are chosen every 12 weeks from the stream of regular releases. Every 4 weeks we release stable releases which include bug and security fix backports. Learn more…

Regular releases (Weekly)

This release line delivers bug fixes and new features rapidly to users and plugin developers who need them. It is generally delivered on a weekly cadence. Learn more…

Downloading Jenkins

Jenkins is distributed as WAR files, native packages, installers, and Docker images. Follow these installation steps:

1. Before downloading, please take a moment to review the Hardware and Software requirements section of the User Handbook.
2. Select one of the packages below and follow the download instructions.
3. Once a Jenkins package has been downloaded, proceed to the Installing Jenkins section of the User Handbook.
4. You may also want to verify the package you downloaded. Learn more about verifying Jenkins downloads.

Deploying Jenkins in public cloud

Many public cloud vendors provide their own Jenkins installation guides and packages. The guides provide instructions to deploy, maintain, and upgrade on the specific public cloud. Such guides may be used to quickly deploy Jenkins and, in many cases, to get an instance preconfigured to be used within the public cloud (e.g. bundled plugins, integrations with public cloud services, etc.).

Jenkins with AWS CodeBuild and AWS CodeDeploy

Jenkins quickstarts, tutorials, samples, and resources for Azure

Jenkins at scale on Google Kubernetes Engine

Jenkins easy and fast quickstart on IBM Cloud

Jenkins Reference Architecture and one-click deployment on Oracle Cloud Infrastructure

How to Install Jenkins on Windows

Learn how to install the popular continuous integration and delivery tool Jenkins on a Windows platform for DevOps.

Join the DZone community and get the full member experience.

Jenkins is one of the most popular tools for continuous integration and continuous delivery on any platform. A Java application, Jenkins has many plugins for automating almost everything at the infrastructure level. The use of Jenkins has widely increased rapidly due to a rich set of functionalities, which it provides in the form of plugins. In this tutorial, we will show a step by step guide on how to install Jenkins on a Windows platform.

Let’s get started.

First, you need to install JDK. Jenkins currently only supports JDK8. Once Java is running, you can install Jenkins. Click here to download the latest Jenkins package for Windows (currently it is version 2.130). Unzip the file to a folder and click on the Jenkins exe file.

Click «Next» to start the installation.

Click the «Change. « button if you want to install Jenkins in another folder. In this example I will keep the default option and click on the «Next» button.

Click the «Install» button to start the installation process.

The installation is processing.

When done, click the «Finish» button to complete the installation process.

You will automatically be redirected to a local Jenkins page, or you can paste the URL http://localhost:8080 in a browser.

To unlock Jenkins, copy the password from the file at C:\Program Files (x86)\Jenkins\secrets\initialAdminPassword and paste it in the Administratorpassword field. Then, click the «Continue» button.

You can install either the suggested plugins or selected plugins you choose. To keep it simple, we will install the suggested plugins.

Wait until the plugins are completely installed.

The next thing we should do is create an admin user for Jenkins. Put in your details and click «Save and Continue.»

Click «Save and Finish» to complete the Jenkins installation.

Now, click «Start using Jenkins» to start Jenkins.

Finally, here is the default Jenkins page.

Published at DZone with permission of Phi Nguyen , DZone MVB . See the original article here.

Opinions expressed by DZone contributors are their own.

Учимся разворачивать микросервисы. Часть 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 — очень гибкая система, позволяющая реализовывать процесс непрерывной интеграции и развертывания любой сложности. В этой статье мы только коснулись этого инструмента, создав простенький пайплайн для микросервисов нашего проекта. В будущем этот пайплайн можно значительно дорабатывать и улучшать, например, добавив уведомления, дополнительные шаги, веб-хуки и многое-многое другое.