Как установить и настроить Jenkins на VPS

MAATRIX

Jenkins — это ветеран CI/CD, который пережил десяток модных конкурентов именно потому, что делает одну вещь надёжно: собирает и деплоит код по правилам, которые вы сами описываете. Если вы устали от лимитов бесплатных минут в облачных CI или хотите держать весь пайплайн у себя, а не в чужом SaaS, разворачиваем Jenkins на собственном VPS с нуля — от системных требований до первого рабочего pipeline и бэкапов.

Сколько ресурсов заложить под сервер

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

Диск часто становится узким местом раньше CPU: каждая сборка тянет за собой workspace, кэш зависимостей (node_modules, .m2, pip cache) и артефакты. Если планируете держать историю сборок и логи подолгу, закладывайте диск с запасом — расширить его на лету проще, чем переносить /var/lib/jenkins на новый раздел вручную.

Для тестового стенда или пары pipeline хватит младшего тарифа VPS, а под активную команду с Docker-агентами разумнее взять сервер с 8+ ГБ RAM и NVMe — иначе сборки будут упираться в диск.

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

Ставим на Ubuntu 24.04 / Debian 12 через официальный apt-репозиторий Jenkins — это даёт автообновления пакета через apt upgrade, а не ручную возню с tar.gz.

Сначала Java — Jenkins LTS на 2026 год требует Java 17 или 21:

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

Подключаем репозиторий и ключ:

sudo mkdir -p /usr/share/keyrings
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

По умолчанию Jenkins слушает 0.0.0.0:8080. На этом этапе порт 8080 наружу лучше не открывать вообще — доступ снаружи организуем позже через reverse-proxy с HTTPS, а сам 8080 закроем фаерволом.

Первичная настройка через мастер

Открываем http://IP-сервера:8080 (временно, если сервер ещё не за прокси — например, через SSH-туннель ssh -L 8080:localhost:8080 user@server, что безопаснее прямого доступа по HTTP). Jenkins попросит пароль администратора — он лежит в файле:

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

Дальше мастер предложит установить плагины — выбирайте "Install suggested plugins" для старта, набор потом легко расширить. После установки плагинов создаётся первый администратор — не оставляйте дефолтного admin с автогенерированным паролем, заведите отдельного пользователя с нормальным паролем сразу.

Ключевой плюс Jenkins — экосистема плагинов (их тысячи): интеграции с Git, Docker, Kubernetes, Slack, SonarQube, системами уведомлений и почти любым инструментом разработки. Но именно обилие плагинов — источник половины проблем с обновлениями: не ставьте плагин "на всякий случай", если он не нужен для текущих pipeline — каждый лишний плагин это лишняя поверхность для конфликтов зависимостей при апгрейде.

HTTPS и доступ через reverse-proxy

Держать Jenkins голым на 8080 по HTTP — плохая идея: в веб-интерфейс уходят логины, токены и секреты сборок. Ставим nginx перед Jenkins и получаем сертификат, как описано в статье про Let's Encrypt SSL на VPS — принцип для Jenkins тот же, но конфиг nginx для него требует особых заголовков из-за WebSocket-соединений, которые использует агент-протокол и CLI:

server {
    listen 443 ssl;
    server_name jenkins.example.com;

    location / {
        proxy_pass         http://127.0.0.1:8080;
        proxy_redirect     default;
        proxy_http_version 1.1;

        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_set_header   Upgrade           $http_upgrade;
        proxy_set_header   Connection        "upgrade";

        client_max_body_size 100m;
    }
}

client_max_body_size стоит увеличить, если через веб-интерфейс планируете загружать большие артефакты или архивы — иначе nginx будет обрывать запрос на дефолтном лимите. Если предпочитаете декларативный конфиг вместо ручного nginx, вариант с Traefik в качестве reverse-proxy тоже подойдёт — там сертификаты обновляются автоматически без отдельного certbot-таймера.

