Jenkins Architecture

Jenkins Architecture: Controller and Agents

Jenkins separates coordination from execution. The controller provides the UI, API, scheduling, credentials integration, and pipeline state. Agents supply operating systems, tools, and compute. This separation limits controller load and enables heterogeneous or elastic build capacity.

Core ideas

• A node is a configured machine or runtime; an agent process connects that node to the controller.
• An executor is one concurrent-work slot. More executors than the machine can support causes contention.
• Labels describe capabilities such as linux, docker, or arm64; label expressions match pipeline demand.
• The queue holds tasks until a compatible online executor is free.

How it works

A pipeline requests an agent. Jenkins matches its label, capacity, usage policy, and permissions, then allocates a workspace. Connection methods include inbound agents, SSH, and cloud-provisioned workers. Keep controller executors at zero for most production installations so user builds do not compete with orchestration.

Configuration example

pipeline {
  agent none
  stages {
    stage('Linux build') {
      agent { label 'linux && docker' }
      steps { sh 'make package' }
    }
    stage('Windows check') {
      agent { label 'windows' }
      steps { bat 'gradlew.bat check' }
    }
  }
}

The sample is intentionally small. In a real installation, replace hostnames, labels, credentials, retention, and commands with reviewed values from your own platform standards.

Production guidance

• Give labels capability meaning instead of tying pipelines to a single machine name.
• Isolate workloads with different trust levels and clean workspaces between builds.
• Monitor queue length, provisioning delay, executor saturation, agent disconnects, CPU, memory, and disk.

The chapter quiz follows this lesson and tests both terminology and safe operating choices.