Можно ли обновлять плагины на jenkins без доступа в интернет

Обновлено: 05.07.2024

Я пытаюсь создать скрипт bash для настройки Дженкинса. Есть ли способ обновить список плагинов с терминала Jenkins?

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

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

каждый плагин, который имеет обновление доступно, имеет новую версию в скобках в конце. Таким образом, вы можете grep для тех:

Если вы вызываете install-plugin с именем плагина, он автоматически обновляется до последней версии.

наконец, вы должны перезапустить Дженкинс.

собираем все вместе (можно поместить в скрипт):

вы можете установить плагины с компьютерного терминала (а не с терминала Дженкинса).

Это позволит плагин в Дженкинсе и при условии, что Дженкинс запущен.

вот как вы можете развернуть Плагины Jenkins CI с помощью Ansible, который, конечно, используется с терминала. Этот код является частью roles/jenkins_ci/tasks/main.yml :

чувствуйте свободным приспособить его к вашим потребностям.

вы можете обновить список плагинов с помощью этой командной строки

FYI -- некоторые плагины (в частности, mercurial) не устанавливаются правильно из командной строки, Если вы не используете их короткое имя. Я думаю, что это связано с триггерами в информационных данных пакета Дженкинса. Вы можете имитировать собственное обновление пакета Дженкинса, посетив 127.0.0.1:8080/pluginManager/checkUpdates в браузере с поддержкой javascript.

Запуск

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

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

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

Установка и настройка 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 ).

Непрерывная интеграция и развертывание (Deployment) с помощью Jenkins

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

Прежде всего, что такое Jenkins?

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

По сути, это означает, что Jenkins (и многие другие инструменты) позволяют автоматизировать процесс развертывания или предоставления изменений в вашем программном обеспечении пользователям сразу после того, как эти изменения готовы. Представим насколько удобно пользователям видеть обновленные сайты сразу после объединения PR с master (или main).

Почему именно Jenkins?

У него сильное сообщество, поэтому найти поддержку не проблема.

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

В этом руководстве мы узнаем, как выполнить CI/CD для приложения Node с помощью Jenkins. Давайте начнем с определения всех шагов, которые мы предпримем, а затем подробно объясним их ниже:

Создайте репозиторий GitHub для приложения node

Создайте простое приложение node и поместите его на GitHub

Создайте приложение Heroku для развертывания

Добавьте веб-хук GitHub для внесения изменений в Jenkins

Сконфигурируйте приложение с помощью Jenkins

Добавьте плагины GitHub в Jenkins

Сконфигурируйте Jenkins для развертывания на Heroku после успешного тестирования

Необходимые условия

Учетная запись на GitHub. Можно зарегистрироваться здесь.

Сервер Ubuntu. Если вы студент и будете использовать Digital Ocean, то можете получить бонус размере $100, используя студенческий пакет разработчика GitHub. Создайте сервер Ubuntu с помощью этого руководства. Настройте сервер, следуя этому руководству по начальной настройке сервера Ubuntu 20.04, включая пользователя без права sudo-доступа, файрвол и доступ по SSH с вашей локальной машины.

Учетная запись Heroku. Можно зарегистрироваться здесь.

Учетная запись на GitHub. Можно зарегистрироваться здесь.

Учетная запись Heroku. Можно зарегистрироваться здесь.

Итак, давайте начнем!

Шаг 1 - Создайте репозиторий GitHub для приложения node

Войдите в свою учетную запись GitHub и создайте новый репозиторий. Дайте ему имя по своему усмотрению, я назову свой jenkins-test . Для инициализации можно использовать README и .gitignore для Node. Также убедитесь, что ваш репозиторий установлен на public.

Шаг 2 - Создайте простое приложение node и разместите его на GitHub

После создания репозитория, клонируйте его на локальную машину с помощью следующей команды:

Не забудьте изменить repository_url на свой.

