Как установить и настроить Open Source стэк для CI/CD: от выбора до первого пайплайна

Внедрение практик непрерывной интеграции и доставки (CI/CD) — обязательный этап для современной IT-команды, стремящейся к скорости, качеству и надежности. Покупка коробочных решений вроде Jenkins Enterprise или GitLab Ultimate может быть дорогой, особенно для стартапов или внутренних проектов. На помощь приходит мощный мир Open Source. Собрать свой CI/CD стэк из открытых компонентов — задача выполнимая и часто более гибкая. Давайте разберемся, как это сделать.

Первым делом определяемся с архитектурой. Классический стек включает: 1) Сервер непрерывной интеграции (оркестратор пайплайнов), 2) Систему контроля версий (VCS), 3) Репозиторий артефактов, 4) Контейнерный реестр, 5) Систему мониторинга пайплайнов. В Open Source-мире у нас есть выбор для каждой роли.

Сервер CI/CD. Jenkins — ветеран, обладающий огромным сообществом и тысячами плагинов. Его установка проста: это WAR-файл, который можно запустить командой `java -jar jenkins.war`. Для production-среды лучше установить его как службу и настроить обратный прокси (nginx) для безопасного доступа по HTTPS. Более современная альтернатива — Drone.io или Tekton. Drone легковесен, использует декларативные пайплайны в формате YAML, хранящиеся прямо в репозитории, и работает через Docker. Установка через Docker Compose занимает минуты.

Система контроля версий. Хотя GitHub и GitLab популярны как SaaS, их можно установить локально. GitLab CE — монолитное, но невероятно мощное решение, которое включает в себя не только Git-репозиторий, но и встроенный CI/CD (GitLab CI), реестр контейнеров и трекер задач. Установка через официальный Omnibus-пакет для Linux проста и хорошо документирована. Gitea или Forgejo — легковесные альтернативы, фокусирующиеся только на Git. Их установка также проста, часто через Docker.

Репозиторий артефактов. Для хранения собранных пакетов (NuGet, npm, Maven) отлично подходит Sonatype Nexus Repository OSS или JFrog Artifactory OSS. Nexus устанавливается как Java-приложение. После загрузки архива нужно распаковать его, прописать переменные окружения и запустить скрипт запуска. Важно настроить хранилище (blob store) на диск с достаточным объемом.

Контейнерный реестр. Docker Registry от самого Docker — стандарт де-факто. Установка тривиальна: `docker run -d -p 5000:5000 --restart=always --name registry registry:2`. Для production необходимо добавить аутентификацию (через nginx и базовую аутентификацию или токены) и TLS-сертификат.

Рассмотрим пошаговый пример установки стека на чистый Ubuntu-сервер.

Шаг 1: Базовая подготовка. Обновляем пакеты, устанавливаем Docker и Docker Compose, Java (для Jenkins или Nexus), Git.

Шаг 2: Устанавливаем GitLab CE. Добавляем репозиторий GitLab, устанавливаем пакет `gitlab-ce`. Во время установки запрашивается пароль для root. После установки правим конфигурационный файл `/etc/gitlab/gitlab.rb`: задаем внешний URL (`external_url 'https://gitlab.your-company.com'`), настраиваем встроенный LetsEncrypt для SSL. Запускаем реконфигурацию: `sudo gitlab-ctl reconfigure`. Процесс долгий, но в итоге вы получаете работающий веб-интерфейс.

Шаг 3: Устанавливаем Jenkins. Скачиваем последнюю LTS-версию Jenkins.war. Создаем systemd-сервис для его управления. В файле сервиса указываем запуск от отдельного пользователя `jenkins` с нужными параметрами памяти. После первого запуска из логов получаем пароль администратора. В мастере настройки устанавливаем рекомендуемые плагины, создаем первого администратора.

Шаг 4: Настраиваем интеграцию. В GitLab создаем проект. В настройках проекта находим раздел CI/CD и добавляем нового Runner (агент, который выполняет задания). Выбираем тип `shell` или `docker`. На сервере с Jenkins устанавливаем плагин "GitLab", в настройках Jenkins добавляем соединение с GitLab, используя сгенерированный Access Token. Теперь Jenkins может видеть события из GitLab (push, merge request).

Шаг 5: Пишем первый пайплайн. В корень проекта в GitLab добавляем файл `.gitlab-ci.yml`. Простейший пример для Node.js-проекта может выглядеть так: определяем стадии `build`, `test`, `deploy`. Для каждой стадии указываем образ Docker и команды для выполнения. GitLab Runner автоматически подхватит этот файл и начнет выполнение при следующем push.

Ключевые моменты после установки: безопасность (регулярные обновления, настройка брандмауэра, использование HTTPS), резервное копирование (для GitLab есть встроенная утилита `gitlab-backup`, для Jenkins нужно копировать директорию `JENKINS_HOME`), мониторинг (можно использовать Prometheus, который уже экспортирует метрики и Jenkins, и GitLab).

Такой собранный из open source-компонентов CI/CD стэк дает полный контроль над процессом, не привязывает к вендору и масштабируется под нужды команды. Первоначальные затраты на настройку окупаются гибкостью и отсутствием лицензионных отчислений.