3.2.2 · блок 3

Устройство Jenkins: controller, agents, Jenkinsfile

Зачем это нужно

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:

1. Сканирует ветки.

2. На push в feature/add-metrics создаёт run.

3. Выделяет agent с label docker.

4. 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 any vs agent { label '...' } и объясните, когда нужен label.
[ ] Найдите в Jenkins docs блок post и добавьте уведомление при failure (email или echo в лог).

Официальные материалы

Открыть интерактивную версию