Чтобы создать файл package.json , откройте терминал и cd в папке проекта, затем запустите npm init и следуйте подсказкам. Я добавил скриншот, чтобы увидеть взаимодействие с CLI ниже.

Вы можете удалить или изменить то, что находится в блоке скриптов вашего файла package.json, и добавить start и test для запуска и тестирования приложения:

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

Далее создайте файл index.js, который будет служить точкой входа в наше приложение node, и добавьте в него следующие строки:

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

Итак, вернитесь в терминал, убедитесь, что вы находитесь в корневом каталоге вашего проекта, и установите пакеты jest и supertest с помощью следующей команды:

Далее в корневом каталоге проекта создайте папку и назовите ее __test__ (два знака подчеркивания, предшествующий и завершающий). Внутри этой папки __test__ создайте файл index.test.js и добавьте в него по крайней мере следующий код (вы всегда можете сделать свои тесты более полными).

Запустите npm test или npm run test в терминале, и вы убедитесь, что тест(ы) прошел(и):

Шаг 3 - Создание приложения Heroku для развертывания

Войдите в свою панель управления Heroku.

Посмотрите в правый верхний угол и нажмите на New.

Выберите Create new app (Создать новое приложение).

Добавьте App name (название приложения) по своему выбору и выберите регион (Choose a region), в котором вы находитесь.

Нажмите Создать приложение (Create app).

Вернитесь в терминал вашего проекта и login (войдите) в Heroku с помощью Heroku CLI. Если вы еще не установили Heroku CLI, вы можете прочесть эту статью.

После этого добавьте remote в ваш локальный репозиторий с помощью:

Затем введите код с помощью:

Это делается для того, чтобы убедиться, что все работает правильно, прежде чем автоматизировать его. Вы можете нажать open app (открыть приложение) на приборной панели приложения Heroku, чтобы проверить, правильно ли оно работает.

Шаг 4 - Установите Jenkins

Откройте новый терминал и войдите на свой сервер под учетной записью пользователя non-root.

После этого мы можем обновить ядро с помощью следующей команды:

Выполните следующую команду для установки java runtime:

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

Теперь, когда Jenkins и все зависимости инсталлированы мы можем запустить его с помощью:

Вы можете проверить успешность запуска Jenkins, используя:

Он должен показать active:

Поскольку Jenkins выполняется на порту 8080, давайте откроем его с помощью ufw:

Вы можете проверить состояние ufw с помощью:

Чтобы разблокировать Jenkins, вернитесь к терминалу и введите следующую команду для отображения пароля. Скопируйте пароль и вставьте его в поле Administrator password (Пароль администратора).

На следующем экране отображается Customize Jenkins (Настроить Jenkins), нажмите на Install suggested plugins (Установите предложенные плагины).

После завершения установки мы перейдем к экрану Create First Admin User (Создание первого пользователя-администратора). Введите Username (имя пользователя), Password (пароль), Full name (полное имя) и E-mail address (адрес электронной почты) для вашего пользователя, затем Save and Continue (Сохранить и продолжить).

Ура, Jenkins готов! Нажмите на Start using Jenkins (Начать использование Jenkins).

Шаг 5 - Добавьте веб-хук GitHub для внесения изменений в Jenkins

В репозитории GitHub приложения перейдите в Settings (Настройки), затем на боковой панели нажмите на Webhooks. Нажмите на Add webhooks (Добавить веб-хуки) и введите url Jenkins с приставкой /github-webhook/ в поле Payload URL.

Выберите application/json для Content-type.

Выберите Just the push event для события, запускающего веб-хук.

Установите флажок Active и нажмите Add webhook. Теперь GitHub может успешно отправлять события в Jenkins.

Шаг 6 - Сконфигурируйте приложение с помощью Jenkins

Откройте новую вкладку или окно терминала и войдите на свой сервер с той же учетной записью пользователя non-root.

В том же терминале включите привилегии root, используя:

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

Сгенерируйте новый ключ SSH с помощью следующей команды:

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

После завершения процесса распечатайте информацию об открытом ключе с помощью:

Скопируйте открытый ключ.

Теперь войдите обратно как пользователь non-root в новом терминале.

Откройте папку authorized_keys следующей командой:

Вставьте открытый ключ id_rsa и выйдите.

Чтобы убедиться, что ключи настроены правильно, переключитесь на терминал сервера jenkins и попробуйте войти в систему как пользователь non-root, используя ssh. Вы успешно войдете в систему, если будете следовать всем вышеописанным действиям.

Шаг 7 - Добавьте плагины GitHub в Jenkins

На приборной панели Jenkins перейдите в раздел Manage jenkins (Управление jenkins), а затем нажмите на Manage plugins (Управление плагинами).

На вкладке Available найдите github и выберите Github Integration plugin (Интеграционный плагин Github).

Нажмите на Install without restart (Установить без перезагрузки), и плагин будет установлен через несколько секунд.

Шаг 8 - Сконфигурируйте Jenkins для развертывания на Heroku после успешного тестирования

Теперь, когда GitHub подключен к Jenkins, мы можем создать новый проект.

На боковой панели нажмите на New Item (Новая тема), выберите Freestyle project из предложенных вариантов и нажмите OK.

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

На странице конфигурации, во вкладке general (общие), отметьте Github project option (опцию проект Github) и добавьте Github project link (ссылку проекта Github) (url для репозитория вашего проекта, без расширения .git).

Далее прокрутите вниз до раздела Source Code Management (Управление исходным кодом), выберите Git и добавьте Repository URL с расширением .git (тот же url, который вы использовали для клонирования репозитория).

Вы можете изменить master ветвь на main или любые другие ветви, которые вам нужны для процесса развертывания.

Нажмите на кнопку Add repository (Добавить репозиторий), чтобы добавить второй репозиторий, указывающий на ваше приложение Heroku.

Чтобы получить ссылку на репозиторий приложения Heroku, перейдите в App settings (настройки приложения) на панели управления Heroku и скопируйте ссылку.

Вернитесь на приборную панель Jenkins и вставьте эту ссылку в Repository URL.

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

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

Убедитесь, что Kind (Тип) - Username with password (Имя пользователя с паролем), а Scope (Область) - global (глобальная).

Введите username (имя пользователя) по своему выбору, но лучше всего, чтобы оно было каким-нибудь описательным. Я буду использовать heroku в качестве имени пользователя.

Далее нам нужно будет добавить Heroku Api key (Api-ключ) в поле Password

(Пароль) и Save (Сохранить). Чтобы получить Heroku Api key, перейдите на приборную панель Heroku, нажмите на Account Settings (Настройки аккаунта) и прокрутите вниз, чтобы увидеть Api key. Скопируйте его и вставьте в поле Password (Пароль).

Вы можете добавить Description (Описание) для этой учетной записи, если хотите.

Нажмите Add (Добавить), чтобы завершить создание учетной записи.

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

Далее нажмите на advanced и добавьте Name, чтобы идентифицировать это хранилище среди других удаленных хранилищ. Это имя понадобится нам позже. Я назвал свое хранилище jenkinsTest, потому что это легко и понятно.

Далее прокрутите вниз до раздела Build Triggers и отметьте опцию GitHub hook trigger for GITScm polling (Триггер хука GitHub для опроса GITScm).

В разделе Build нажмите на кнопку Add build step (Добавить шаг сборки) и затем нажмите на Execute shell (Выполнить командную оболочку). Введите в оболочку следующий код:

Нажмите на Add post-build action (Добавить действие после сборки), выберите Git Publisher и укажите опцию Push Only If Build Succeeds (Запускать только в случае успеха сборки).

