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

В новой статье рассмотрим основы CI/CD и познакомимся Jenkins. Вы узнаете, где применяется Jenkins и какие проблемы помогает решить, поймёте логику архитектурных решений и особенности структуры каталогов. А ещё научитесь устанавливать Jenkins и производить базовую конфигурацию.

За основу статьи взят первый урок нашего практического курса «CI/CD с Jenkins».

CI/CD: что это такое и зачем нужно

Скорость разработки продуктов — одно из главных конкурентных преимуществ в разработке ПО. Поэтому на смену старым моделям программирования пришла новая концепция CI/CD.

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

CD, (Continuous Delivery) — непрерывная поставка. На этой стадии происходит автоматическое развертывание на стенды и тестовые окружения. Ещё CD расшифровывают как Continuous Deployment — непрерывное развёртывание. Это более продвинутый путь, на шаг дольше, чем непрерывная поставка. При таком подходе каждое изменение, которое мы коммитим в основную ветку репозитория, автоматически проходит все этапы CI и CD и затем попадает на продакшн.

Continuous Deployment Pipeline — высший пилотаж, который редко встречается на практике, потому что всегда есть определённые ограничения. Эти ограничения могут быть как в самом пайплайне, так и в бизнес-процессах с точки зрения безопасности. Но, однозначно, Continuous Deployment Pipeline — то, к чему нужно стремиться.

Цели CI/CD:

• обеспечение последовательного и автоматизированного способа сборки, упаковки и тестирования;

• автоматизация развёртывания в разных окружениях;

• сведение к минимуму ошибок и проблем. 

Добиться этих целей помогают четыре принципа, на которых основана концепция CI/CD. Первый принцип — разделение активности. Каждый из участников процесса делит ответственность за жизненные циклы продукта. Проектируется бизнес-логика, выбираются сквозные функции, проводятся тесты, организуется доставка кода из одного окружения в другое.

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

Третий принцип — сокращение цикла обратной связи. В рамках CI/CD мы стремимся увеличить скорость внесения изменений и согласования правок. 

Четвертый принцип — реализация среды. У разработчиков должно быть общее пространство для работы с основной веткой или со вспомогательными ветками. Это пространство должно быть отказоустойчивым и удобным для работы. 

Основные этапы CI/CD выглядят так:

Планирование основывается на пользовательском опыте и бизнес-функционале. Обычно за этот этап отвечают люди из анализа: они переводят требования с языка бизнеса на язык, понятный разработчикам и администраторам. Затем начинается этап работы с кодом — разработчики пишут код, проводят тестирования в ручном режиме и добавляют изменения в основную ветку репозитория. 

После того, как изменения попадают в репозиторий, система контроля версии инициирует сборку и тестирование проекта. Тестирование может быть как ручным, так и автоматическим — зависит от того, как работает команда. Далее всё уходит сначала на релиз, а затем на развёртывание. На этапе развёртывания уже протестированная версия приложения отправляется на продакшн и становится доступна пользователям.

Когда продукт попадает к пользователям, мы продолжаем следить за ним — этап поддержки и мониторинга. Мы контролируем, как пользователь идёт по бизнес-процессу, корректно ли работают интеграции. Если на стадии мониторинга мы обнаруживаем ошибку, возвращаемся к самому началу — к планированию. Аналитики разбирают, что пошло не так и предлагают новое решение, разработчики пишут код, и снова начинается процесс сборки.

Как и у любой методологии, у CI/CD есть свои плюсы и минусы:

Реализовать принципы CI/CD, свести к минимуму ошибки интеграции, а также ускорить релизы и повысить их качество помогает Jenkins.

Что такое Jenkins

Jenkins – не просто инструмент CI/CD. Это Framework, потому что он:

• Гибок и расширяем. Jenkins — опенсорсный проект с множеством внешних расширений.

• Минимален из коробки. У Jenkins есть контроллер. Вы можете подключить к нему несколько слоев и уже на этом сетапе собрать минимальный пайплайн, который позволит автоматизировать работу по обновлению сервисов.

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

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

Слэйвы или агенты — это то, что непосредственно выполняет сами задания. 

Коротко их взаимодействие можно описать так: контроллер запускает задачу и говорит агенту выполнить её, агент выполняет задачу и возвращает результат контроллеру. Контроллер получает результат и сохраняет его в build-логе.

Установка Jenkins

Разберём, как установить Jenkins, как настроить параметры JVM и почему это важно. Дополнительно познакомимся с Jenkins Home: что это за зверь и с чем его едят. Все действия будем выполнять на Ubuntu.

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

root@vs01:~# java --version

По умолчанию из коробки Java нет:

Рекомендуется использовать Java 11, потому что у неё более продвинутый Garbage Collector. Поставим её:

root@vs01:~# apt install openjdk-11-jre-headless

Проверим, что Java установилась:

root@vs01:~# java --version

Теперь нужно сконфигурировать файл limit.com. Но в Linux всё — файл, поэтому нужно установить фан-лимит, чтобы снять ограничения и позволить Jenkins генерировать файлы, дампы и др. Если не сделать этого, в каких-то случаях мы не сможем получить данные и понять, что же с Jenkins пошло не так.

Редактируем лимиты на Ubuntu:

root@vs01:~# vi/etс/security/limits.conf

И добавляем секцию управления и устанавливаем права на различные лимиты: хардовые, софтовые, size-файлы и др:

Дальше нужно установить фаервол на Ubuntu:

root@vs01:~# apt-get install ufw

Обязательно разрешаем OpenSSH-порт, потому что больше не сможем подключиться к этой машине:

root@vs01:~# ufw allow OpenSSH

8080 — порт, по которому работает Jenkins. 

root@vs01:~# ufw allow 8080

Проверяем Jenkins репозиторий, потому что по умолчанию его нет в стоке Ubuntu:

root@vs01:~# wget -q -o – http://pkg.jenkins.io/Debian-stable/jenjins.io.key|sudo gpg --dearmor -o /usr/share/keyrings/Jenkins.gpg

После того, как скопировали ключи, устанавливаем Jenkins в sources list:

Важно для Ubuntu делать apt-get update:

root@vs01:~# apt-get update -y

Теперь можем поставить Jenkins:

root@vs01:~# apt-get install Jenkins -y

Установка проходит довольно быстро. Если посмотреть верхнеуровнево, то Jenkins — это war-файл. И вы можете не устанавливать его в систему через system, а просто скачать war-файл и запускать через war.

Мы можем посмотреть статус Jenkins App:

root@vs01:~# systemctl status jenkins

Он активный, но нам этого недостаточно. Jenkins — это Java, а Java очень требовательно относится к памяти. Поэтому дальше поговорим про Garbage Collector — службу, которая очищает память от неиспользованных объектов. 

Мы немного «подтюним» Java-машину и добавим опции в файл etc systemd/system/jenkins.service:

root@vs01:~# vi /lib/systemd/system/Jenkins.service

Найдём Java OPTS:

Добавим больше опций: 

Обратите внимание, что в настройках мы указываем Xmx512m и Xms512 — размер оперативной памяти, который выделяем Java-машине для работы. Вообще размер зависит от количества доступной памяти в операционной системе и корректируется в соответствии с ней. По рекомендациям Cloud Business и личному опыту, нужно ставить не больше 16 гигабайт на hip size. Но при этом важно не забывать, что у вас есть Meta Space и система, которые тоже занимают память. Если у вас на машине 20 гигабайт памяти, смело можно ставить 16. Если у вас всего 18 гигабайт памяти, и вы выделяете 16 гигабайт под Jenkins и Java, не удивляйтесь, когда машина начнёт работать плохо, а в какой-то момент просто умрёт. 

Здесь выставляем Garbage Collector — UseG1GC:

И добавляем снятие автоматического дампа при out of memory:

Это полезная опция, когда Jenkins падает. Конечно, падения все равно будут случаться — мы не всегда можем рассчитать нагрузку и определить, сколько потребуется памяти для работы. Но параметр поможет понять, что произошло. 

Также в Garbage Collector выставляем лог — /var/lib/jenkins/gc.log:

Сохраняем.

Нужно перезагрузить Jenkins, но перед этим сделать daemon-reload:

root@vs01:~# systemctl daemon-reload
root@vs01:~# systemctl restart Jenkins

Проверим:

root@vs01:~# systemctl status Jenkins

oot@vs01:~# cat /proc/http://Jenkins.s043218.edu.slurm.io^C
root@vs01:~# cat /proc/67043/cmdline

Видим, что Java настроена как раз под те опции, что мы ей передали, и запускается Jenkins war:

Теперь откроем веб-интерфейс http://jenkins.s043218.edu.slurm.io. Он предлагает разблокировать Jenkins:

То есть первоначальная установка предполагает, что вы введете некий мастер-пароль. Jenkins сам подсказывает, где этот мастер-пароль можно найти — var/lib/jenkins/secret/initialAdminPassword. Давайте пойдём туда и посмотрим:

root@vs01:~# cd var/lib/jenkins/

root@vs01:/var/lib/jenkins/# cd secrets/
root@vs01:/var/lib/jenkins/secrets# ls -al

Initial password — пароль, который вы можете использовать один раз при первой установке Jenkins. После вы переключитесь на внутреннюю базу авторизации.

Следующий шаг — установить Suggested-плагины или самостоятельно выбрать плагины, которые хотите поставить. 

Список плагинов, которые используются в Suggested, достаточно правильный, поэтому рекомендуется просто поставить эти плагины автоматом. 

А пока Jenkins делает плагины, посмотрим на Home-директорию:

root@vs01:/var/lib/jenkins/secrets# cd ..
root@vs01:/var/lib/jenkins# ls -la

У Jenkins нет выделенной базы, как у некоторых систем. В качестве базы данных он использует директорию Jenkins Home, которая есть в каталоге файловой системы того сервера, на который выставили контролер. Здесь хранятся: конфиги, плагины, задания, которые мы делаем и всё, что связано с ними и т.д.

Вернёмся к Jenkins — он уже поставил домен и предлагает нам настроить первого пользователя. Заполним поля:

Далее Jenkins предлагает настроить URL:

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

Итак, мы поставили Jenkins. Пока нет никаких заданий, но мы можем немного пройтись по Manage Jenkins:

Из наиболее интересного здесь:

• System information — хранит всю основную информацию (Java Home, версия Java, версия Ubuntu и т.д.). 

• System log — то, куда нужно смотреть, если непонятно, почему не подключается агент или не работает скрип. 

• Load statistics — показывает, сколько экзекьюторов всего онлайн.

На этом всё. В рамках первого урока мы повторили цели CI/CD, узнали, что такое Jenkins и рассмотрели область его применения. Ещё попробовали самостоятельно установить Jenkins на Ubuntu-сервер и познакомились с содержимым Jenkins Home. В следующих уроках подробно разберём администрирование Jenkins, научимся настраивать интеграции, создавать конфигурации Jenkins As a Code и многое другое. 

Дженкинс – Обзор

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

Наряду с Дженкинсом иногда можно увидеть ассоциацию Гудзона . Hudson – это очень популярный инструмент непрерывной интеграции на основе Java с открытым исходным кодом, разработанный Sun Microsystems, который впоследствии был приобретен Oracle. После приобретения Sun компанией Oracle была создана форк из исходного кода Hudson, что привело к появлению Jenkins.

Что такое непрерывная интеграция?

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

Системные Требования

JDK	JDK 1,5 или выше
объем памяти	2 ГБ ОЗУ (рекомендуется)
Дисковое пространство	Нет минимальных требований. Обратите внимание, что, поскольку все сборки будут храниться на машинах Jenkins, необходимо убедиться, что для хранения сборок доступно достаточно места на диске.
Версия операционной системы	Jenkins может быть установлен на Windows, Ubuntu / Debian, Red Hat / Fedora / CentOS, Mac OS X, openSUSE, FReeBSD, OpenBSD, Gentoo.
Контейнер Java	Файл WAR можно запустить в любом контейнере, который поддерживает Servlet 2.4 / JSP 2.0 или более позднюю версию (например, Tomcat 5).

Дженкинс – Установка

Скачать Дженкинс

Официальный сайт Дженкинса – Дженкинс . Если вы нажмете указанную ссылку, вы сможете получить домашнюю страницу официального сайта Jenkins, как показано ниже.

По умолчанию последняя версия и версия долгосрочной поддержки будут доступны для загрузки. Предыдущие выпуски также доступны для скачивания. Перейдите на вкладку «Долгосрочная поддержка» в разделе загрузки.

Нажмите на ссылку «Старая, но стабильная версия», чтобы загрузить файл войны Дженкинса.

Начиная Дженкинс

Откройте командную строку. В командной строке перейдите в каталог, где находится файл jenkins.war. Запустите следующую команду

D:>Java –jar Jenkins.war

После запуска команды будут выполняться различные задачи, одной из которых является извлечение файла war, который выполняется встроенным веб-сервером winstone.

D:>Java –jar Jenkins.war
Running from: D:jenkins.war
Webroot: $user.home/ .jenkins
Sep 29, 2015 4:10:46 PM winstone.Logger logInternal
INFO: Beginning extraction from war file

Как только обработка завершится без существенных ошибок, в строке командной строки появится следующая строка.

INFO: Jenkins is fully up and running

Доступ к Дженкинс

После запуска Jenkins можно получить доступ к Jenkins по ссылке – http: // localhost: 8080.

Эта ссылка откроет панель управления Jenkins.

Jenkins – Настройка Tomcat

Следующие предварительные условия должны быть выполнены для установки Jenkins Tomcat.

Шаг 1. Проверка установки Java

Чтобы проверить установку Java, откройте консоль и выполните следующую команду Java.

Операционные системы	задача	команда
Windows	Открыть командную консоль	> Java-версия
Linux	Открыть командный терминал	$ java – версия

Если Java правильно установлена ​​в вашей системе, вы должны получить один из следующих выводов, в зависимости от платформы, на которой вы работаете.

Операционные системы	Выход
Windows	Java версия “1.7.0_60” Среда выполнения Java (TM) SE (сборка 1.7.0_60-b19) 64-разрядная серверная виртуальная машина Java Hotspot (TM) (сборка 24.60-b09, смешанный режим)
Linux	Java-версия “1.7.0_25” Открытая среда выполнения JDK (rhel-2.3.10.4.el6_4-x86_64) Откройте виртуальную машину 64-разрядного сервера JDK (сборка 23.7-b01, смешанный режим)

Java версия “1.7.0_60”

Среда выполнения Java (TM) SE (сборка 1.7.0_60-b19)

64-разрядная серверная виртуальная машина Java Hotspot (TM) (сборка 24.60-b09, смешанный режим)

Java-версия “1.7.0_25”

Открытая среда выполнения JDK (rhel-2.3.10.4.el6_4-x86_64)

Откройте виртуальную машину 64-разрядного сервера JDK (сборка 23.7-b01, смешанный режим)

Мы предполагаем, что читатели этого учебного пособия установили Java 1.7.0_60 в своей системе, прежде чем приступить к этому учебному пособию.

Если у вас нет Java JDK, вы можете скачать его по ссылке Oracle

Шаг 2. Проверка установки Java

Установите переменную среды JAVA_HOME, чтобы она указывала на местоположение базовой директории, где установлена ​​Java на вашем компьютере. Например,

Операционные системы	Выход
Windows	Установите переменную среды JAVA_HOME в C: ProgramFiles java jdk1.7.0_60
Linux	экспорт JAVA_HOME = / usr / local / java-current

Добавьте полный путь расположения компилятора Java к системному пути.

Операционные системы	Выход
Windows	Добавить строку; C: Program Files Java jdk1.7.0_60 bin до конца системной переменной PATH.
Linux	экспорт PATH = $ PATH: $ JAVA_HOME / bin /

Проверьте команду java-version из командной строки, как описано выше.

Шаг 3: Загрузите Tomcat

Официальный сайт Tomcat – Tomcat . Если вы нажмете указанную ссылку, вы сможете получить домашнюю страницу официального сайта tomcat, как показано ниже.

Перейдите по ссылке https://tomcat.apache.org/download-70.cgi, чтобы получить загрузку для tomcat.

Перейдите в раздел «Двоичные распределения». Загрузите 32-битный zip-файл Windows.

Затем распакуйте содержимое загруженного zip-файла.

Шаг 4: Настройка Jenkins и Tomcat

Скопируйте файл Jenkis.war, который был загружен из предыдущего раздела, и скопируйте его в папку webapps в папке tomcat.

Теперь откройте командную строку. В командной строке перейдите в каталог, где находится папка tomcat7. Перейдите в каталог bin в этой папке и запустите файл start.bat.

E:Appstomcat7bin>startup.bat

Как только обработка завершится без существенных ошибок, в строке командной строки появится следующая строка.

INFO: Server startup in 1302 ms

Откройте браузер и перейдите по ссылке – http: // localhost: 8080 / jenkins . Дженкинс будет работать на кота.

Jenkins – Git Setup

В этом упражнении вы должны убедиться в наличии подключения к Интернету на компьютере, на котором установлен Jenkins. На панели инструментов Jenkins (домашний экран) выберите опцию Manage Jenkins с левой стороны.

На следующем экране выберите «Управление плагинами».

