Зачем это нужно
Jenkins — один из самых распространённых CI-серверов в enterprise, включая ML-платформы курса. Чтобы писать рабочий Jenkinsfile, нужно понимать архитектуру: кто планирует сборки, где выполняются команды, где хранятся секреты и как job привязана к Git-ветке.
Без этой модели легко «сломать» controller тяжёлой сборкой модели или запутаться, почему pipeline не видит Docker.
Основные идеи
Controller (бывший master). Центральный сервер Jenkins: UI, расписание, хранение конфигурации jobs, credentials (зашифрованно). Не запускайте на controller тяжёлые docker build и обучение — он для оркестрации.
Agents (nodes / executors). Машины (VM, pod в Kubernetes, bare metal), где реально выполняются шаги pipeline. Agent может иметь label: docker, gpu, linux. В Jenkinsfile указывают agent { label 'docker' } — сборка уедет на подходящую ноду.
Job types. Freestyle — UI-клики, legacy. Pipeline job — один Jenkinsfile в Git. Multibranch Pipeline — отдельная сборка на каждую ветку и PR; идеально для курса и продуктовых репозиториев.
Jenkinsfile — Declarative Pipeline. Структура:
pipeline { agent { label 'docker' } stages { stage('Checkout') { steps { checkout scm } } stage('Test') { steps { sh 'pytest tests/' } } stage('Build') { steps { sh 'docker build -t myapp:${BUILD_NUMBER} .' } } } post { always { cleanWs() } failure { echo 'Pipeline failed' } } }
agent, stages, steps, post — обязательные блоки Declarative синтаксиса.
Plugins. Jenkins расширяется плагинами: Git, Docker Pipeline, Credentials Binding, Blue Ocean (UI). Без плагина docker или podman шаг docker build на agent не сработает — agent должен иметь CLI и доступ к daemon.
Workspace. На каждый запуск создаётся рабочая директория на agent с checkout кода. cleanWs() в post освобождает диск — важно при больших ML-датасетах в тестах (лучше не копировать датасеты в repo).
BUILD_NUMBER, GIT_COMMIT. Встроенные переменные окружения для тегов образов и отчётов.
Как это выглядит на практике
Репозиторий ml-scorer с Jenkinsfile в корне. В Jenkins создают Multibranch Pipeline, указывают URL Git. Jenkins:
Сканирует ветки.
На push в
feature/add-metricsсоздаёт run.Выделяет agent с label
docker.Checkout → test → build.
Controller показывает лог каждого stage; при падении Test stage Build не выполняется (по умолчанию).
Для GPU-обучения (не inference) иногда выделяют отдельный agent gpu и stage с when { branch 'main' }, чтобы не гонять тяжёлый fit на каждый PR.
Связь с Docker (модуль 3.1): agent с установленным Docker выполняет те же команды, что вы локально. Registry credentials подключают через Jenkins Credentials (следующие уроки).
Что сделать после занятия
Создайте Declarative Pipeline с двумя stages:
LintиEcho(без Docker) — добейтесь зелёной сборки.Добавьте
agent anyvsagent { label '...' }и объясните, когда нужен label.Найдите в Jenkins docs блок
postи добавьте уведомление приfailure(email или echo в лог).