Нажмите на Add Branch (Добавить ветвь), введите имя ветви для развертывания в поле Branch to Push и добавьте Name, используемое для идентификации репозитория приложения Heroku, в поле Target remote name (мое имя было jenkinsTest, если вы помните, поэтому добавьте сюда свое).

Затем Save (сохраните).

Перейдите на приборную панель проекта, нажмите Build now (Построить сейчас) на левой боковой панели и с удовольствием наблюдайте за успешной сборкой вашего кода!

Внесите изменения в свой код и опубликуйте его на GitHub. Затем посмотрите, как ваш код будет автоматически развернут на Heroku.

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

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

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

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

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

Build. Компиляция проекта
Test. Выполнение тестов. В проекте у нас только модульные тесты, но с помощью Maven нетрудно сделать отдельный шаг и для интеграционных тестов
Package. Сборка jar-архива
Push Images. Создание Docker-образов и их загрузка в реестр образов. Мы будем пушить два образа — с тегом latest и конкретной версией
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 мы передаем опции для команды докера, а именно имя используемого докер-файла.

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

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

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

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

Итоговый Jenkinsfile

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

Заключение

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

Как установить плагин в Jenkins вручную

можно ли скачать плагин и установить его вручную в Дженкинс?

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

скачать плагин.
Внутри Дженкинс: Управление Дженкинс → Управление Плагинами → есть вкладка под названием дополнительно и на этой странице есть возможность загрузить плагин (расширение файла должно быть ИГП).

иногда при загрузке плагинов вы можете получить (.zip) файлы затем просто переименовать с (.hpi) и использовать пользовательский интерфейс для установки плагина.

пример родительского файла Dockerfile:

Я создал простой скрипт, который делает следующее:

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

скрипт не требует запуска jenkins - я использую его для подготовки докера коробка.

иногда при загрузке плагинов вы можете получить (.zip) файлы затем просто переименовать с (.hpi), а затем извлеките все плагины и перейдите в .

обновление для Docker: используйтеinstall-plugins.sh сценарий. Он принимает список имен плагинов минус расширение "- plugin". См. Описание здесь.

install-plugins.sh заменяет устаревший plugins.sh который теперь предупреждает:

WARN: plugins.sh is deprecated, please switch to install-plugins.sh

использовать плагины.txt согласно plugins.sh см.этот вопрос и этот метод:

RUN /usr/local/bin/install-plugins.sh $(cat /usr/share/jenkins/plugins.txt | tr '\n' ' ')

ответы даны работа, с добавленными плагинами.

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

в моем случае мне нужно было установить плагин на автономный сервер сборки под управлением Windows Server (версия здесь не имеет значения). Я уже установил Jenkins на своем ноутбуке, чтобы заранее проверить изменения, и он работает на localhost:8080 как служба windows.

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

Дженкинс на моем ноутбуке: откройте Дженкинс,http://localhost:8080
Navigator: управление Jenkins / скачать плагин без опции установки
Проводник Windows: скопируйте загруженный файл плагина, который находится по адресу "c:\program папка" файлы (x86)\Jenkins\plugins " (т. е. ролевая стратегия.jpi по)
вставьте его в общую папку на автономном сервере
остановите службу Jenkins (автономный сервер Jenkins) через Компонент Услуги, Услуги Дженкинс
скопируйте файл плагина (т. е. ролевую стратегию.jpi) в "c:\program файлы (x86)\Jenkins\plugins" папка на сервере (Offline Jenkins)
перезапустить Дженкинс и вуаля! Он должен быть установлен.

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

копировать через каталог плагинов:

скопируйте их в другой ящик Дженкинса:

для установки плагина " git " со всеми его зависимостями:

здесь установлен плагин git ; версия, указанная как @current игнорируется Дженкинс. Дженкинс работает на localhost порт 8080 изменить при необходимости. Насколько я знаю, это самый простой способ установить плагин со всеми его зависимостями "вручную". Протестировано на Дженкинсе v1.644

Читайте также: