В этом уроке разберёмся, как устроены jenkins плагины, откуда они берутся, как обновлять и откатывать без сюрпризов, какой набор реально нужен в 2026 году и как описать всё это кодом, чтобы инсталляция была воспроизводимой.
Update Center и механика установки плагина Jenkins
Любой плагин Jenkins берётся из Update Center - это каталог, который контроллер периодически тянет с updates.jenkins.io. По умолчанию там лежат последние совместимые версии под твою сборку ядра. Зайди в "管理 Jenkins -> Plugins" (старый путь "Manage Plugins"), и увидишь четыре вкладки: доступные обновления, available для установки, installed и advanced с настройкой источника.
Когда ты ставишь плагин jenkins через UI, происходит вот что: контроллер скачивает .hpi-файл, кладёт его в JENKINS_HOME/plugins, разрешает зависимости (другие плагины, которые нужны этому) и тоже их докачивает. Многие плагины требуют рестарта - до перезапуска класслоадер не подхватит новые классы. Поэтому в Update Center есть галочка "Restart Jenkins when installation is complete and no jobs are running".
Самое важное про зависимости: ты почти никогда не ставишь один плагин. Например, ставя workflow-aggregator (это и есть jenkins pipeline plugin, мета-пакет всего пайплайна), ты тянешь два-три десятка transitive-зависимостей. Каждая из них - отдельный модуль со своей версией и своим темпом обновлений.
Обновление, откат и совместимость: где больно
Update Center показывает, для каких плагинов есть свежие версии. Обновлять оптом и сразу на проде - плохая идея. Типичный сценарий аварии: ты жмёшь "обновить всё", один из плагинов в новой версии поднял минимальную версию ядра или другого плагина, зависимость не удовлетворилась - и после рестарта половина расширений в статусе "failed to load", а джобы не стартуют.
Откат в Jenkins есть, но он примитивный. На странице плагина внизу бывает кнопка "Downgrade to <предыдущая версия>" - она работает, только если старый .hpi ещё лежит локально (Jenkins хранит .bak). Если нет - качаешь нужную версию вручную со страницы плагина на plugins.jenkins.io, кладёшь .hpi в каталог plugins и перезапускаешь. Поэтому золотое правило: бэкап JENKINS_HOME (а точнее каталога plugins и config.xml) перед каждым обновлением. Без бэкапа откат превращается в археологию.
Про совместимость в 2026 держи в голове два слоя. Первый - версия ядра: плагин объявляет минимально требуемую LTS. Второй - версия Java. Тут за последние пару лет всё сдвинулось: актуальные LTS-линии Jenkins уже требуют Java 21, а самые свежие сборки поддерживают и Java 25; Java 17 в новых релизах LTS отвалилась. Если ты сидишь на старой Java, часть свежих плагинов просто не загрузится. Прежде чем массово обновлять плагины, убедись, что контроллер крутится на поддерживаемой Java - иначе словишь NoClassDefFoundError на ровном месте.
Ключевой набор jenkins plugins на 2026 год
Не ставь всё подряд "на всякий случай" - каждый лишний плагин это поверхность атаки и потенциальный конфликт. Вот разумный костяк для современного declarative-конвейера:
- Pipeline (workflow-aggregator) - сердце. Тот самый jenkins pipeline plugin, который даёт директивы pipeline, stages, steps и парсинг Jenkinsfile.
- Git (git, git-client) - чекаут репозиториев, без него никуда.
- Credentials + Credentials Binding - безопасное хранилище секретов и их подстановка в шаги через withCredentials.
- Configuration as Code (configuration-as-code) - настройка самого Jenkins через YAML. В книге 2018 года этого нет, а сегодня это базовая практика.
- Docker Pipeline (docker-workflow) - сборка и запуск контейнеров прямо из пайплайна.
- Kubernetes (kubernetes) - эфемерные агенты-поды, которые поднимаются под задачу и умирают после неё.
- Role-based Authorization Strategy (role-strategy) - гибкие права по ролям вместо matrix-каши.
- Blue Ocean (blueocean) - наследие. Когда-то это был модный UI для пайплайнов, но проект давно в режиме поддержки: новых фич не будет, только редкие правки безопасности. Не строй на нём процессы. Для визуализации стадий бери Pipeline Graph View или Pipeline: Stage View - они живые и активно развиваются.
Кликать мышкой в Update Center нормально для песочницы, но для прода это путь к "снежинке" - серверу, который никто не может воспроизвести. Решение - описать список плагинов файлом и собирать Jenkins из образа.
Официальный Docker-образ Jenkins несёт утилиту jenkins-plugin-cli (плагин-менеджер). Она читает plugins.txt в формате artifactId:version (версию можно опустить - возьмётся latest, но для воспроизводимости лучше пинить), скачивает плагины со всеми зависимостями и показывает предупреждения безопасности.
Пример plugins.txt:
Код: Выделить всё
workflow-aggregator:latest
git
credentials-binding
configuration-as-code
docker-workflow
kubernetes
role-strategy
pipeline-graph-view
Код: Выделить всё
FROM jenkins/jenkins:lts-jdk21
COPY --chown=jenkins:jenkins plugins.txt /usr/share/jenkins/ref/plugins.txt
RUN jenkins-plugin-cli --plugin-file /usr/share/jenkins/ref/plugins.txt
Код: Выделить всё
jenkins:
systemMessage: "Контроллер собран из plugins.txt и JCasC"
numExecutors: 0
authorizationStrategy:
roleBased:
roles:
global:
- name: "admin"
permissions:
- "Overall/Administer"
assignments:
- "devops"
unclassified:
location:
url: "https://ci.cyberlake.ru/"
А вот как использовать установленные плагины в реальном Jenkinsfile - эфемерный агент в Kubernetes плюс шаг с секретом:
Код: Выделить всё
pipeline {
agent {
kubernetes {
yaml '''
apiVersion: v1
kind: Pod
spec:
containers:
- name: maven
image: maven:3.9-eclipse-temurin-21
command: ['sleep']
args: ['infinity']
'''
}
}
stages {
stage('Build') {
steps {
container('maven') {
sh 'mvn -B clean package'
}
}
}
stage('Push') {
steps {
withCredentials([usernamePassword(
credentialsId: 'registry-creds',
usernameVariable: 'REG_USER',
passwordVariable: 'REG_PASS')]) {
sh 'echo "$REG_PASS" | docker login -u "$REG_USER" --password-stdin'
}
}
}
}
}
Типичные грабли
- Заброшенные плагины. На plugins.jenkins.io у части плагинов висит плашка "deprecated" или давно не было релизов. Такой плагин - мина: он может не пережить следующее обновление ядра или нести незакрытую уязвимость. Перед установкой смотри дату последнего релиза и число инсталляций.
- Конфликты версий. Два плагина тянут одну зависимость разных версий. Jenkins разрулит не всегда - в логах "plugin X requires Y >= z". Лечится синхронным обновлением связки, а не точечным тыком в один плагин.
- Влияние на стабильность контроллера. Кривой или тяжёлый плагин может отъедать память контроллера, плодить потоки и ронять весь инстанс. Чем больше плагинов - тем выше шанс, что один утянет всех. Минимализм здесь это не аскетизм, а надёжность.
- Безопасность. Jenkins security advisories выходят регулярно и чаще всего касаются именно плагинов. jenkins-plugin-cli и Update Center показывают security warnings - не игнорируй их. Уязвимый плагин Git или Credentials это прямой путь к утечке секретов.
Мини-лаба
- Открой "Manage Jenkins -> Plugins", зайди на installed и найди три плагина с пометкой об устаревании или предупреждением безопасности.
- Установи Pipeline Graph View, запусти любой пайплайн и сравни визуализацию со старым Blue Ocean (если он ещё стоит).
- Собери plugins.txt из ключевого набора выше и забилди свой Docker-образ Jenkins командой из урока. Подними контейнер и убедись, что плагины на месте без единого клика в UI.
- Подключи JCasC: смонтируй casc.yaml, выставь CASC_JENKINS_CONFIG и проверь, что systemMessage и URL применились автоматически.
- Что такое Update Center и почему установка одного плагина обычно тянет десятки других?
- Почему перед массовым обновлением плагинов критичен бэкап JENKINS_HOME и какой механизм отката есть штатно?
- Зачем нужен plugins.txt и чем подход "плагины как код" лучше ручной установки через UI?
- Какой статус у Blue Ocean в 2026 году и чем его заменить для визуализации стадий пайплайна?
Плагины - это и есть Jenkins: ядро лишь движок, а реальная работа делается расширениями. Сила в гибкости, риск в нестабильности, конфликтах версий и уязвимостях. Лечится это дисциплиной: минимальный осознанный набор, бэкап перед обновлением, контроль security warnings и - главное - описание всего хозяйства кодом через plugins.txt и JCasC. Тогда твой контроллер перестаёт быть снежинкой и становится воспроизводимым артефактом, который не страшно пересобрать с нуля.
