Jenkins остаётся одним из самых распространённых серверов автоматизации: он запускает сборки, тесты, публикацию артефактов и развёртывание по расписанию или по коммиту. Свой экземпляр имеет смысл, когда нужен полный контроль над данными, доступом к внутренней сети и окружением сборки. Ниже — установка на отдельный Linux-сервер, настройка агентов, пайплайн в Jenkinsfile и резервное копирование.

Что даёт собственный контроллер

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

  • полный контроль над версией Java, инструментами и кэшами;
  • исходники и артефакты не покидают вашу инфраструктуру;
  • доступ к внутренним репозиториям и тестовым стендам без публикации наружу.

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

Установка и первый запуск

Нужна поддерживаемая LTS-версия Java. Зафиксируйте версию JDK: после обновления дистрибутива Jenkins может не стартовать. Пакет из официального репозитория ставит systemd-юнит и отдельного пользователя jenkins.

java -version
sudo install -d -m 0755 /etc/apt/keyrings
curl -fsSL https://pkg.jenkins.io/debian-stable/jenkins.io-2023.key | sudo tee /etc/apt/keyrings/jenkins-keyring.asc > /dev/null
echo "deb [signed-by=/etc/apt/keyrings/jenkins-keyring.asc] https://pkg.jenkins.io/debian-stable binary/" | sudo tee /etc/apt/sources.list.d/jenkins.list > /dev/null
sudo apt update && sudo apt install -y jenkins

После установки служба запускается автоматически. Порт по умолчанию — 8080, каталог данных — /var/lib/jenkins. Если порт занят, его меняют в файле /etc/default/jenkins и перезапускают службу.

sudo systemctl status jenkins
sudo journalctl -u jenkins -n 50 --no-pager
sudo ss -ltnp | grep 8080

Первичный пароль создаётся при первом старте. Дальше мастер предложит набор плагинов; для начала достаточно Suggested plugins.

sudo cat /var/lib/jenkins/secrets/initialAdminPassword

Плагины и учётные данные

Минимальный набор: Git, Pipeline, Credentials Binding и JUnit. Плагины — главный источник проблем совместимости, поэтому обновляют их не все сразу, а партиями, с проверкой списка изменений. CLI-клиент лежит на контроллере: /jnlpJars/jenkins-cli.jar.

Секреты хранят в Credentials: пароли, SSH-ключи, токены. В пайплайне их подставляют через withCredentials, а не через переменные окружения на уровне задания.

java -jar jenkins-cli.jar -s http://127.0.0.1:8080/ -auth admin:TOKEN list-plugins
java -jar jenkins-cli.jar -s http://127.0.0.1:8080/ -auth admin:TOKEN safe-restart

Pipeline как код

Декларативный Jenkinsfile хранится рядом с исходниками и проходит ревью вместе с кодом. В примере ниже сборка идёт на агенте с меткой linux, тесты публикуют отчёт, а артефакт сохраняется только при успехе. Блок post гарантирует очистку рабочего каталога даже при падении.

pipeline {
  agent { label 'linux' }
  options { timeout(time: 30, unit: 'MINUTES'); buildDiscarder(logRotator(numToKeepStr: '20')) }
  stages {
    stage('Сборка') { steps { sh './gradlew clean assemble' } }
    stage('Тесты') { steps { sh './gradlew test' } }
    stage('Публикация') {
      when { branch 'main' }
      steps { sh './scripts/publish.sh' }
    }
  }
  post {
    always { junit 'build/test-results/**/*.xml'; cleanWs() }
  }
}

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

Агенты и изоляция сборок

Агент подключается по SSH или через inbound-подключение. Второй вариант удобнее за NAT: агент сам открывает соединение к контроллеру. Пользователь агента должен иметь минимум прав, а рабочий каталог — находиться на отдельном разделе, чтобы сборка не заполнила корень.

sudo useradd -m -s /bin/bash builder
sudo -u builder ssh-keygen -t ed25519 -N '' -f /home/builder/.ssh/id_ed25519
sudo -u builder mkdir -p /home/builder/agent
java -jar agent.jar -url http://jenkins.example.internal:8080/ -secret SECRET -name linux-01 -workDir /home/builder/agent

Контейнерные агенты снижают конфликты версий, но требуют доступа к реестру образов.

Обратный прокси и HTTPS

Наружу контроллер публикуют только через reverse proxy с TLS. В nginx нужно увеличить таймауты и разрешить загрузку артефактов, иначе большие сборки будут обрываться. Заголовки X-Forwarded-* нужны для правильных ссылок.

server {
  listen 443 ssl;
  server_name jenkins.example.com;
  client_max_body_size 100m;
  location / {
    proxy_pass http://127.0.0.1:8080;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_read_timeout 300s;
  }
}

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

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

Копируют весь JENKINS_HOME, включая задания, плагины, историю и файл secret.key. Без последнего зашифрованные учётные данные восстановить нельзя. Для согласованного снимка лучше сделать короткую паузу.

sudo systemctl stop jenkins
sudo tar czf /backup/jenkins-$(date +%F).tar.gz -C /var/lib jenkins
sudo systemctl start jenkins
sudo tar tzf /backup/jenkins-$(date +%F).tar.gz | head

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

Диагностика и безопасность

Если сборка зависла, смотрят журнал службы, очередь заданий и свободное место. Частая причина — переполненный диск или исчерпанный пул агентов. Для зависших процессов помогает thread dump.

df -h /var/lib/jenkins
curl -s -o /dev/null -w '%{http_code}\n' http://127.0.0.1:8080/login
sudo -u jenkins jstack $(pgrep -u jenkins -f jenkins.war) > /tmp/jenkins-threads.txt

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

Чек-лист перед вводом в эксплуатацию

  • Отдельная виртуальная машина и отдельный раздел под данные.
  • Настроены TLS, аутентификация и роли с минимальными правами.
  • Агенты изолированы, секреты выдаются только доверенным веткам.
  • Настроены резервные копии и проверено восстановление.
  • Есть мониторинг диска, очереди и доступности веб-интерфейса.

Итог

Свой Jenkins — это предсказуемый CI/CD без внешних ограничений, но с полной ответственностью за эксплуатацию. Начните с одного контроллера и одного агента, заведите Jenkinsfile в репозитории, настройте резервное копирование и только потом добавляйте новые плагины. Такой порядок избавляет от большинства аварий, которые случаются при попытке сразу построить сложный конвейер.

Насколько публикация полезна?

Нажмите на звезду, чтобы оценить!

Средняя оценка 0 / 5. Количество оценок: 0

Оценок пока нет. Поставьте оценку первым.

Поделиться: Telegram ВКонтакте