Автоматический деплой через Jenkins: установка и CI/CD пайплайн

Содержание

В материале рассказали, как установить Jenkins на сервер или VPS, подключить репозиторий, собрать рабочий пайплайн и настроить автоматический деплой проекта.

Ручной сборке не место в современном процессе разработки. Jenkins позволяет автоматизировать деплой и упростить выпуск обновлений. Рассказали в статье, как это делается. Когда нужно выкатить обновление, начинается самое интересное. Что-то забыли, что-то не собралось, где-то прод внезапно лёг. Чтобы обновления не превращались в стресс, лучше один раз настроить автоматическое развёртывание. Рассмотрим пошагово: установка Jenkins, подключение репозитория, настройка пайплайна и автоматический деплой.

Аренда VPS/VDS от 219 руб/месяц

Преимущества VPS в AdminVPS:

✓ Бесплатное администрирование

✓ Только быстрые NVMe-диски

✓ Защита от DDoS-атак

✓ Быстрая техподдержка

Аренда VPS/VDS виртуального сервера от AdminVPS — это прозрачная и честная услуга с доступной ценой

Установка Jenkins на сервер или VPS с Ubuntu

Начать стоит с подготовки Linux-сервера. На Ubuntu установите JDK (Java 11+) и обновите список пакетов. Затем добавьте официальный репозиторий Jenkins и ключ разработчиков:

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

После установки служба Jenkins запустится автоматически. Она слушает порт 8080. Если включён файрвол, не забудьте открыть этот порт (ufw allow 8080 или аналогично).

При первом запуске Jenkins сгенерирует временный пароль администратора. Найти его можно в файле:

/var/lib/jenkins/secrets/initialAdminPassword

Откройте в браузере

http://<ваш_сервер>:8080

введите пароль и завершите первоначальную настройку через веб-интерфейс. При первом запуске мастер установки предложит установить рекомендованные плагины и создать учётную запись администратора — выберите эти опции для быстрой настройки. Это даст стандартный набор инструментов для дальнейшей работы.

Создание CI/CD пайплайна

Когда Jenkins готов, приступайте к созданию конвейера (pipeline). В интерфейсе выберите New Item → Pipeline, задайте имя задачи и в настройках укажите Pipeline script from SCM. Подключите ваш Git-репозиторий: введите URL (через SSH или HTTPS) и выберите способ авторизации, например, SSH-ключ или токен доступа.

Обычно весь пайплайн описывают в файле Jenkinsfile, который лежит в корне проекта. Ниже — пример рабочего Jenkinsfile для Node.js-приложения с установкой, тестами, деплоем и откатом на случай ошибок. Этот сценарий можно взять за основу и доработать под конкретные задачи.

pipeline {
  agent any
  tools { nodejs 'Node 14' }
  environment {
    NODE_ENV = 'production'
    API_TOKEN = credentials('api-token-id')
  }
  stages {
    stage('Install') {
      steps {
        // Устанавливаем зависимости и билдим
        sh 'npm install && npm run build'
      }
    }
    stage('Test') {
      steps {
        // Запускаем модульные тесты
        sh 'npm test'
      }
    }
    stage('Deploy') {
      steps {
        // Блокировка ресурса, чтобы не было параллельных деплоев
        lock('deploy_lock') {
          // Подключаем SSH-агент с ключом и выполняем команды на сервере
          sshagent(['production-key']) {
            sh '''
              ssh deploy@prod-server << EOF
              cd /var/www/myapp
              git pull
              npm install --production
              pm2 restart myapp
              EOF
            '''
          }
        }
      }
    }
  }
  post {
    failure {
      echo 'Сборка провалилась. Откатываемся к предыдущей версии...'
      sshagent(['production-key']) {
        sh '''
          ssh deploy@prod-server << EOF
          cd /var/www/myapp
          git reset --hard HEAD~1
          pm2 restart myapp
          EOF
        '''
      }
    }
  }
}

В этом пайплайне этапы Install и Test отвечают за установку зависимостей, сборку проекта и запуск тестов. На шаге Deploy Jenkins подключается к серверу по SSH от имени пользователя deploy, переходит в папку с приложением и вытягивает свежий код. Команда lock('deploy_lock') не даёт запустить второй деплой, пока не завершён первый, это защита от накладок.