После того как HTTPS настроен, в разделе Jenkins "Manage Jenkins → System" укажите правильный Jenkins URL (https://jenkins.example.com/) — иначе ссылки в уведомлениях и webhook-колбэках будут генерироваться неправильно.

Права доступа и базовая безопасность

Дефолтная установка Jenkins после мастера уже включает Matrix-based security с одним администратором — это нормальная стартовая точка, но для команды стоит донастроить:

• Отключите анонимный доступ на чтение, если Jenkins не планируется публиковать наружу как открытую панель статуса сборок ("Manage Jenkins → Security → Authorization").
• Поставьте плагин Role-based Authorization Strategy, если людей больше двух — так проще выдавать права по ролям (разработчик видит только свои job, релиз-менеджер может деплоить в prod), а не вручную дёргать матрицу на каждого пользователя.
• Отключите Jenkins CLI по remoting-протоколу ("Manage Jenkins → Security"), если не используете — в разное время в нём находили уязвимости, а закрытая по умолчанию функция снижает риск.
• Заведите отдельных сервисных пользователей для webhook-интеграций (GitHub/GitLab), а не общий admin-токен на все случаи.

На уровне сервера закройте порт 8080 снаружи и оставьте только 80/443 для web и 22 для SSH — как настроить UFW-фаервол на VPS подробно расписано отдельно, но суть команд такая:

sudo ufw allow OpenSSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw deny 8080/tcp
sudo ufw enable

Credentials (SSH-ключи, токены доступа к репозиториям, пароли к registry) храните только в разделе Jenkins Credentials, а не в переменных окружения job или тексте Jenkinsfile — так они не светятся в логах сборки и истории git.

Первый pipeline и агенты сборки

Современный подход — Declarative Pipeline, описанный файлом Jenkinsfile прямо в репозитории проекта. Минимальный пример для веб-приложения:

pipeline {
    agent any

    stages {
        stage('Checkout') {
            steps {
                git branch: 'main', url: 'git@github.com:org/app.git'
            }
        }
        stage('Build') {
            steps {
                sh 'npm ci'
                sh 'npm run build'
            }
        }
        stage('Test') {
            steps {
                sh 'npm test'
            }
        }
        stage('Deploy') {
            steps {
                sh 'rsync -avz dist/ user@prod-server:/var/www/app/'
            }
        }
    }

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

Создайте job типа "Multibranch Pipeline" — Jenkins сам подхватит Jenkinsfile из каждой ветки и будет собирать её при пуше. Триггер по коммиту настраивается через webhook в GitHub/GitLab (Settings → Webhooks → URL вида https://jenkins.example.com/github-webhook/), а не через периодический опрос — опрос лишний раз грузит и Jenkins, и Git-провайдера.

Для изоляции сборок от системы хоста и друг от друга многие переносят выполнение в Docker-агенты — тогда каждая сборка стартует в чистом контейнере с нужным набором инструментов, а не тащит зависимости прямо на VPS. Для этого на сервере нужен Docker — можно поставить его так же, как в статье про установку Docker на Ubuntu 24.04, затем добавить пользователя jenkins в группу docker (sudo usermod -aG docker jenkins) и использовать agent { docker { image 'node:22' } } в pipeline вместо agent any.

Число одновременных executor'ов (Manage Jenkins → Nodes) разумно держать примерно равным числу физических ядер сервера — больше executor'ов не ускорит сборки, если они упираются в CPU, а лишь заставит их конкурировать за ресурсы.

Бэкапы, обновления и типичные проблемы

Всё состояние Jenkins — конфиги job, история сборок, плагины, credentials в зашифрованном виде — лежит в /var/lib/jenkins. Простейший рабочий бэкап — cron с архивированием этой директории:

0 3 * * * tar -czf /backup/jenkins-$(date +\%F).tar.gz \
  --exclude='/var/lib/jenkins/workspace' \
  --exclude='/var/lib/jenkins/caches' \
  /var/lib/jenkins

Исключить workspace и caches стоит обязательно — там лежат временные файлы сборок, которые пересоздаются заново и только раздувают архив. Конфиги job и pipeline лучше дополнительно держать в git (job-as-code через Jenkins Configuration as Code plugin) — тогда восстановление сервера с нуля не зависит от бэкапа целиком.

Обновляйте Jenkins через штатный apt upgrade jenkins, но перед этим:

1. Проверьте changelog LTS-релиза на предмет breaking changes в плагинах, которые используете.
2. Обновляйте плагины постепенно, не все разом — если после обновления что-то ломается, проще найти виновника.
3. На активном проде тестируйте обновление сначала на копии сервера, а не сразу в бою.

Частая проблема — Jenkins падает по нехватке памяти при параллельных сборках. Лечится ограничением heap в /etc/default/jenkins (переменная JAVA_ARGS, например -Xmx2g) и уменьшением числа executor'ов, а не бездумным увеличением RAM сервера — сначала стоит понять, что именно ест память.

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