Jenkins или Drone CI: что выгоднее и когда

MAATRIX

Рано или поздно перед любой командой встаёт вопрос: на чём собирать CI/CD — на Jenkins, который все знают и все ругают, или на Drone CI, который проще, но заметно уже по возможностям. Выбор не абстрактный: он определяет, сколько RAM вы будете держать под CI-сервер, сколько времени уйдёт на поддержку и насколько быстро новый разработчик разберётся в пайплайнах. Разберём оба варианта честно, без «Jenkins мёртв» и «Drone — это несерьёзно» — у каждого есть свои сценарии, где он выигрывает с большим отрывом.

Что это вообще такое и чем они принципиально отличаются

Jenkins — это универсальный автоматизационный сервер, который живёт с 2011 года (изначально Hudson). Он написан на Java, работает как отдельное Java-приложение с веб-интерфейсом, хранит конфигурацию заданий (jobs) в собственной базе на диске и умеет буквально всё — от сборки кода до триггера физического принтера через плагин, если такой плагин кто-то написал. А плагинов больше 1800 в официальном Update Center. Jenkins не привязан к Docker и не заточен под контейнеры изначально — он появился раньше, чем контейнеризация стала стандартом, и это чувствуется в архитектуре.

Drone CI — история моложе (первый релиз в 2014-м) и с самого начала построена вокруг контейнеров: каждый шаг пайплайна — это отдельный Docker-контейнер, конфигурация — YAML-файл .drone.yml в репозитории, а сам сервер — это по сути тонкая прослойка между вашей Git-платформой (GitHub, GitLab, Gitea, Bitbucket) и Docker-раннерами. Drone принципиально проще как система: меньше сущностей, меньше настроек через веб-интерфейс, почти всё — в YAML-файле рядом с кодом.

Ключевая разница на уровне философии:

• Jenkins — конфигурация «через интерфейс + Groovy DSL», множество источников правды (UI, Jenkinsfile, плагины), максимальная гибкость.
• Drone CI — конфигурация «только YAML в репозитории», один источник правды, минимум ручной настройки через UI, но и меньше возможностей из коробки.

Если вы уже разворачивали Jenkins на Ubuntu 24.04 или Drone CI с нуля, разница в подходе видна уже на этапе установки.

Требования к серверу: сколько ресурсов реально нужно

Это первое, что стоит прикинуть, потому что разница в footprint ощутимая.

Jenkins — Java-приложение с JVM, и это заметно на RAM даже в простое:

JVM сама по себе съедает от 512 МБ до 1 ГБ на старте, даже если задач нет вообще. Плюс каждый плагин добавляет свои классы в память, а сборочные агенты (если запускаете их на том же хосте) добавляют ещё нагрузку сверху.

Drone CI — сервер написан на Go, стартует легковесно:

Сам сервер Drone почти ничего не ест — основная нагрузка приходится на раннеры, которые поднимают Docker-контейнеры под задачи. То есть реальный расход памяти у Drone сильно зависит от того, что именно вы собираете (тяжёлая сборка Java-проекта в контейнере съест память вне зависимости от CI-системы), а не от самого CI-сервера.

Ориентир простой: если берёте VPS на 2 ГБ RAM под CI и больше ничего на нём не крутите — Drone влезет комфортно, Jenkins будет впритык, особенно с несколькими плагинами. Если посчитать заранее нужные ресурсы лень — есть отдельные разборы, сколько RAM нужно для Jenkins и сколько RAM нужно для Drone CI с более подробной разбивкой по нагрузке.

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

Оба варианта проще всего поднимать через Docker — так меньше зависимостей на хосте и легче переносить систему на другой сервер.

Jenkins через docker-compose.yml:

services:
  jenkins:
    image: jenkins/jenkins:lts-jdk17
    restart: unless-stopped
    ports:
      - "8080:8080"
      - "50000:50000"
    volumes:
      - jenkins_home:/var/jenkins_home
      - /var/run/docker.sock:/var/run/docker.sock
volumes:
  jenkins_home:

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

docker exec jenkins cat /var/jenkins_home/secrets/initialAdminPassword

Дальше — мастер настройки в браузере: выбор плагинов (обычно ставят «suggested», это 30-50 штук сразу), создание пользователя, базовая настройка. На первый рабочий пайплайн у человека, который делает это впервые, обычно уходит 30-60 минут — не потому что сложно, а потому что шагов много.

Drone CI требует чуть больше подготовки на старте, потому что нужно сразу зарегистрировать OAuth-приложение в вашей Git-платформе (GitHub, GitLab или Gitea), а сервер и раннер — это два отдельных контейнера, связанных общим DRONE_RPC_SECRET:

services:
  drone-server:
    image: drone/drone:2
    restart: unless-stopped
    ports: ["80:80", "443:443"]
    volumes: ["drone_data:/data"]
    environment:
      - DRONE_GITEA_SERVER=https://git.example.com
      - DRONE_GITEA_CLIENT_ID=your_client_id
      - DRONE_GITEA_CLIENT_SECRET=your_client_secret
      - DRONE_RPC_SECRET=long_random_secret
      - DRONE_SERVER_HOST=drone.example.com
      - DRONE_SERVER_PROTO=https

  drone-runner:
    image: drone/drone-runner-docker:1
    restart: unless-stopped
    ports: ["3000:3000"]
    volumes: ["/var/run/docker.sock:/var/run/docker.sock"]
    environment:
      - DRONE_RPC_HOST=drone-server
      - DRONE_RPC_SECRET=long_random_secret
      - DRONE_RUNNER_CAPACITY=2

volumes:
  drone_data:

После запуска заходите на drone.example.com, логинитесь через Git-платформу, активируете нужный репозиторий одним переключателем — и всё, пайплайн уже описывается в .drone.yml рядом с кодом. Никакого мастера настройки, никакого выбора плагинов. Минус в том, что если у вас self-hosted Gitea или GitLab — придётся повозиться с корректными redirect URL и DRONE_SERVER_HOST, иначе авторизация будет падать с невнятной ошибкой.

Синтаксис пайплайнов: Groovy vs YAML

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

Jenkinsfile (Declarative Pipeline):

pipeline {
    agent any
    stages {
        stage('Build') {
            steps {
                sh 'docker build -t myapp:${BUILD_NUMBER} .'
            }
        }
        stage('Test') {
            steps {
                sh 'docker run --rm myapp:${BUILD_NUMBER} npm test'
            }
        }
        stage('Deploy') {
            when { branch 'main' }
            steps {
                sh 'docker compose up -d --force-recreate'
            }
        }
    }
}

.drone.yml (эквивалент):

kind: pipeline
type: docker
name: default

steps:
  - name: build
    image: docker
    volumes:
      - name: dockersock
        path: /var/run/docker.sock
    commands:
      - docker build -t myapp:${DRONE_BUILD_NUMBER} .

  - name: test
    image: node:20
    commands:
      - npm test

  - name: deploy
    image: docker/compose:latest
    when:
      branch:
        - main
    commands:
      - docker compose up -d --force-recreate

volumes:
  - name: dockersock
    host:
      path: /var/run/docker.sock

Groovy в Jenkinsfile — это полноценный язык программирования: можно писать функции, циклы, условия любой сложности, шарить библиотеки между проектами (Shared Libraries). Это мощно, но и это же источник боли — Jenkinsfile легко превращается в 300-строчный скрипт, который понимает только его автор, а отладка синтаксических ошибок Groovy в контексте Jenkins временами превращается в квест с перезапуском джобы ради одной опечатки.

YAML в Drone декларативнее и жёстче: нет циклов, нет условной логики кроме when, зато файл читается за 30 секунд человеком, который видит его впервые. Для сложных сценариев (матрица тестов, динамическая генерация шагов) YAML начинает ограничивать — приходится городить multi-pipeline конфиги или выносить логику в сами шаги (например, bash-скрипт внутри контейнера).

Плагины и экосистема против Docker-first минимализма

Jenkins берёт возможностями. Нужна интеграция с Jira, Slack, SonarQube, Kubernetes, Ansible, любой SCM, любой облачный провайдер — плагин почти наверняка уже есть, часто не один. Это огромный плюс для legacy-инфраструктуры и энтерпрайза: если у вас 15 разных систем, с которыми должен взаимодействовать CI, Jenkins с высокой вероятностью закроет это без написания кастомного кода.

Обратная сторона — управление плагинами само по себе становится работой. Плагины конфликтуют по версиям, обновление Jenkins core иногда ломает совместимость со старыми плагинами, а security-патчи выходят регулярно из-за огромной площади атаки. Бэкап и восстановление Jenkins — отдельная тема именно из-за того, что состояние размазано между jenkins_home, конфигурацией плагинов и job-специфичными файлами.

Drone принципиально не имеет системы плагинов в привычном смысле. Вместо этого — любой Docker-образ можно использовать как шаг пайплайна: нужна интеграция со Slack — берёте образ plugins/slack или пишете свой в 20 строк на любом языке. Это чище архитектурно: нет версионного ада и security-дыр в чужом коде плагина, но готовых решений на редкий кейс может не найтись — придётся собирать самому.

Когда выбирать что: сценарии из практики

Практический вывод: если вы стартап или небольшая команда, которая гоняет Docker-образы, деплоит на VPS и хочет, чтобы пайплайн описывался прямо в репозитории — Drone CI сэкономит и ресурсы сервера, и время на поддержку. Если вы средняя или крупная компания с зоопарком технологий, где CI должен дружить с десятком внутренних систем, а Groovy для части команды не пугающее слово — Jenkins окупит свою тяжеловесность гибкостью.

Есть и третий вариант, который часто упускают: если вам не нравится ни Groovy Jenkins, ни жёсткость YAML Drone, посмотрите в сторону встроенного CI/CD у самой Git-платформы — Gitea Actions или GitLab CI, и тогда отдельный CI-сервер вообще не нужен, экономите ресурсы на всей связке.

Смешивать оба варианта тоже реально: часть команд держит Jenkins для тяжёлых legacy-сборок и параллельно Drone для новых микросервисов — но это уже двойная административная нагрузка, оправданная только на переходный период.

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