Gymterview
middle

Какова архитектура Jenkins (master/agent)

Архитектура Jenkins master/agent — это распределенная модель, в которой центральный сервер (master) координирует выполнение задач, а рабочие узлы (agents) непосредственно выполняют сборки.

Аналогия: master — это диспетчер такси, который принимает заказы и распределяет их, а agents — это водители, которые выполняют поездки. Диспетчер знает, какой водитель свободен и какой маршрут ему назначить.

Jenkins Master (Controller)

  • Основной сервер Jenkins.
  • Управляет конфигурацией, планированием и распределением задач.
  • Хранит настройки, историю сборок, результаты.
  • Предоставляет веб-интерфейс и REST API.
  • Может выполнять сборки самостоятельно, но это не рекомендуется в production (нагрузка на master снижает его стабильность).

Jenkins Agent (Node)

  • Рабочая машина, на которой выполняются сборки.
  • Подключается к master и получает задания.
  • Может иметь специфичные инструменты (JDK, Maven, Docker и т.д.).
  • Помечается метками (labels) для маршрутизации задач (например, java17, docker, linux).

Способы подключения агентов

Способ Описание Когда использовать
SSH Master подключается к агенту по SSH Linux-агенты, постоянные машины
JNLP Агент сам подключается к master через Java Web Start Windows-агенты, агенты за NAT
Docker Агент запускается как Docker-контейнер на время сборки Изолированные одноразовые сборки
Kubernetes Агенты создаются как Pod в кластере Kubernetes Облачная/контейнерная инфраструктура

Пример конфигурации агента в Jenkinsfile

Пример
pipeline {
    agent {
        label 'java17-maven'  // Сборка выполняется на агенте с данной меткой
    }
    stages {
        stage('Build') {
            steps {
                sh 'java -version'
                sh 'mvn --version'
            }
        }
    }
}

Пример с Docker-агентом

Пример
pipeline {
    agent {
        docker {
            image 'maven:3.9-eclipse-temurin-17'
            args '-v $HOME/.m2:/root/.m2'  // Кэширование зависимостей Maven
        }
    }
    stages {
        stage('Build') {
            steps {
                sh 'mvn clean package'
            }
        }
    }
}

Пример с Kubernetes-агентом

Jenkinsfile с Kubernetes Pod
pipeline {
    agent {
        kubernetes {
            yaml '''
                apiVersion: v1
                kind: Pod
                spec:
                  containers:
                  - name: maven
                    image: maven:3.9-eclipse-temurin-17
                    command: ['sleep']
                    args: ['infinity']
                  - name: docker
                    image: docker:24-dind
                    securityContext:
                      privileged: true
            '''
        }
    }
    stages {
        stage('Build') {
            steps {
                container('maven') {
                    sh 'mvn clean package'
                }
            }
        }
        stage('Docker Build') {
            steps {
                container('docker') {
                    sh 'docker build -t my-app .'
                }
            }
        }
    }
}

Вывод

Архитектура master/agent позволяет масштабировать Jenkins горизонтально: master занимается координацией, а вычислительная нагрузка распределяется между агентами. В production-среде рекомендуется запрещать сборки на master и использовать эфемерные агенты (Docker/Kubernetes) для изоляции и воспроизводимости.

На собеседовании: часто спрашивают, зачем нужны агенты и как выбрать способ подключения. Упомяните преимущества эфемерных агентов: чистая среда для каждой сборки, отсутствие «грязного» состояния и лучшая безопасность.