На следующем экране перейдите на вкладку Доступно. Эта вкладка предоставит список плагинов, которые доступны для скачивания. На вкладке «Фильтр» введите «Плагин Git»

Список будет затем отфильтрован. Отметьте опцию Git Plugin и нажмите кнопку «Установить без перезагрузки»

Затем начнется установка, и экран обновится, чтобы показать состояние загрузки.

После завершения всех установок перезапустите Jenkins, выполнив в браузере следующую команду. HTTP: // локальный: 8080 / Jenkins / перезагрузка

После перезапуска Jenkins Git будет доступен в качестве опции при настройке заданий. Чтобы проверить, нажмите New Item в опциях меню для Jenkins. Затем введите имя для работы, в следующем случае введенное имя будет «Демо». Выберите «Фристайл проект» в качестве типа элемента. Нажмите кнопку ОК.

На следующем экране, если вы перейдете в раздел «Управление исходным кодом», теперь вы увидите «Git» в качестве опции.

Jenkins – Maven Setup

Шаг 1: Загрузка и настройка Maven

Официальный сайт Maven – Apache Maven . Если вы нажмете указанную ссылку, вы сможете получить домашнюю страницу официального сайта maven, как показано ниже.

При просмотре сайта перейдите в раздел «Файлы» и загрузите ссылку на файл Binary.zip.

Как только файл загружен, распакуйте файлы в соответствующую папку приложения. Для этого файлы maven будут помещены в E: Apps apache-maven-3.3.3.

Шаг 2: Настройка Jenkins и Maven

На панели управления Jenkins (домашний экран) выберите «Управление Jenkins» в меню слева.

Затем нажмите «Настроить систему» ​​с правой стороны.

На экране настройки системы прокрутите вниз, пока не увидите раздел Maven, а затем нажмите кнопку «Добавить Maven».

Снимите флажок «Установить автоматически».

Добавьте любое имя для настройки и расположение MAVEN_HOME.

Затем нажмите кнопку «Сохранить» в конце экрана.

Теперь вы можете создать работу с опцией «Проект Maven». На панели инструментов Jenkins выберите параметр «Новый элемент».

Дженкинс – Конфигурация

Вы, вероятно, видели пару раз в предыдущих упражнениях, где нам приходилось настраивать параметры в Jenkins. Ниже показаны различные параметры конфигурации в Jenkins.

Таким образом, можно получить различные параметры конфигурации для Jenkins, щелкнув параметр «Управление Jenkins» в левой части меню.

Затем вам будет представлен следующий экран –

Нажмите на Настроить систему. Ниже обсуждаются некоторые параметры конфигурации Jenkins, которые можно выполнить.

Домашний каталог Дженкинс

Дженкинсу нужно немного дискового пространства для сборки и хранения архивов. Проверить это местоположение можно с экрана конфигурации Jenkins. По умолчанию это значение равно ~ / .jenkins, и это местоположение будет изначально сохранено в вашем профиле пользователя. В правильной среде вам нужно изменить это местоположение на подходящее место для хранения всех соответствующих сборок и архивов. Один раз можете сделать это следующими способами

• Установите переменную среды “JENKINS_HOME” в новый домашний каталог перед запуском контейнера сервлета.

• Установите системное свойство “JENKINS_HOME” для контейнера сервлета.

• Установите запись среды JNDI “JENKINS_HOME” в новый каталог.

Установите переменную среды “JENKINS_HOME” в новый домашний каталог перед запуском контейнера сервлета.

Установите системное свойство “JENKINS_HOME” для контейнера сервлета.

Установите запись среды JNDI “JENKINS_HOME” в новый каталог.

В следующем примере будет использоваться первая опция установки переменной среды «JENKINS_HOME».

Сначала создайте новую папку E: Apps Jenkins. Скопируйте все содержимое из существующего ~ / .jenkins в этот новый каталог.

Установите переменную среды JENKINS_HOME, чтобы она указывала на местоположение базовой директории, где установлена ​​Java на вашем компьютере. Например,

Операционные системы	Выход
Windows	Установите переменную среды JENKINS_HOME, чтобы указать, в каком месте вы находитесь. В качестве примера вы можете установить его в E: Apps Jenkins
Linux	export JENKINS_HOME = / usr / local / Jenkins или желаемое место.

На приборной панели Jenkins выберите «Управление Jenkins» в левом меню. Затем нажмите «Настроить систему» ​​с правой стороны.

В домашнем каталоге вы увидите новый настроенный каталог.

# исполнителей

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

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

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

Дженкинс URL

По умолчанию URL-адрес Jenkins указывает на localhost. Если у вас есть настройка доменного имени для вашего компьютера, установите это имя домена, иначе перезапишите localhost с IP-адресом компьютера. Это поможет в настройке ведомых устройств и при отправке ссылок с использованием электронной почты, поскольку вы можете напрямую обращаться к URL-адресу Jenkins с помощью переменной среды JENKINS_URL, к которой можно получить доступ как $ {JENKINS_URL}.

Уведомление по электронной почте

В области уведомлений по электронной почте вы можете настроить параметры SMTP для отправки электронных писем. Это необходимо для подключения Jenkins к почтовому серверу SMTP и отправки электронных писем в список получателей.

Дженкинс – Управление

Чтобы управлять Jenkins, выберите опцию «Manage Jenkins» в левой части меню.

Таким образом, можно получить различные параметры конфигурации для Jenkins, щелкнув параметр «Управление Jenkins» в левой части меню.

Затем вам будет представлен следующий экран –

Некоторые из вариантов управления следующие:

Настроить систему

Здесь можно управлять путями к различным инструментам, используемым в сборках, таким как JDK, версии Ant и Maven, а также параметры безопасности, серверы электронной почты и другие сведения о конфигурации всей системы. Когда плагины установлены. Jenkins добавит необходимые поля конфигурации динамически после установки плагинов.

Перезагрузить конфигурацию с диска

Jenkins хранит всю свою информацию о конфигурации системы и сборки в виде XML-файлов, которые хранятся в домашнем каталоге Jenkins. Здесь также хранится вся история сборки. Если вы переносите задания сборки из одного экземпляра Jenkins в другой или архивируете старые задания сборки, вам необходимо добавить или удалить соответствующие каталоги заданий сборки в каталог сборки Jenkins. Вам не нужно переводить Jenkins в автономный режим, чтобы сделать это – вы можете просто использовать опцию «Перезагрузить конфигурацию с диска», чтобы перезагрузить систему Jenkins и напрямую создать конфигурации заданий.

Управление плагином

Здесь можно установить самые разнообразные сторонние плагины прямо от различных инструментов управления исходным кодом, таких как Git, Mercurial или ClearCase, до отчетов о качестве кода и показателях покрытия кода. Плагины можно устанавливать, обновлять и удалять с помощью экрана «Управление плагинами».

Системная информация

На этом экране отображается список всех текущих системных свойств Java и системных переменных среды. Здесь можно точно проверить, в какой версии Java Jenkins работает, под каким пользователем он работает, и так далее.

На следующем снимке экрана показана некоторая информация о значении имени, доступная в этом разделе.

Системный журнал

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

Загрузить статистику

На этих страницах отображаются графические данные о том, насколько занят экземпляр Jenkins, с точки зрения количества одновременных сборок и длины очереди сборки, что дает представление о том, как долго ваши сборки должны ждать перед выполнением. Эта статистика может дать хорошее представление о том, требуются ли дополнительные ресурсы или дополнительные узлы сборки с точки зрения инфраструктуры.

Консоль скриптов

Этот экран позволяет запускать скрипты Groovy на сервере. Это полезно для расширенного поиска и устранения неисправностей, поскольку требует глубоких знаний внутренней архитектуры Jenkins.

Управление узлами

Дженкинс способен обрабатывать параллельные и распределенные сборки. На этом экране вы можете настроить, сколько сборок вы хотите. Jenkins запускается одновременно, и, если вы используете распределенные сборки, настройте узлы сборки. Узел сборки – это еще одна машина, которую Jenkins может использовать для выполнения своих сборок.

Подготовьтесь к выключению

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

Дженкинс – Настройка сборки

Для этого упражнения мы создадим задание в Jenkins, которое подберет простое приложение HelloWorld, соберет и запустит Java-программу.

Шаг 1 – Перейдите на панель инструментов Jenkins и нажмите на новый элемент

Шаг 2 – На следующем экране введите имя элемента, в данном случае мы назвали его Helloworld. Выберите «Фристайл проект»

Шаг 3 – появится следующий экран, в котором вы можете указать детали работы.

