Мастер настройки: разблокировка, плагины и первый админ
При первом запуске Jenkins генерирует одноразовый пароль и кладёт его в файл внутри JENKINS_HOME. Найти его легко:
Код: Выделить всё
cat /var/lib/jenkins/secrets/initialAdminPassword
# в Docker:
docker exec <container> cat /var/jenkins_home/secrets/initialAdminPassword
Следующий экран - создание первого администратора. Не оставляй учётку admin/admin и не пропускай этот шаг кнопкой "Continue as admin", иначе логином станет тот самый одноразовый секрет. Заведи нормального пользователя с осмысленным именем и сильным паролем. Последний шаг визарда - Jenkins URL. Его обязательно проставить правильно: это не косметика. По этому адресу Jenkins строит ссылки в уведомлениях и, что важнее, его ждут вебхуки от GitLab и GitHub. Оставишь localhost - получишь молчащие триггеры и битые ссылки в почте.
Manage Jenkins: глобальная конфигурация и настройка инструментов
Когда визард закрылся, вся дальнейшая настройка jenkins живёт в разделе Manage Jenkins. Это твой центр управления, и стоит знать, что где лежит. Обзор Manage Jenkins по основным блокам:
- System - системные настройки: Jenkins URL, системное сообщение, число исполнителей (executors) на контроллере, адрес SMTP, глобальные переменные окружения.
- Tools - объявление инструментов сборки: JDK, Git, Maven, Gradle, NodeJS. Здесь ты задаёшь именованные установки, на которые потом ссылаешься в пайплайне.
- Plugins - управление плагинами: установка, обновление, удаление.
- Security - кто может войти (Security Realm) и кто что может делать (Authorization).
- Nodes и Clouds - агенты и облачные провайдеры (например, Kubernetes).
- Credentials - секреты: токены, SSH-ключи, пароли.
Настройка инструментов сборки в Tools - частый источник боли у новичков. Логика такая: ты регистрируешь установку с именем, а Jenkins либо использует уже стоящий в системе бинарник (путь к JAVA_HOME, к git), либо ставит сам через "Install automatically". В декларативном пайплайне на эти имена ссылаются через блок tools:
Код: Выделить всё
pipeline {
agent any
tools {
jdk 'jdk21'
maven 'maven3'
}
stages {
stage('Build') {
steps {
sh 'java -version'
sh 'mvn -B clean package'
}
}
}
}
Jenkins пользователи, авторизация и базовая безопасность
Самое опасное место дефолтной установки - права доступа. Заходишь в Security и видишь два независимых вопроса. Первый - Security Realm (откуда берутся jenkins пользователи): "Jenkins' own user database" - встроенная база, простой и нормальный вариант для старта; есть LDAP, есть вход через GitHub/Google. Второй вопрос - Authorization (что им можно). Здесь живёт главная ловушка: режим "Anyone can do anything" удобен на минуту и катастрофичен на проде - это анонимный полный доступ. Никогда не оставляй его. Рабочий выбор - "Matrix-based security" (матрица прав) или "Project-based Matrix Authorization", где ты явно раздаёшь права по пользователям и группам.
Минимально здравая матрица: анонимному пользователю - ничего (или только Overall/Read, если форум должен показывать статус сборок публично), аутентифицированным - чтение, конкретным людям - сборка и администрирование. Не давай Overall/Administer всем подряд: с этим правом человек по сути получает шелл на сервере через пайплайн.
И отдельно про создание jenkins пользователей. В режиме встроенной базы новых людей заводят в Manage Jenkins -> Users. Но запомни: создать пользователя и выдать ему права - это два разных действия. Завёл учётку в Users, потом обязательно прописал её в матрице авторизации, иначе человек войдёт и не увидит ничего.
Резервное копирование JENKINS_HOME и подход "не кликать руками"
Вся конфигурация, которую ты сейчас накликал, история сборок, плагины и секреты - всё это лежит в одной директории JENKINS_HOME (обычно /var/lib/jenkins или /var/jenkins_home в Docker). Потеряешь её - потеряешь весь Jenkins. Поэтому бэкап JENKINS_HOME обязателен. Минимально рабочий вариант - остановить сервис и заархивировать каталог:
Код: Выделить всё
systemctl stop jenkins
tar czf /backup/jenkins-$(date +%F).tar.gz -C /var/lib/jenkins .
systemctl start jenkins
А теперь главное. Всё, что ты прокликал в визарде и Manage Jenkins, - это состояние, которое живёт в недрах XML-файлов и которое невозможно нормально ревьюить и воспроизвести. Современный ответ на это - Configuration as Code (плагин JCasC). Вместо кликов ты описываешь конфигурацию контроллера в YAML, кладёшь файл в репозиторий и указываешь Jenkins на него переменной CASC_JENKINS_CONFIG. Вот как тот же самый стартовый набор выглядит декларативно:
Код: Выделить всё
jenkins:
systemMessage: "Управляется через JCasC, руками не трогать"
numExecutors: 0
securityRealm:
local:
allowsSignup: false
users:
- id: "admin"
password: "${ADMIN_PASSWORD}"
authorizationStrategy:
globalMatrix:
permissions:
- "Overall/Administer:admin"
- "Overall/Read:authenticated"
unclassified:
location:
url: "https://ci.example.com/"
tool:
git:
installations:
- name: "Default"
home: "git"
Кстати, про устаревшее. Blue Ocean - красивый альтернативный UI из эпохи книги Ластера - в 2026 году в режиме поддержки: новых функций нет, только редкие правки безопасности. Строить на нём ничего не надо, это наследие. И для контекста: по адаптации в индустрии Jenkins держит около 28 процентов, уступив лидерство GitHub Actions (порядка 33) и наступающему на пятки GitLab CI. Там конфигурация изначально живёт в YAML в репозитории - и JCasC как раз догоняет эту идею для мира Jenkins.
Типичные грабли
- Оставленный localhost в Jenkins URL. Вебхуки не приходят, ссылки в письмах битые. Правь сразу в System.
- "Anyone can do anything". Открытый анонимный доступ к серверу с правом запуска шелл-команд. Никогда не в проде.
- Сборка на контроллере. Executors контроллера в 0, собирают агенты.
- Плагины пачками. Каждый - риск и обновления. Ставь только нужное.
- Создал пользователя, забыл про матрицу. Человек входит и видит пустоту - права раздаются отдельно.
- Нет бэкапа JENKINS_HOME. Один отказ диска - и весь Jenkins с историей и секретами потерян.
- Запусти свежий Jenkins (проще всего в Docker), достань initialAdminPassword, пройди визард, выбрав suggested plugins.
- Создай нормального админа (не admin/admin) и пропиши корректный Jenkins URL в Manage Jenkins -> System.
- В Manage Jenkins -> Tools заведи установку JDK с именем jdk21 и Maven с именем maven3. Собери минимальный декларативный pipeline из урока и убедись, что java -version и mvn отрабатывают.
- Переключи Authorization на Matrix-based security, заведи второго пользователя в Users, выдай ему только Overall/Read и проверь под его логином, что админских кнопок он не видит.
- Сделай tar-бэкап JENKINS_HOME, удали контейнер, разверни заново и восстанови из архива.
- Чем Security Realm отличается от Authorization Strategy и почему недостаточно завести пользователя, чтобы он получил права?
- Почему режим "Anyone can do anything" опасен и какой режим авторизации брать вместо него?
- Что произойдёт, если имя инструмента в блоке tools пайплайна не совпадёт с именем установки в Manage Jenkins -> Tools?
- Какую проблему ручной настройки решает JCasC и что нельзя забыть положить в бэкап JENKINS_HOME?
Первичная настройка Jenkins - это пять решений, которые задают судьбу инсталляции: разумный набор плагинов, нормальный админ вместо дефолта, правильный Jenkins URL, матрица прав вместо открытого доступа и регулярный бэкап JENKINS_HOME. Manage Jenkins даёт всё это прокликать руками - и это полезно, чтобы понять механику. Но как только ты осознал, какие именно ручки крутишь, переноси их в YAML через JCasC: воспроизводимый контроллер из кода - это и есть стандарт 2026 года, особенно когда Jenkins живёт в Kubernetes.