Доступ к серверу и чувствительные данные, вроде SSH-ключей и токенов, берутся из Jenkins Credentials. Например, credentials('api-token-id') и sshagent(['production-key']) — это ссылки на заранее добавленные секреты. Пароли не светятся в логах и не попадают в код.

Если что-то идёт не так, блок post с failure запускает откат. Jenkins возвращает репозиторий на предыдущий коммит и перезапускает приложение. Так проект быстро приходит в рабочее состояние, даже если сборка упала.

Для удобства вы можете установить плагин Blue Ocean: он предложит визуальный конструктор пайплайна. Через Blue Ocean достаточно подключить репозиторий и выбрать ветку. Он сам найдёт Jenkinsfile и покажет готовый конвейер в наглядном виде. Также можно настроить Multibranch Pipeline: Jenkins автоматически создаст задачу для каждой ветки, где есть Jenkinsfile.

Подключение к продакшен-серверу

Подключение к серверу — важная часть автоматического деплоя. На Jenkins-сервере нужно сгенерировать SSH-ключи или взять уже готовые. Публичный ключ добавьте на продакшен-сервер в файл ~/.ssh/authorized_keys от имени пользователя, под которым будет идти деплой, например, deploy. Приватный ключ загрузите в Jenkins через меню Credentials, выбрав тип SSH Username with private key, и укажите того же пользователя.

Если сервера пока нет, можно взять VPS от AdminVPS. Он отлично работает с Jenkins, не создаёт проблем с портами и зависимостями. А если что-то пойдёт не так, техподдержка всегда на связи.

Пароли, токены и другие секреты тоже лучше хранить в Jenkins Credentials. API-ключи, доступ к базе, логины — всё это удобно сохранять как Secret Text или Username/Password. В Jenkinsfile такие переменные подключают через withCredentials или через environment.Это обеспечивает безопасность: переменные не отображаются в логах и не попадают в репозиторий.

Если проект использует переменные окружения, их можно задать прямо в Jenkins или описать в Jenkinsfile, например:

environment {
  NODE_ENV = 'production'
  DB_PASSWORD = credentials('db-password-id')
}

После этого в скриптах переменные будут доступны как env.NODE_ENV или env.DB_PASSWORD.

Отладка пайплайнов и полезные плагины

Чтобы пайплайн работал стабильно, стоит установить нужные плагины и заранее продумать отладку.

Сначала добавьте Git Plugin — он отвечает за клонирование репозиториев и работу с ветками. Плагин Pipeline нужен для поддержки сценариев, написанных в формате Declarative и Scripted.

Для JavaScript-проектов пригодится NodeJS Plugin. Он помогает задать нужную версию Node прямо внутри Jenkins. Интерфейс Blue Ocean делает пайплайн наглядным: видно, на каком этапе сейчас сборка, что прошло успешно, а где возникли проблемы.

Настройка автоматического развёртывания через Jenkins

Если нужно подключаться к серверам по SSH, установите SSH Agent и Publish Over SSH. Через них можно отправлять команды или файлы на удалённую машину прямо из пайплайна. Плагины AnsiColor и Timestamper улучшают читаемость логов: добавляют цвет и временные метки.

Lockable Resources помогает избежать накладок при одновременных сборках. Достаточно дать ресурсу понятное имя, например, prod-deploy, и Jenkins не будет запускать несколько деплоев сразу. А с помощью Credentials Binding проще работать с переменными окружения и скрывать секреты в логах.

Если сборка упала, откройте Console Output — там видно, из-за чего всё сломалось. В интерфейсе Blue Ocean легко отследить, на каком этапе возник сбой. А если проблема системная, проверьте логи Jenkins, они лежат в /var/log/jenkins/jenkins.log.

Для автоматического запуска задач настройте триггеры. Jenkins может слушать вебхуки из GitHub или GitLab. Если с вебхуками возникнут сложности, включите регулярную проверку с помощью pollSCM. Например, правило H/5 * * * * означает проверку изменений каждые пять минут. Лучше использовать оба варианта сразу.

Заключение

CI и CD не решают все проблемы, но убирают большую часть хаоса. Когда система сама проверяет код, запускает сборку и выкатывает обновление, команде проще сосредоточиться на продукте.

Автоматизация делает процесс прозрачным и предсказуемым. Всё под контролем, а значит и новые релизы перестают быть поводом для нервов.

Читайте в блоге: