Введение новичка в Дженкинс – CI/CD

Автор оригинала: Dragan Bjekic.

Вступление

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

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

Ключевые концепции Дженкинса

Чтобы понять, почему кто-то должен использовать Дженкинса, нам нужно понять, какие проблемы Дженкинс стремится решить.

Конвейер CI/CD

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

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

Архитектура Контроллера-Агента

Чтобы распределить нагрузку на параллельные сборки и задачи, Дженкинс представляет архитектуру Контроллер-агент . “Контроллер” – сервер Дженкинса отвечает за администрирование проектов, конфигураций, пользователей и данных. “Агенты” могут быть вызваны для выполнения определенных этапов конкретного конвейера. Это дает множество преимуществ, таких как простота масштабирования, оптимальное аппаратное обеспечение (крупномасштабная математика или сложные процессы с данными), тестовые серверы и сборки для конкретной платформы.

Плагины

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

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

Соглашения об именовании

На протяжении всего жизненного цикла Дженкинса номенклатура немного менялась, в том числе из-за того, что определенная терминология может рассматриваться как оскорбительная.

Несмотря на то, что некоторые соглашения об именах были введены много лет назад, сообщество по-прежнему использует их взаимозаменяемо. Чтобы избежать путаницы, вот несколько синонимичных терминов:

• Мастер
• Раб
• Работа
• Рабочий процесс

Более старая Ведущая/Ведомая архитектура была переименована в Контроллер/Агент архитектура из-за негативных коннотаций терминологии.

Установка

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

В этом руководстве будет описан процесс установки в Ubuntu 20.04 , хотя этот процесс не сильно отличается для Windows, Mac или других дистрибутивов. Проверьте страницу загрузки Дженкинса для вашей конкретной машины (или облачной службы).

Установка JDK/JRE

Будучи написанным на Java, Дженкинсу для запуска требуется Среда выполнения Java . Обратите внимание , что для OpenJDK доступны только версии 8 и 11 поддерживаются. Если вы хотите создавать Java-приложения с помощью Jenkins, вам нужно будет установить JDK вместо только JRE .

Давайте продолжим и установим openjdk-11-jdk :

$ sudo apt install openjdk-11-jdk

Обновление списка источников и установка с помощью apt

Дженкинс недоступен в официальном репозитории Linux, поэтому нам придется добавить его собственный репозиторий. Мы собираемся установить версию LTS ( Долгосрочная поддержка ), которая обновляется каждые 12 недель, согласно веб-сайту Дженкинса.

Для острия, если, например, вы хотите разрабатывать плагины, удалите часть -stable из первой и второй строк ниже:

$ wget -q -O - https://pkg.jenkins.io/debian-stable/jenkins.io.key | sudo apt-key add -
$ sudo sh -c 'echo deb https://pkg.jenkins.io/debian-stable binary/ > \
        /etc/apt/sources.list.d/jenkins.list'
$ sudo apt update
$ sudo apt install jenkins

Наконец, мы можем продолжить и зарегистрировать Дженкинса в качестве сервиса и запустить его через терминал:

$ sudo systemctl daemon-reload
$ sudo systemctl start jenkins

Доступ к Дженкинсу из браузера

По умолчанию Дженкинс размещен на порту 8080 .

Если вы установили Jenkins на локальном компьютере, доступ к нему можно получить из браузера, перейдя по адресу localhost:8080 . Если вы установили его на виртуальной машине, выполнение команды ifconfig (часть net-tools ) покажет IP-адрес виртуальной машины в вашей локальной сети.

При первом запуске Дженкинса требуется скрытый пароль. Его можно найти в /var/lib/Дженкинс/секреты/начальный пароль администратора , написанный на сервере. Извлеките и введите его, чтобы продолжить:

На второй странице выберите опцию Установить предлагаемые плагины . Установка плагина рассматривается далее в этом руководстве. Дождитесь установки плагинов, создайте учетную запись администратора, настройте URL-адрес Дженкинса (в нашем случае мы оставим его на localhost:8080 ) для доступа других пользователей, и вам будет представлена Панель мониторинга :

Использование Дженкинса

Дженкинс-это большой и сложный проект, и мы рассмотрим большинство наиболее важных функций.

Для этого мы рассмотрим три примера рабочего процесса:

• Использование браузера для создания проекта Maven с уведомлениями по электронной почте.
• Подключение к репозиторию GitHub и создание нашего приложения Maven с помощью файла репозитория Дженкинса .
• Используя jenkins-cli.jar Для выполнения повседневных задач, таких как управление заданиями, запуск сборок, проверка журналов и т.д. Из командной строки.

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

Простая Локальная Сборка

Чтобы легко настроить Maven – мы установим плагин Maven для Дженкинса.

Установка плагинов

Перейдите к опции Управление плагинами в разделе Управление Дженкинсом :

Выбрав вкладку Доступно , найдите “Maven” и установите флажок рядом. Выберите Установить без перезагрузки :

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

Настройка Maven

В разделе Управление Дженкинсом перейдите в раздел Глобальная конфигурация инструмента . Прокрутите страницу вниз и добавьте установку Maven. Сохраните новые изменения.

Настройка электронной почты

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

Создание проекта

Выберите Новый элемент на боковой панели, дайте своему проекту имя и отметьте его как Проект Maven , прежде чем нажать ОК :

Git Essentials

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

В нижней части настройте файл POM расположение и настройте дополнительный шаг post для отправки уведомлений по электронной почте. Обратите внимание, что в Unix-подобных системах Дженкинс создает отдельного пользователя Дженкинс , поэтому могут потребоваться права доступа.

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

Запуск сборки

Настроив шаги, мы можем начать сборку. Боковая панель сообщит нам о ходе работы, а также покажет историю сборки. Неудачные сборки (#1) будут отображаться другим цветом.

Перейдите к параметру Вывод на консоль для получения более подробной информации:

Отслеживание репозитория GitHub и чтение файла Дженкинса

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

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

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

Учетные данные GitHub

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

Для создания пары ключей мы будем использовать команду ssh-keygen :

$ ssh-keygen -t rsa -b 4096

Выберите, где хранить ключи, и установите пароль, если хотите.

Затем скопируйте закрытый ключ и перейдите на панель управления Дженкинса. Оттуда в разделе Управление Дженкинсом перейдите в Управление учетными данными -> Дженкинс -> Глобальные учетные данные -> Добавить учетные данные .

Выберите Имя пользователя SSH с закрытым ключом , вставьте ключ вместе с его парольной фразой и нажмите “ОК”.

Скопируйте открытый ключ и вставьте его в список ключей развертывания для вашего репозитория, расположенный по адресу https://github.com/user/repo/setting/keys/new . Дайте ему имя, установите флажок разрешить доступ на запись, если вы хотите, чтобы изменения были частью вашего конвейера, и нажмите Добавить клавишу .

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

Создание проекта

На панели мониторинга перейдите в Новый элемент -> Многоответвленный конвейер . Дайте ему название и продолжайте. В разделе Источники филиалов выберите git , укажите имя источника, введите адрес хранилища и выберите соответствующие учетные данные, которые мы только что добавили. Сохраните изменения и продолжайте.

Мы заставим наш проект прослушивать изменения в репозитории, прокрутив вниз Сканирование триггеров конвейера с несколькими ответвлениями и установив флажок, выбрав 1 минуту в качестве желаемого интервала. Нажмите сохранить .

Примечание: Если рядом с Git вы видите GitHub в качестве опции , это означает, что у вас установлен плагин GitHub. Использование GitHub в качестве источника филиала требует, чтобы вы использовали комбинацию имени пользователя/пароля или имени пользователя/учетных данных токена – , которая обеспечивает доступ ко всем репозиториям, для которых авторизована учетная запись .

Маршрут Git также является более общим, поскольку процедура одинакова для любого удаленного репозитория Git – он не обязательно должен размещаться на GitHub, но, возможно, на сервере компании или в другой службе хостинга, такой как BitBucket и GitLab.

Пока наш проект будет проверять только изменения в нашем репозитории Git. Давайте напишем файл Дженкинса , чтобы Дженкинс знал, что он должен делать.

Написание файла Дженкинса

Чтобы определить набор процедур для запуска – конвейер – мы используем Файлы Дженкинса . Аналогично тому, как Docker использует Dockerfiles в качестве списка выполняемых команд, Дженкинс делает то же самое. Файлы Дженкинса используют синтаксис, похожий на заводной.

Давайте продолжим и напишем сценарий, похожий на Groovy, под названием “Файл Дженкинса” (без расширения) и зафиксируем/переместим его в корневой каталог вашего репозитория:

pipeline {
    agent any
    stages{
        stage('build'){
            steps {
                sh 'mvn clean install'
            }
        }
    }
    post {
        always {
            mail to :"[email protected]",
                subject: "Build Finished: ${currentBuild.fullDisplayName}",
                body:"Check out status at ${env.BUILD_URL}"
        }
    }
}

Этот простой синтаксис очень удобочитаем и достаточно понятен. Мы определили конвейер, который может быть выполнен любым доступным агентом . Существует только один этап ( 'сборка' ), на котором будет запущена команда оболочки для создания нашего кода.

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

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

Служебные задачи в командной строке

Чтобы избежать использования браузера для повседневных задач, таких как запуск/остановка заданий, проверка вывода сборки на консоль или импорт/экспорт, нам нужно будет загрузить jenkins-cli.jar .

Он входит в комплект каждой установки Дженкинса:

$ wget localhost:8080/jnlpJars/jenkins-cli.jar

Чтобы узнать, сможем ли мы подключиться к Дженкинсу, давайте введем следующую команду:

$ java -jar jenkins-cli.jar http://localhost:8080 who-am-i
Authenticated as: anonymous
Authorities:
  anonymous

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

Создание маркера API

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

Чтобы указать пользователя, мы будем использовать параметр -auth , который получает параметры [ПОЛЬЗОВАТЕЛЬ:СЕКРЕТНЫЙ | @ФАЙЛ] . Давайте поместим наше имя пользователя:токен в файл с именем учетные данные , на который мы будем ссылаться при подключении.

$ java -jar jenkins-cli.jar -s http://localhost:8080 -auth @credentials who-am-i
Authenticated as: admin
Authorities:
	authenticated

Список заданий и запущенных сборок

Чтобы перечислить и запустить наши задания, мы будем использовать команды list-jobs и build , а также использовать команду console для получения выходных данных. Обратите внимание , что Приложение GitHub Maven , будучи многоотраслевым проектом, требует указания ветви с синтаксисом project/branch , в нашем случае “GitHub Maven/Maven”:

$ java -jar jenkins-cli.jar -s http://localhost:8080 -auth @credentials list-jobs
GitHub Maven App
Maven App
$ java -jar jenkins-cli.jar -s http://localhost:8080 -auth @credentials build 'GitHub Maven App/Maven'
$ $ java -jar jenkins-cli.jar -s http://localhost:8080 -auth @credentials console 'GitHub Maven App/Maven'
Started from command line by
							admin
Running as SYSTEM
Building in workspace /var/lib/jenkins/workspace/Maven App
Parsing POMs
.
.
.

Импорт/Экспорт Существующих Заданий

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

jenkins-cli обеспечивает поддержку импорта и экспорта с помощью команд get-job и create-job , которые принимают XML в качестве параметра. Следующий код дублирует наш проект Maven в новый:

$ java -jar jenkins-cli.jar -s http://localhost:8080 -auth @credentials get-job 'Maven App' > myMavenProject.xml
$ java -jar jenkins-cli.jar -s http://localhost:8080 -auth @credentials create-job 'new Maven App' < myMavenProject.xml

Вывод

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

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

Если вы хотите продолжить свое путешествие по Дженкинсу – вы можете ознакомиться с нашим руководством по планированию заданий в Дженкинсе или настройке закрытых проверок для проектов Spring Boot на GitHub .