Шаг 4 – Нам нужно указать расположение файлов, которые нужно собрать. В этом примере мы будем предполагать, что был настроен локальный репозиторий git (E: Program), который содержит файл «HelloWorld.java». Поэтому прокрутите вниз и нажмите на опцию Git и введите URL-адрес локального репозитория git.

Примечание. Если вы размещаете репозиторий на Github, вы также можете ввести здесь URL этого репозитория. В дополнение к этому вам нужно будет нажать кнопку «Добавить» для ввода учетных данных, чтобы добавить имя пользователя и пароль в репозиторий github, чтобы код можно было получить из удаленного репозитория.

Шаг 5 – Теперь перейдите в раздел «Сборка» и нажмите «Добавить шаг сборки» → «Выполнить пакетную команду Windows».

Шаг 6 – В окне команд введите следующие команды и нажмите кнопку Сохранить.

Javac HelloWorld.java
Java HelloWorld

Шаг 7 – После сохранения вы можете нажать на опцию Build Now, чтобы увидеть, успешно ли вы определили задание.

Шаг 8 – Как только сборка запланирована, она запустится. Следующий раздел истории сборки показывает, что сборка выполняется.

Шаг 9 – Как только сборка завершена, статус сборки покажет, была ли сборка успешной или нет. В нашем случае следующая сборка была выполнена успешно. Нажмите на # 1 в истории сборки, чтобы открыть детали сборки.

Шаг 10 – Нажмите на ссылку Console Output, чтобы увидеть детали сборки

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

Дженкинс – Модульное тестирование

Jenkins предоставляет готовую функциональность для Junit и предоставляет множество плагинов для модульного тестирования для других технологий, например MSTest для модульных тестов .Net. Если вы перейдете по ссылке https://wiki.jenkins-ci.org/display/JENKINS/xUnit+Plugin, она предоставит список доступных плагинов для модульного тестирования.

Пример теста Junit в Дженкинсе

В следующем примере рассмотрим

• Простой класс HelloWorldTest, основанный на Junit.
• Ant как инструмент для сборки внутри Jenkins для соответствующей сборки класса.

Шаг 1 – Перейдите на панель инструментов Jenkins и нажмите на существующий проект HelloWorld и выберите опцию Configure.

Шаг 2 – Перейдите в раздел, чтобы добавить шаг сборки и выберите опцию Invoke Ant.

Шаг 3 – Нажмите на кнопку «Дополнительно».

Шаг 4 – В разделе файла сборки введите местоположение файла build.xml.

Шаг 5 – Затем нажмите опцию Добавить опцию после сборки и выберите опцию «Опубликовать отчет о результатах теста Junit»

Шаг 6 – В XML-файлах отчетов о тестировании введите местоположение, как показано ниже. Убедитесь, что отчеты – это папка, созданная в рабочей области проекта HelloWorld. «* .Xml» в основном говорит Дженкинсу забрать результирующие XML-файлы, которые создаются при выполнении тестовых случаев Junit. Эти XML-файлы, которые затем преобразуются в отчеты, которые можно просмотреть позже.

После этого нажмите кнопку Сохранить в конце.

Шаг 7 – После сохранения вы можете нажать на опцию Build Now.

Как только сборка будет завершена, статус сборки покажет, была ли сборка успешной или нет. В выходных данных Build вы теперь заметите дополнительный раздел под названием Test Result. В нашем случае мы ввели отрицательный контрольный пример, чтобы результат не удался, просто в качестве примера.

Можно перейти к выходу консоли, чтобы увидеть дополнительную информацию. Но что более интересно, если вы нажмете на «Результат теста», вы увидите развернутые результаты теста.

Дженкинс – Автоматизированное тестирование

Одним из основных принципов непрерывной интеграции является то, что сборка должна быть проверяемой. Вы должны быть в состоянии объективно определить, готова ли конкретная сборка перейти к следующему этапу процесса сборки, и наиболее удобный способ сделать это – использовать автоматизированные тесты. Без надлежащего автоматического тестирования вы обнаружите, что вам нужно сохранить множество артефактов сборки и проверить их вручную, что вряд ли соответствует духу непрерывной интеграции. В следующем примере показано, как использовать Selenium для запуска автоматических веб-тестов.

Шаг 1 – Перейти к управлению плагинами.

Шаг 2 – Найдите плагин Hudson Selenium и выберите установку. Перезапустите экземпляр Jenkins.

Шаг 3 – Перейти к настройке системы.

Шаг 4 – Сконфигурируйте jar сервера selenium и нажмите кнопку Сохранить.

Примечание . Файл селеновой банки можно загрузить с сайта SeleniumHQ.

Нажмите на загрузку для автономного сервера Selenium.

Шаг 5 – Вернитесь на свою панель инструментов и нажмите на опцию Configure для проекта HelloWorld.

Шаг 6 – Нажмите «Добавить сборку» и выберите опцию «SeleniumHQ htmlSuite Run»

Шаг 7 – Добавьте необходимые детали для теста на селен. Здесь suiteFile – это TestSuite, созданный с помощью IDE Selenium. Нажмите Сохранить и выполнить сборку. Теперь посткомпиляция запустит драйвер селена и выполнит тест html.

Дженкинс – Уведомление

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

Шаг 1 – Настройка SMTP-сервера. Перейти к Управлению Jenkins → Настроить систему. Перейдите в раздел уведомлений по электронной почте и введите требуемый SMTP-сервер и сведения о суффиксе электронной почты пользователя.

Шаг 2. Настройка получателей в проекте Jenkins. При настройке любого проекта сборки Jenkins в самом конце появляется возможность добавить получателей, которые будут получать уведомления по электронной почте о нестабильных или поврежденных сборках. Затем нажмите на кнопку Сохранить.

Помимо стандартного, на рынке есть также плагин уведомлений. Примером является плагин уведомлений от Tikal Knowledge, который позволяет отправлять уведомления о статусе работы в форматах JSON и XML. Этот плагин позволяет настраивать конечные точки, как показано ниже.

Вот детали каждого варианта –

• «Формат» – это формат содержимого уведомления, который может быть либо JSON, либо XML.

• «Протокол» – протокол, используемый для отправки уведомлений, HTTP, TCP или UDP.

• «Событие» – события задания, которые вызывают уведомления: задание запущено, задание завершено, задание завершено или все события (опция по умолчанию).

• «URL» – URL для отправки уведомлений. Он принимает форму « http: // host » для протокола HTTP и "host:port" для протоколов TCP и UDP.

• «Тайм-аут» – Тайм-аут в миллисекундах для отправки запроса уведомления, по умолчанию 30 секунд.

«Формат» – это формат содержимого уведомления, который может быть либо JSON, либо XML.

«Протокол» – протокол, используемый для отправки уведомлений, HTTP, TCP или UDP.

«Событие» – события задания, которые вызывают уведомления: задание запущено, задание завершено, задание завершено или все события (опция по умолчанию).

«URL» – URL для отправки уведомлений. Он принимает форму « http: // host » для протокола HTTP и "host:port" для протоколов TCP и UDP.

«Тайм-аут» – Тайм-аут в миллисекундах для отправки запроса уведомления, по умолчанию 30 секунд.

Дженкинс – Отчетность

Как показано в предыдущем разделе, существует множество плагинов для отчетов, самым простым из которых являются отчеты, доступные для тестов jUnit.

В действии Post-build для любого задания вы можете определить отчеты, которые будут созданы. После завершения сборок опция «Результаты теста» будет доступна для дальнейшей детализации.

Дженкинс – Анализ кода

Дженкинс имеет множество плагинов для анализа кода. Различные плагины можно найти по адресу https://wiki.jenkins-ci.org/display/JENKINS/Static+Code+Analysis+Plugins.

Этот плагин предоставляет утилиты для плагинов статического анализа кода. Jenkins может анализировать файл результатов с помощью различных инструментов анализа кода, таких как CheckStyle, FindBugs, PMD и т. Д. Для каждого соответствующего инструмента анализа кода необходимо установить плагин в Jenkins.

Кроме того, доступен дополнительный плагин Static Analysis Collector, который объединяет отдельные результаты этих плагинов в единый график и представление тренда.

Плагины могут предоставить такую ​​информацию, как

• Общее количество предупреждений в работе
• Показ новых и исправленных предупреждений о сборке
• Отчеты о тенденциях, показывающие количество предупреждений на одну сборку
• Обзор найденных предупреждений для модуля, пакета, категории или типа
• Подробные отчеты о найденных предупреждениях, необязательно отфильтрованные по серьезности (или новые и исправленные)

Jenkins – Распределенные сборки

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

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

Подчиненный – это компьютер, который настроен на разгрузку проектов сборки с главного устройства, и после настройки это распределение задач выполняется довольно автоматически. Точное поведение делегирования зависит от конфигурации каждого проекта; некоторые проекты могут выбрать «придерживаться» определенной машины для сборки, в то время как другие могут свободно перемещаться между рабами.

Поскольку каждое ведомое устройство запускает отдельную программу, называемую «ведомым агентом», нет необходимости устанавливать полный Jenkins (пакет или скомпилированные двоичные файлы) на подчиненном устройстве. Существуют различные способы запуска подчиненных агентов, но, в конце концов, ведомому агенту и главному устройству Jenkins необходимо установить двунаправленный канал связи (например, сокет TCP / IP.) Для работы.

Чтобы настроить подчиненные узлы / узлы в Jenkins, выполните следующие действия.

Шаг 1 – Перейдите в раздел «Управление Jenkins» и прокрутите вниз до раздела «Управление узлами».

Шаг 2 – Нажмите на новый узел

Шаг 3 – Дайте имя для узла, выберите опцию Dumb slave и нажмите Ok.

Шаг 4 – Введите сведения о узле подчиненного компьютера. В приведенном ниже примере мы рассматриваем подчиненную машину как машину с Windows, поэтому в качестве метода запуска была выбрана опция «Разрешить Jenkins управлять этим подчиненным Windows как службой Windows». Нам также необходимо добавить необходимые данные о подчиненном узле, такие как имя узла и учетные данные для входа в систему для узла. Нажмите кнопку Сохранить. Метки, для которых имя вводится как «New_Slave», – это то, что можно использовать для настройки заданий на использование этого подчиненного компьютера.

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

Дженкинс – Автоматизированное развертывание

Существует множество доступных плагинов, которые можно использовать для передачи файлов сборки после успешной сборки на соответствующее приложение / веб-сервер. Например, «Плагин для развертывания в контейнере». Чтобы использовать это, следуйте инструкциям ниже.

Шаг 1 – Перейдите в Управление Дженкинс → Управление плагинами. Перейдите в раздел «Доступные» и найдите плагин «Плагин для развертывания в контейнер» и установите плагин. Перезагрузите сервер Jenkins.

Этот плагин берет файл war / ear и развертывает его на работающем удаленном сервере приложений в конце сборки.

Tomcat 4.x / 5.x / 6.x / 7.x

JBoss 3.x / 4.x

Glassfish 2.x / 3.x

Шаг 2 – Перейдите к вашему проекту Build и выберите опцию Configure. Выберите опцию «Развернуть войну / ухо в контейнере»

Шаг 3 – В разделе «Развернуть war / ear to container» введите необходимые данные о сервере, на котором необходимо развернуть файлы, и нажмите кнопку «Сохранить». Эти шаги теперь обеспечат развертывание необходимых файлов в необходимом контейнере после успешной сборки.

Дженкинс – метрики и тенденции

В Jenkins есть различные плагины для демонстрации метрик для сборок, которые выполняются в течение определенного периода времени. Эти метрики полезны для понимания ваших сборок и того, как часто они терпят неудачу / проходят со временем. В качестве примера давайте рассмотрим плагин Build History Metrics.

Этот плагин рассчитывает следующие показатели для всех сборок после установки

• Среднее время до отказа (MTTF)
• Среднее время до восстановления (MTTR)
• Стандартное отклонение времени сборки

Шаг 1 – Перейдите на панель инструментов Jenkins и нажмите Manage Jenkins.

Шаг 2 – Перейдите к опции «Управление плагинами».

Шаг 3 – Перейдите на вкладку Доступно и найдите плагин «Плагин Build History Metrics» и выберите «Установить без перезапуска».

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

Когда вы перейдете на страницу «Работа», вы увидите таблицу с рассчитанными показателями. Метрики показаны за последние 7 дней, последние 30 дней и все время.

Чтобы увидеть общие тенденции в Jenkins, существуют плагины для сбора информации из сборок и Jenkins и отображения их в графическом формате. Одним из примеров такого плагина является плагин Hudson global-build-stats. Итак, давайте пройдемся по шагам для этого.

Шаг 1 – Перейдите на панель инструментов Jenkins и нажмите Manage Jenkins.

Шаг 2 – Перейдите к опции «Управление плагинами»

Шаг 3 – Перейдите на вкладку «Доступные» и найдите плагин «Hudson global-build-stats plugin» и выберите «установить без перезапуска».

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

Чтобы увидеть глобальную статистику, выполните шаги с 5 по 8.

Шаг 5 – Перейдите на панель инструментов Jenkins и нажмите Manage Jenkins. На экране «Управление Jenkins» прокрутите вниз, и теперь вы увидите опцию «Global Build Stats». Нажмите на эту ссылку.

Шаг 6 – Нажмите на кнопку «Инициализировать статистику». Что он делает, так это собирает все существующие записи для сборок, которые уже были выполнены, и диаграммы могут быть созданы на основе этих результатов.

Шаг 7 – После того, как данные были инициализированы, пришло время создать новую диаграмму. Нажмите на ссылку «Создать новый график».

Шаг 8 – Появится всплывающее окно для ввода соответствующей информации для новых деталей диаграммы. Введите следующую обязательную информацию

• Заголовок – Любая информация заголовка, для этого примера дана как «Демо»
• Ширина диаграммы – 800
• Высота диаграммы – 600
• Шкала времени графика – Ежедневно
• Продолжительность графика – 30 дней

Остальная информация может оставаться как есть. Как только информация введена, нажмите «Создать новый график».

Теперь вы увидите график, который отображает тренды сборок с течением времени.

Если вы щелкнете по любому из разделов диаграммы, вы получите подробную информацию о задании и его сборках.

Jenkins – Обслуживание сервера

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

Параметры URL

Следующие команды при добавлении к URL-адресу экземпляра Jenkins будут выполнять соответствующие действия с экземпляром Jenkins.

http: // localhost: 8080 / jenkins / exit – отключение jenkins

http: // localhost: 8080 / jenkins / restart – перезапустить jenkins

http: // localhost: 8080 / jenkins / reload – перезагрузить конфигурацию

Резервное копирование Jenkins Home

Домашний каталог Jenkins – это не что иное, как место на вашем диске, где Jenkins хранит всю информацию для заданий, сборок и т. Д. Расположение вашего домашнего каталога можно увидеть, нажав «Управление Jenkins» → «Настроить систему».

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

Другим лучшим методом является написание заданий cron или задач обслуживания, которые могут выполнять операции очистки, чтобы избежать переполнения диска, на котором настроен Jenkins.

Дженкинс – непрерывное развертывание

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

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

Доступны плагины, которые могут фактически дать вам графическое представление процесса непрерывного развертывания. Но сначала давайте создадим еще один проект в Jenkins, чтобы мы лучше видели, как это работает.

Давайте создадим простой проект, который эмулирует этап QA и выполняет тест приложения Helloworld.

Шаг 1 – Перейдите к приборной панели Дженкинса и нажмите «Новый предмет». Выберите «Фристайл проект» и введите название проекта как «QA». Нажмите на кнопку ОК, чтобы создать проект.

Шаг 2. В этом примере мы сохраняем простоту и просто используем этот проект для выполнения тестовой программы для приложения Helloworld.

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

Шаг 3 – Теперь перейдите к вашему проекту Helloworld и нажмите на опцию Configure

Шаг 4 – В конфигурации проекта выберите «Добавить действие после сборки» и выберите «Построить другие проекты»

Шаг 5 – В разделе «Проект для сборки» введите QA в качестве имени проекта для сборки. Вы можете оставить параметр по умолчанию «Триггер, только если сборка стабильна». Нажмите на кнопку Сохранить.

Шаг 6 – Создайте проект Helloworld. Теперь, если вы увидите выходные данные консоли, вы также увидите, что после успешной сборки проекта Helloworld также будет происходить сборка проекта QA.

Шаг 7 – Позвольте теперь установить плагин доставки конвейера. Перейдите в Управление Дженкинс → Управление плагином. На доступной вкладке найдите «Плагин конвейера доставки». Нажмите «Установить без перезагрузки». После этого перезапустите экземпляр Jenkins.

Шаг 8 – Чтобы увидеть конвейер доставки в действии, на панели управления Jenkins нажмите значок + на вкладке рядом с вкладкой «Все».

Шаг 9 – Введите любое имя для имени представления и выберите опцию «Представление конвейера доставки».

Шаг 10 – На следующем экране вы можете оставить параметры по умолчанию. Можно изменить следующие настройки –

• Убедитесь, что опция «Показать результаты статического анализа» отмечена.
• Убедитесь, что опция «Показать общее время сборки» отмечена.
• Для начальной работы – введите проект Helloworld в качестве первой работы, которую следует построить.
• Введите любое имя для конвейера
• Нажмите кнопку ОК.

Теперь вы увидите великолепный вид всего конвейера доставки и сможете увидеть состояние каждого проекта во всем конвейере.

Другой известный плагин – плагин сборки конвейера . Давайте посмотрим на это.

Шаг 1 – Перейдите в Управление Дженкинс → Управление плагином. На доступной вкладке найдите «Построить плагин конвейера». Нажмите «Установить без перезагрузки». После этого перезапустите экземпляр Jenkins.

Шаг 2 – Чтобы увидеть конвейер сборки в действии, на панели управления Jenkins нажмите значок + на вкладке рядом с вкладкой «Все».

Шаг 3 – Введите любое имя для имени представления и выберите опцию «Построить представление конвейера».

Шаг 4 – Примите настройки по умолчанию, просто в выбранном начальном задании убедитесь, что вы ввели имя проекта Helloworld. Нажмите на кнопку ОК.

Теперь вы увидите великолепный вид всего конвейера доставки и сможете увидеть состояние каждого проекта во всем конвейере.

Jenkins – Управление плагинами

Чтобы получить список всех плагинов, доступных в Jenkins, можно перейти по ссылке – https://wiki.jenkins-ci.org/display/JENKINS/Plugins

Мы уже видели много примеров установки плагинов, давайте посмотрим на некоторые другие задачи по обслуживанию в отношении плагинов

Удаление плагинов

Чтобы удалить плагин, выберите «Управление Jenkins» → «Управление плагинами». Нажмите на установленную вкладку. Некоторые из плагинов будут иметь опцию удаления. Вы можете нажать эти кнопки, чтобы удалить плагины. Обязательно перезапустите экземпляр Jenkins после удаления.

Установка другой версии плагина

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

Дженкинс – Безопасность

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

Чтобы настроить безопасность в Jenkins, выполните следующие действия.

Шаг 1 – Нажмите «Управление Jenkins» и выберите «Настроить глобальную безопасность».

Шаг 2 – Нажмите на опцию «Включить безопасность». В качестве примера, давайте предположим, что мы хотим, чтобы Jenkins поддерживал свою собственную базу данных пользователей, поэтому в области безопасности выберите вариант «собственная база данных пользователей Jenkins».

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

Шаг 3 – Вам будет предложено добавить вашего первого пользователя. В качестве примера, мы настраиваем администраторов для системы.

Шаг 4 – Настало время настроить ваших пользователей в системе. Теперь, когда вы перейдете к управлению Дженкинс и прокрутите вниз, вы увидите опцию «Управление пользователями». Нажмите эту опцию.

Шаг 5 – Так же, как вы определили своего администратора, начните создавать других пользователей для системы. В качестве примера, мы просто создаем другого пользователя с именем «пользователь».

Шаг 6 – Теперь пришло время настроить ваши полномочия, в основном у кого есть доступ к чему. Перейдите в раздел «Управление Jenkins» → «Настроить глобальную безопасность».

Теперь в разделе «Авторизация» нажмите «Безопасность на основе матрицы».

Шаг 7 – Если вы не видите пользователя в списке групп пользователей, введите имя пользователя и добавьте его в список. Затем дайте соответствующие разрешения пользователю.

Нажмите на кнопку Сохранить, как только вы определили соответствующие полномочия.

Ваша безопасность Jenkins теперь настроена.

Примечание. Для проверки подлинности Windows AD необходимо добавить плагин Active Directory для Jenkins.

Jenkins – Плагин резервного копирования

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

Шаг 1 – Нажмите «Управление Jenkins» и выберите «Управление плагинами».

Шаг 2 – На доступной вкладке найдите «Плагин резервного копирования». Нажмите «Установить без перезагрузки». После этого перезапустите экземпляр Jenkins.

Шаг 3 – Теперь, когда вы перейдете в Управление Jenkins и прокрутите вниз, вы увидите «Диспетчер резервного копирования» в качестве опции. Нажмите на эту опцию.

Шаг 4 – Нажмите на настройку.

Шаг 5 – Здесь основным полем для определения является каталог для вашей резервной копии. Убедитесь, что он находится на другом диске, отличном от диска, на котором настроен ваш экземпляр Jenkins. Нажмите на кнопку Сохранить.

Шаг 6 – Нажмите «Backup Hudson configuration» на экране диспетчера резервного копирования, чтобы начать резервное копирование.

На следующем экране будет показано состояние резервной копии

Чтобы восстановить резервную копию, перейдите на экран диспетчера резервных копий, нажмите «Восстановить конфигурацию Hudson».

Появится список резервных копий, нажмите на соответствующую, чтобы нажать Launch Restore, чтобы начать восстановление резервной копии.

Дженкинс – дистанционное тестирование

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

Шаг 1 – Убедитесь, что ваша конфигурация master-slave установлена. Зайдите на ваш главный сервер Jenkins. Перейдите в Управление Дженкинс → Управление узлами.

В нашем списке узлов метка DXBMEM30 является подчиненной машиной. В этом примере и главная, и подчиненная машины являются машинами Windows.

Шаг 2 – Нажмите на настройку для ведомой машины DXBMEM30.

Шаг 3 – Убедитесь, что метод запуска установлен как «Запуск подчиненных агентов через Java Web Start»

Шаг 4 – Теперь перейдите на свой подчиненный компьютер и оттуда откройте экземпляр браузера для своего главного экземпляра Jenkins. Затем перейдите в Управление Дженкинс → Управление узлами. Перейдите к DXBMEM30 и нажмите на

Шаг 5 – Нажмите на экземпляр DXBMEM30.

Шаг 6 – Прокрутите вниз, и вы увидите опцию Launch, которая является опцией Start ‘Java Web Start’

Шаг 7 – Вам будет представлено предупреждение безопасности. Установите флажок «Принять» и нажмите «Выполнить».

Теперь вы увидите окно подчиненного Дженкинса, открытое и теперь подключенное.

Шаг 8 – Настройка ваших тестов для работы на ведомом устройстве. Здесь вы должны убедиться, что создаваемое задание предназначено специально для запуска только тестов селена.

В конфигурации задания убедитесь, что выбран параметр «Ограничить, где можно запустить этот проект», и в выражении «Метка» введите имя подчиненного узла.

Шаг 9 – Убедитесь, что селеновая часть вашей работы настроена. Вы должны убедиться, что файл Sample.html и файл selenium-server.jar также присутствуют на подчиненном компьютере.

После того, как вы выполнили все вышеперечисленные шаги и нажали на Build, этот проект запустит тест Selenium на подчиненном компьютере, как и ожидалось.

Содержание

	Введение
	Запустить скрипт из репозитория
	Jenkins Docker Agent
	Автоматический запуск заданий
	Переменные окружения
	Credentials
	Сборщики проектов
	Статьи про Jenkins

Введение

Jenkins Docker Agent

Относительно новый способ создавать агентов — запускать их в Docker контейнерах. Для этого в Jenkins нужно добавить плагин Docker

Plugin Manager → Cloud Providers → Docker

Настройка происходит через

Manage Jenkins → Manage nodes and clouds → Configure Clouds

Настроим Docker сервер на отдельном

Ubuntu

хосте в локальной сети и затем вернёмся к настройке Jenkins

sudo vi /lib/systemd/system/docker.service

# ExecStart=/usr/bin/dockerd -H fd:// —containerd=/run/containerd/containerd.sock
ExecStart=/usr/bin/dockerd -H tcp://0.0.0.0:2375 -H unix:///var/run/docker.sock

sudo vi /lib/systemd/system/docker.service

sudo service docker status -l

● docker.service — Docker Application Container Engine
Loaded: loaded (/lib/systemd/system/docker.service; enabled; vendor preset: enabled)
Active: active (running) since Mon 2023-01-09 12:00:07 EET; 3min 47s ago
TriggeredBy: ● docker.socket
Docs: https://docs.docker.com
Main PID: 7709 (dockerd)
Tasks: 10
Memory: 29.9M
CPU: 862ms
CGroup: /system.slice/docker.service
└─7709 /usr/bin/dockerd -H tcp://0.0.0.0:2375 -H unix:///var/run/docker.sock

Apr 25 08:49:56 andrei-virtual-machine dockerd[7709]: time=»2023-01-09T12:00:05.488100986+02:00″ level=info msg=»ClientConn switching balancer to «pick_first»» module=grpc
Apr 25 08:49:56 andrei-virtual-machine dockerd[7709]: time=»2023-01-09T12:00:05.850772393+02:00″ level=info msg=»[graphdriver] using prior storage driver: overlay2″
Apr 25 08:49:56 andrei-virtual-machine dockerd[7709]: time=»2023-01-09T12:00:05.934673941+02:00″ level=info msg=»Loading containers: start.»
Apr 25 08:49:56 andrei-virtual-machine dockerd[7709]: time=»2023-01-09T12:00:06.450509708+02:00″ level=info msg=»Default bridge (docker0) is assigned with an IP address 172.17.0.0/16. Daemon option —bip can be used to set a preferred IP address»
Apr 25 08:49:56 andrei-virtual-machine dockerd[7709]: time=»2023-01-09T12:00:06.689935636+02:00″ level=info msg=»Loading containers: done.»
Apr 25 08:49:56 andrei-virtual-machine dockerd[7709]: time=»2023-01-09T12:00:06.990191356+02:00″ level=info msg=»Docker daemon» commit=20.10.12-0ubuntu4 graphdriver(s)=overlay2 version=20.10.12
Apr 25 08:49:56 andrei-virtual-machine dockerd[7709]: time=»2023-01-09T12:00:06.990408478+02:00″ level=info msg=»Daemon has completed initialization»
Apr 25 08:49:56 andrei-virtual-machine systemd[1]: Started Docker Application Container Engine.
Apr 25 08:49:56 andrei-virtual-machine dockerd[7709]: time=»2023-01-09T12:00:07.109669043+02:00″ level=info msg=»API listen on [::]:2375″
Apr 25 08:49:56 andrei-virtual-machine dockerd[7709]: time=»2023-01-09T12:00:07.122519364+02:00″ level=info msg=»API listen on /var/run/docker.sock»

Проверим, доступен ли Docker API с помощью

curl

curl http://localhost:2375/version

{«Platform»:{«Name»:»»},»Components»:[{«Name»:»Engine»,»Version»:»20.10.12″,»Details»:{«ApiVersion»:»1.41″,»Arch»:»amd64″,»BuildTime»:»2022-03-07T15:57:50.000000000+00:00″,»Experimental»:»false»,»GitCommit»:»20.10.12-0ubuntu4″,»GoVersion»:»go1.17.3″,»KernelVersion»:»5.15.0-57-generic»,»MinAPIVersion»:»1.12″,»Os»:»linux»}},{«Name»:»containerd»,»Version»:»1.5.9-0ubuntu3.1″,»Details»:{«GitCommit»:»»}},{«Name»:»runc»,»Version»:»1.1.0-0ubuntu1.1″,»Details»:{«GitCommit»:»»}},{«Name»:»docker-init»,»Version»:»0.19.0″,»Details»:{«GitCommit»:»»}}],»Version»:»20.10.12″,»ApiVersion»:»1.41″,»MinAPIVersion»:»1.12″,»GitCommit»:»20.10.12-0ubuntu4″,»GoVersion»:»go1.17.3″,»Os»:»linux»,»Arch»:»amd64″,»KernelVersion»:»5.15.0-57-generic»,»BuildTime»:»2022-03-07T15:57:50.000000000+00:00″}

Проверим доступность из сети

curl http://10.15.253.223:2375/version

{«Platform»:{«Name»:»»},»Components»:[{«Name»:»Engine»,»Version»:»20.10.12″,»Details»:{«ApiVersion»:»1.41″,»Arch»:»amd64″,»BuildTime»:»2022-03-07T15:57:50.000000000+00:00″,»Experimental»:»false»,»GitCommit»:»20.10.12-0ubuntu4″,»GoVersion»:»go1.17.3″,»KernelVersion»:»5.15.0-57-generic»,»MinAPIVersion»:»1.12″,»Os»:»linux»}},{«Name»:»containerd»,»Version»:»1.5.9-0ubuntu3.1″,»Details»:{«GitCommit»:»»}},{«Name»:»runc»,»Version»:»1.1.0-0ubuntu1.1″,»Details»:{«GitCommit»:»»}},{«Name»:»docker-init»,»Version»:»0.19.0″,»Details»:{«GitCommit»:»»}}],»Version»:»20.10.12″,»ApiVersion»:»1.41″,»MinAPIVersion»:»1.12″,»GitCommit»:»20.10.12-0ubuntu4″,»GoVersion»:»go1.17.3″,»Os»:»linux»,»Arch»:»amd64″,»KernelVersion»:»5.15.0-57-generic»,»BuildTime»:»2022-03-07T15:57:50.000000000+00:00″}

Вернёмся в Jenkins и настроим облако

The docker container’s mapped SSH port, typically a port on the docker host, has to be accessible over network from the master.
Docker image must have sshd installed.
Docker image must have Java installed.
Log in details configured as per ssh-slaves plugin.

Не забудьте указать Remote File System Root. В данном примере это

/home/jenkins

Также советую задать параметр Instance Capacity. Для примера можно ограничить двумя. Если не задавать
этот параметр Jenkins будет запускать столько агентов, сколько сможет. При каких-то неполадках вы
обнаружите список из большого числа неактивных агентов.

В качесте Connect Method можно выбрать

SSH

и подключиться по паролю.

Теперь нужно создать или обновить существующее задание так, чтобы оно выполнялось на агенте

Started by user andrei
Running as SYSTEM
Building remotely on demo-docker-slave-000gd8ottq9e0 on docker (demo-docker-slave) in workspace /home/jenkins/workspace/job_for_docker_agent
[job_for_docker_agent] $ /bin/sh -xe /tmp/jenkins17605261416739110587.sh
+ echo Job for docker agent is done!
Job for docker agent is done!
Finished: SUCCESS

Добавим ещё один шаблон для докер агента. Теперь подключение будет не по SSH а с помощью JNLP

Manage Jenkins → Manage nodes and clouds → Configure Clouds → Docker Agent Template → Add Docker Template

Будем использовать образ

jenkins/jnlp-slave

Старый образ jenkinsci/jnlp-slave устарел и не рекомендуется к использованию

Требования:

Jenkins master has to be accessible over network from the container.

Docker image must have Java installed.

Docker image must launch agent.jar by itself or using the EntryPoint Arguments below.

В Jenkins мастере

Configure Global Security → Agents → TCP port for inbound agents

Автоматический запуск заданий

Рассмотрим задание, которое использует репозиторий на

GitHub

Configure → Source Code Management → Build Triggers

H/5 * * * *

Затем нужно сделать коммит в репозиторий подключённый к этому заданию и подождать около пяти минут.

