Jenkins на Ubuntu 24.04: пошаговая установка

MAATRIX

Jenkins — самый живучий инструмент CI/CD на рынке: ему больше двадцати лет, а он всё ещё стоит в проде у половины компаний, которым нужен полный контроль над пайплайном и не хочется зависеть от лимитов GitHub Actions или GitLab CI SaaS. Минус один — сам себе хостишь, сам обновляешь, сам разбираешься с плагинами. Ниже — рабочая установка Jenkins на чистой Ubuntu 24.04 LTS: от голого сервера до первого pipeline за собственным Nginx с HTTPS.

Что понадобится перед установкой

Jenkins сам по себе не прожорлив, но агенты сборки (компиляция, тесты, сборка Docker-образов) едят память рывками. Ориентируйтесь на такие минимумы:

• 2 vCPU, 4 ГБ RAM — комфортный старт для одного проекта с 1-2 параллельными сборками. На 2 ГБ Jenkins стартует, но JVM начинает подтормаживать под нагрузкой, особенно если в pipeline собирается Docker-образ.
• От 40 ГБ диска — под /var/lib/jenkins уходят workspace-ы сборок, артефакты, кэш плагинов и логи. Растёт быстро, если не чистить старые билды.
• Ubuntu 24.04 LTS x86_64, свежая, без легаси-пакетов Java из старых репозиториев — они конфликтуют с версией, которую требует текущий Jenkins.
• Домен, направленный на IP сервера — нужен для нормального HTTPS через Let's Encrypt, без него можно жить только по IP и самоподписанному сертификату, что неудобно для webhook'ов от GitHub/GitLab.
• Открытые порты 22 (SSH), 80/443 (HTTP/HTTPS через Nginx). Сам Jenkins слушает 8080, но наружу его лучше не светить напрямую.

Если сервер арендован специально под CI/CD, стоит сразу заложить запас по диску и памяти — со временем добавятся Docker-агенты и параллельные джобы, и апгрейд тарифа "на живую" не всегда безболезненный.

Устанавливаем Java — Jenkins требует JDK, не JRE

Jenkins с 2024 года работает только на Java 17 или 21 — старые JRE 11 больше не поддерживаются актуальными версиями. Берём OpenJDK 21 из репозиториев Ubuntu 24.04 — там уже свежая сборка:

sudo apt update
sudo apt install -y openjdk-21-jdk fontconfig
java -version

Ожидаемый вывод — что-то вроде openjdk version "21.0.x". Ставим именно JDK, а не JRE: Jenkins использует некоторые инструменты сборки (jarsigner, javac для отдельных плагинов), которых в JRE нет.

fontconfig нужен не для красоты — без него Jenkins иногда падает при генерации графиков истории сборок (используются AWT-классы, которым нужны системные шрифты).

Устанавливаем Jenkins из официального репозитория

Пакет из стандартных репозиториев Ubuntu почти всегда старый и без нужных плагинов апстрима. Ставим из официального репозитория Jenkins — там актуальная LTS-ветка:

sudo wget -O /usr/share/keyrings/jenkins-keyring.asc \
  https://pkg.jenkins.io/debian-stable/jenkins.io-2023.key

echo "deb [signed-by=/usr/share/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

После установки сервис поднимается сам:

sudo systemctl enable --now jenkins
sudo systemctl status jenkins

Если статус active (running) — Jenkins слушает на 127.0.0.1:8080 (или 0.0.0.0:8080, в зависимости от конфигурации файрвола — снаружи это неважно, порт мы всё равно закроем и отдадим доступ только через Nginx). Проверить, что процесс реально слушает порт:

sudo ss -tlnp | grep 8080

Первый запуск JVM может занять 20-40 секунд — не спешите перезапускать сервис, если веб-интерфейс не открылся сразу.

Проходим мастер первичной настройки

Jenkins при первом старте генерирует пароль администратора и требует его ввести — это защита от захвата свежеустановленного инстанса, пока вы не сменили дефолтные настройки. Пароль лежит в файле:

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

Дальше открываете http://ВАШ_IP:8080 в браузере (пока без домена и SSL — их настроим на следующем шаге), вставляете пароль и попадаете в мастер настройки:

1. Install suggested plugins — для старта достаточно, туда входят Git, Pipeline, Credentials Binding и базовый набор для большинства сценариев. Если точно знаете, что нужны конкретные плагины (например, Docker Pipeline или конкретный SCM), можно выбрать "Select plugins to install" и добавить их сразу.
2. Создаёте первого администратора — реального пользователя, не встроенного admin. Логин, пароль, email.
3. Указываете Jenkins URL — здесь уже стоит вписать будущий домен (https://ci.вашдомен.ру), даже если SSL ещё не настроен: многие плагины и webhook-конфиги берут этот URL как базовый, и переписывать его потом по всем джобам неприятно.

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

Закрываем Jenkins за Nginx с HTTPS

Отдавать Jenkins напрямую по 8080 без TLS — плохая идея: логины, токены API, cookie сессии идут открытым текстом, а webhook'и от GitHub/GitLab по HTTP многие провайдеры вообще не принимают. Ставим Nginx как reverse proxy:

sudo apt install -y nginx

Конфиг /etc/nginx/sites-available/jenkins:

server {
    listen 80;
    server_name ci.вашдомен.ру;

    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-For $proxy_add_x_forwarded_for;
        proxy_set_header   X-Forwarded-Proto $scheme;
        proxy_redirect     http:// https://;

        # Jenkins отдаёт длинные ответы при стриминге логов сборки
        proxy_read_timeout 90s;
        proxy_buffering    off;
    }
}

sudo ln -s /etc/nginx/sites-available/jenkins /etc/nginx/sites-enabled/
sudo nginx -t && sudo systemctl reload nginx

Дальше выпускаем сертификат через Certbot — подробный разбор этого шага и частых граблей с продлением есть в отдельной статье про настройку Let's Encrypt SSL:

sudo apt install -y certbot python3-certbot-nginx
sudo certbot --nginx -d ci.вашдомен.ру

После этого Jenkins открывается по https://ci.вашдомен.ру с валидным сертификатом, а порт 8080 остаётся доступным только с localhost. Если хотите разобраться в самой механике reverse proxy глубже — есть отдельный разбор Nginx как reverse proxy.

Базовая безопасность и бэкапы

Jenkins с настройками по умолчанию слишком доверчив — стоит закрутить несколько гаек сразу после установки.

Файрвол. Порт 8080 наружу не нужен вообще — весь трафик идёт через Nginx на 80/443:

sudo ufw allow OpenSSH
sudo ufw allow 'Nginx Full'
sudo ufw enable

Подробнее про настройку правил — в статье про firewall UFW на Ubuntu 24.04.

Права доступа. Сразу после мастера настройки зайдите в *Manage Jenkins → Security* и включите Matrix-based или Role-based Authorization Strategy вместо дефолтного "Logged-in users can do anything". Даже единственному разработчику полезно не иметь случайного доступа к системным настройкам через неаккуратный клик.

Бэкапы. Всё важное лежит в /var/lib/jenkins: конфиги job'ов, credentials (зашифрованные мастер-ключом), история сборок, установленные плагины. Простой вариант — периодический архив с исключением workspace (он самый тяжёлый и легко восстанавливается пересборкой):

sudo tar --exclude='/var/lib/jenkins/workspace' \
  -czf /root/jenkins-backup-$(date +%F).tar.gz \
  /var/lib/jenkins

Для регулярных автоматических бэкапов с ротацией разумнее сразу настроить что-то системное — вариант с cron и rsync описан в статье про автоматические бэкапы на Ubuntu 24.04. Отдельно храните файл secrets/master.key — без него зашифрованные credentials в бэкапе не расшифровать при восстановлении на новом сервере.

Плагины и первый pipeline

Jenkins без плагинов — просто планировщик задач. Сила в экосистеме (официально заявлено больше 1800 плагинов), но ставить нужно избирательно — каждый плагин это потенциальная дыра в безопасности и точка отказа при апдейте. Базовый набор для типового CI/CD проекта:

• Git / GitHub / GitLab — интеграция с репозиториями и webhook'ами (обычно уже стоят после "suggested plugins").
• Pipeline — декларативные и scripted pipeline, основной способ описывать сборку как код.
• Credentials Binding — безопасное хранение токенов, SSH-ключей, паролей без утечки в логи сборки.
• Docker Pipeline — если сборка идёт в контейнерах или собирает Docker-образы для деплоя.
• Blue Ocean (опционально) — более наглядный UI для pipeline, полезен, если в команде не все привыкли читать текстовые логи Jenkins.

Ставятся через *Manage Jenkins → Plugins → Available plugins*.

Минимальный Jenkinsfile для проверки, что всё работает — простой pipeline, который клонирует репозиторий и гоняет тесты:

pipeline {
    agent any

    stages {
        stage('Checkout') {
            steps {
                git branch: 'main', url: 'https://github.com/example/repo.git'
            }
        }
        stage('Build') {
            steps {
                sh 'echo "Собираем проект"'
                // здесь реальная команда сборки, например npm ci && npm run build
            }
        }
        stage('Test') {
            steps {
                sh 'echo "Гоняем тесты"'
            }
        }
    }

    post {
        failure {
            echo 'Сборка упала — смотрите лог выше'
        }
    }
}

Создаёте job типа "Pipeline", вставляете этот Jenkinsfile (или, что правильнее, храните его в самом репозитории и указываете Jenkins брать pipeline оттуда — "Pipeline script from SCM"), запускаете и смотрите, что стадии проходят зелёным. Если сборка требует Docker (например, собирать образ и пушить в registry) — агенту нужен доступ к Docker-сокету, это отдельная настройка безопасности, которую стоит делать осознанно, а не давать пользователю Jenkins root-доступ к хосту через docker.sock.

Частые вопросы