Started by an SCM change
Running as SYSTEM
Building remotely on docker_slave_ssh-000i0w2937lrg on docker_ubuntu_esxi2 (docker_slave_ssh) in workspace /home/jenkins/workspace/my_python_job
The recommended git tool is: NONE
No credentials specified
Cloning the remote Git repository
Cloning repository https://github.com/yourrepojenkins-docker-slave
> git init /home/jenkins/workspace/my_python_job # timeout=10
Fetching upstream changes from https://github.com/yourrepojenkins-docker-slave
> git —version # timeout=10
> git —version # ‘git version 2.34.1’
> git fetch —tags —force —progress — https://github.com/yourrepojenkins-docker-slave +refs/heads/*:refs/remotes/origin/* # timeout=10
> git config remote.origin.url https://github.com/yourrepojenkins-docker-slave # timeout=10
> git config —add remote.origin.fetch +refs/heads/*:refs/remotes/origin/* # timeout=10
Avoid second fetch
> git rev-parse refs/remotes/origin/master^{commit} # timeout=10
Checking out Revision f0943b9194a48bafebf77280e1a848af92c6d6c3 (refs/remotes/origin/master)
> git config core.sparsecheckout # timeout=10
> git checkout -f f0943b9194a48bafebf77280e1a848af92c6d6c3 # timeout=10
Commit message: «QA: adds ! to helloworld.py»
> git rev-list —no-walk 09810fbbf97a812d396aca02e50c443ce999fa8f # timeout=10
[my_python_job] $ /bin/sh -xe /tmp/jenkins8662150179336980601.sh
+ python3 helloworld.py
Hello World!
Finished: SUCCESS

Если ваше задание — это Multibranch Pipleline, то можно использовать

Configure → Scan Multibranch Pipeline Triggers
→ Periodically if not otherwise run
→ Interval

Переменные окружения

Изучить доступные переменные окружения можно на странице

http://jenkins_url/env-vars.html

Например, в моём примере это

http://jenkins.andrei.com:8080/env-vars.html/

Credentials

Важно не забыть указать ID так как именно он будет идентифицировать данные. Если не задать его
вручную — Jenkins сгенерирует ID самостоятельно и запомнить его будет сложнее.

Для того чтобы пользоваться сохранёнными в Jenkins учётными данными нужно установить плагин
Credentials Binding Plugin

О том как использовать
учетные данные в Pipeline читайте в статье

«Использование учетных данных в Jenkins Pipeline»

Сборщики проектов

pipeline {
agent any

tools {
gradle ‘Gradle-6.2’
}

stages {
stage(«run frontend») {
steps {
echo ‘executing yarn…’
nodejs(‘Node-10.17’) {
sh ‘yarn install’
}
}
}
stage(«run backend») {
steps {
echo ‘executing gradle…’
sh ‘./gradlew -v’
}
}
}
}

Статьи про Jenkins

	Jenkins
	Установка Jenkins
	Основы Jenkins
	Jenkins Pipeline
	Задания по расписанию
	Разбор ошибок
	DevOps
	Docker
	Make

Popular repositories

1. For an introductory tutorial on how to use Jenkins to build a simple Java application with Maven.

   
   
   Shell
   

   352

   23.3k

2. For an introductory tutorial on how to use Jenkins to build a simple Node.js and React application with npm.

   
   
   JavaScript
   

   183

   6.9k

3. For an advanced tutorial on how to use Jenkins to build a multibranch Pipeline project with selectively executed stages.

   
   
   Shell
   

   97

   3.3k

4. For an introductory tutorial on how to use Jenkins to build a simple Python application with PyInstaller.

   
   
   Python
   

   84

   4.7k

5. For an introductory tutorial on how to use the Blue Ocean feature of Jenkins to create a Pipeline that builds an application.

   
   
   JavaScript
   

   37

   1.9k

In this Jenkins tutorial series, you will learn all the essential topics for a DevOps engineer to understand Jenkins better with step-by-step practical tutorials.

What is Jenkins?

Jenkins is a continuous open-source integration written in Java. It was forked from Hudson Project after a dispute with Oracle. Since the fork, Jenkins has grown to be much more than a continuous integration solution.

Jenkins is not just a Continuous Integration tool anymore. Instead, it is a Continuous Integration and Continuous delivery tool. You can orchestrate application deployments using Jenkins with a wide range of freely available community plugins and native Jenkins workflows.

Jenkins also supports GitOps workflows with Jenkins X. It helps you accelerate the continuous delivery pipeline on Kubernetes.

Jenkins Use Cases

The following are the main Jenkins use cases from my experience extensively working on Jenkins.

1. Continuous Integration: With Jenkins pipelines, we can achieve CI for both applications and infrastructure as code.
2. Continuous Delivery: You can set up well-defined and automated application delivery workflows with Jenkins pipelines.
3. Automation & Ad-Hoc Tasks: With Jenkins jobs and pipelines, you can automate infrastructure components and perform ad-hoc infrastructure tasks (Backups, remote executions, etc.).

Jenkins Tutorials For Beginners

In this collection of Jenkins tutorial posts, I will cover various Jenkins guides, which will help beginners get started with many of the Jenkins core functionalities.

I have categorized the list of Jenkins beginner tutorials into multiple sections. From Jenkins installation to advanced concepts like shared libraries are covered in this tutorial list.

It is a growing list of Jenkins step-by-step guides. I will add all the latest tutorials to this list.

How Does Jenkins Work?

In this section, you will learn the very basics of Jenkins that every beginner should know. Overall you will learn how Jenkins works as a CI/CD tool.

1. Jenkins Architecture Explained for Beginners: In this tutorial, you will learn how Jenkins works, its core components, how Jenkins data is organized, and the protocols involved in Jenkins controller-agent communication.
2. Jenkins High Availability: This guide will cover key concepts in setting up a Highly available Jenkins using the open-source version.

Jenkins Administration Tutorials

1. Installing and configuring Jenkins: Learn to install and configure Jenkins on Ubuntu VM & Docker container.
2. Install and Configure Jenkins on Centos/Redhat: This tutorial helps you set up Jenkins on RedHat-based Linux distributions.
3. Setting up Jenkins Agents: This tutorial will teach you how to configure Jenkins master and agents using both SSH and JNLP methods.
4. Configure SSL on Jenkins Server: This tutorial will walk you through the process of setting up SSL for the Jenkins controller.
5. Running Jenkins on port 80: By default Jenkins runs on port 8080. This guide has step by step guides to setup Jenkins to run on port 80.
6. Backing up Jenkins Data and Configurations
7. Setting up Custom UI for Jenkins: A tutorial to change the default UI of Jenkins with custom CSS.
8. Setting up Jenkins Master on Kubernetes Cluster: Tutorial to set up Jenkins infrastructure on containers.
9. Jenkins Setup Using AWS Autoscaling Group: This tutorial teaches you to automate the whole Jenkins setup on AWS using an Autoscaling group, EFS, and a load balancer.

Scaling Jenkins Agents

1. Configuring Docker Containers as Jenkins Build Agents
2. Scaling Jenkins Agents with Kubernetes
3. Configuring ECS as Build Slave For Jenkins [Needs Update]

Jenkins Pipeline Tutorials

1. Jenkins Pipeline as Code Tutorial for Beginners: In this guide, you will learn about Jenkins Pipeline as code. Jenkins pipeline as code helps you organize and manage all the CI/CD Jenkins pipeline as code. This tutorial walks you through the important pipeline concepts.
2. Getting Started With Jenkins Shared Libary: Shared library is a very important concept in Jenkins. It helps you to create reusable pipeline code. It is a must-learn concept.
3. Creating Jenkins Shared Library: Step-by-step guide on the practical implementation of Jenkins shared library
4. Beginner Guide to Parameters in Declarative Pipeline: In this tutorial, you will learn to manage static and dynamic Jenkins parameters using the pipeline as code.

Jenkins CI/CD Tutorials

1. Java Continuous Integration with Jenkins: This tutorial teaches you to set up a Java CI pipeline using the maven build utility. [Needs Update]
2. Jenkins PR based builds with Github Pull Request Builder Plugin
3. Jenkins Multi-branch Pipeline Detailed Guide for Beginners
4. Building Docker Images Using Kaniko & Jenkins on Kubernetes
5. How to manage Secrets with Jenkins [Upcomming]
6. How to Build Docker Image using Jenkins [Upcomming]
7. How to Build Java Applications Using Jenkins Pipeline [Upcomming]

Jenkins Core Features

Let’s have look at the overview of key Jenkins 2.X features that you should know.

1. Pipeline as Code
2. Shared Libraries
3. Better UI and UX
4. Improvements in security and plugins

Pipeline as Code

Jenkins introduced a DSL by which you can version your build, test, and deploy pipelines as code. Pipeline code is wrapped around a groovy script that is easy to write and manage. An example pipeline code is shown below.

node(‘linux’){
  git url: 'https://github.com/devopscube/simple-maven-pet-clinic-app.git'
  def mvnHome = tool 'M2'
  env.PATH = "${MNHOME}/bin:${env.PATH}"
  sh 'mvn -B clean verify'
}

Using pipeline as a code you can run parallel builds on a single job on different slaves. Also, you have good programmatic control over how and what each Jenkins job should do.

Jenkinsfile is the best way to implement Pipeline as code. There are two types of pipeline as code.

1. Scripted Pipeline and
2. Declarative Pipeline.

I recommend using only a declarative pipeline for all your Jenkins-based CI/CD workflows, as you will have more control and customization over your pipelines.

Jenkins 2.0 has a better User interface. The pipeline design is also great in that the whole flow is visualized. Now you can configure the user, password, and plugins right from the moment you start the Jenkins instance through awesome UI.

Also, Jenkins Blueocean is a great plugin that gives a great view of pipeline jobs. You can even create a pipeline using the blue ocean visual pipeline editor. Blueocen looks like the following.

Jenkins Shared Libraries

Jenkins shared library is a great way to reuse the pipeline code. You can create your CI/CD code libraries, which can be referenced in your pipeline script. In addition, the extended shared libraries will allow you to write custom groovy code for more flexibility.

Here is how shared libraries work.

1. The common pipeline shared library code resides on a version control system like Github.
2. The shared library GitHub repo needs to be configured in Jenkins global configuration. It enables access to the library for all Jenkins jobs.
3. You have to add an import statement to import the shared libraries and use it in the pipeline code in individual jobs. During job builds, first, the shared library files get checked out.

GitOps With Jenkins X

Jenkins X is a project from Jenkins for CI/CD on Kubernetes. This project is entirely different from normal Jenkins.

Jenkins X has the following key features.

1. GitOps-based Tekton pipelines
2. Environment Promotion via GitOps
3. Pull Request Preview Environments
4. Feedback and chat on Issues and Pull Requests

Conclusion

All the Jenkins tutorials mentioned in this article will help you take your Jenkins knowledge to the next level.

Jenkins has a huge community and, you can find support in different forums if you face any issues.

If you think any tutorial is missing, do let me know in the comment section. We will add it to the list.

Also, if you want to learn real-world Jenkins uses cases, you can try out the Jenkins workflows from the DevOps Projects.