DEV Community

Aisalkyn Aidarova
Aisalkyn Aidarova

Posted on

Jenkins Agents — Full DevOps Lecture

#architecture #automation #cicd #devops

What problem are we solving?

In real systems, builds are heavy, diverse, and parallel. One Jenkins instance cannot safely or efficiently do everything alone.
Agents are how Jenkins scales, isolates, and survives in production.

1) What is a Jenkins Agent?

In Jenkins, there are two roles:

  • Controller (formerly “master”)

    • UI, job definitions
    • Scheduling and orchestration
    • Credentials and configuration

  • Agent (worker/node)

    • Executes the actual work:
    • git clone
    • npm install
    • docker build
    • terraform apply
    • tests, scans, packaging

Key rule:

The controller decides what to run; the agent decides where and how it runs.

2) Why DevOps NEED Jenkins Agents

Reason 1 — Performance & Scale

If everything runs on the controller:

  • CPU spikes
  • Builds slow down
  • Jenkins becomes unstable

Agents let you:

  • Run multiple builds in parallel
  • Add more workers instead of upgrading one big server

DevOps principle: horizontal scaling over vertical scaling.

Reason 2 — Isolation & Safety

Builds are risky:

  • Untrusted code
  • Random scripts
  • Docker daemon access
  • Cloud credentials usage

Agents:

  • Isolate failures
  • Prevent a bad build from crashing Jenkins
  • Allow disposable environments

Reason 3 — Multiple Environments

Real pipelines need:

  • Linux agents
  • Windows agents
  • macOS agents
  • ARM vs x86
  • Different toolchains

Agents allow right job → right machine.

Reason 4 — Security & Compliance

Best practice:

  • Controller has no Docker
  • Controller has no cloud admin keys
  • Controller does not build artifacts

Agents:

  • Get minimal permissions
  • Are rotated or destroyed
  • Follow least-privilege access

3) High-Level Architecture

Image

Image

Image

Flow:

  1. Developer pushes code
  2. Jenkins controller receives event
  3. Controller selects agent by label
  4. Agent executes pipeline steps
  5. Results returned to controller

4) Where Agents Are Used (Real DevOps Scenarios)

Scenario 1 — CI for Microservices

  • Each service builds independently

  • Agents run:

    • unit tests
    • Docker image builds

  • Multiple agents = faster CI

Scenario 2 — Infrastructure as Code (Terraform)

  • Agent has:

    • Terraform
    • AWS CLI
    • IAM role

  • Controller never touches AWS directly

Scenario 3 — Docker & Kubernetes

  • Docker builds on Docker-enabled agents
  • Kubernetes agents run inside the cluster
  • Ephemeral pods for every pipeline run

Scenario 4 — Security Scanning

  • Dedicated agents for:

    • SAST
    • Dependency scanning
    • Image scanning

  • Isolated from prod builds

Scenario 5 — Multi-OS Testing

  • Windows agent → .NET build
  • Linux agent → backend services
  • macOS agent → iOS build

5) Types of Jenkins Agents (DevOps View)

1️⃣ Static / Permanent Agents

  • Long-running VMs
  • SSH or local connection

  • Good for:

    • legacy systems
    • stable workloads

2️⃣ Docker Agents

  • Agent = container
  • Created per build
  • Destroyed after job

Image

Image

Why DevOps loves this:

  • Clean environment
  • No dependency conflicts
  • Easy version control

3️⃣ Cloud VM Agents (EC2, GCE, Azure)

  • Auto-scale based on demand
  • Shut down when idle
  • Cost-efficient

4️⃣ Kubernetes Agents (Modern Standard)

  • Agent = Kubernetes Pod
  • Fully ephemeral
  • Perfect for microservices

Image

Image

Industry standard for large orgs.

6) How Jenkins Chooses an Agent

Labels (MOST IMPORTANT)

Agents have labels like:

linux
docker
terraform
k8s
mac
Enter fullscreen mode Exit fullscreen mode

Pipeline example:

pipeline {
  agent { label 'docker' }
  stages {
    stage('Build') {
      steps {
        sh 'docker build -t app .'
      }
    }
  }
}
Enter fullscreen mode Exit fullscreen mode

Translation:

“Run this job only on agents that can do Docker builds.”

7) How Agents Connect to Jenkins

Option A — WebSocket (Recommended)

  • Outbound connection
  • No inbound ports
  • Firewall-friendly
  • Modern default

Used when:

  • Corporate networks
  • Local demos
  • Cloud agents behind NAT

Option B — SSH

  • Jenkins connects to agent
  • Common for EC2

Used when:

  • Stable VMs
  • Traditional infra

Option C — Kubernetes Plugin

  • Jenkins requests a pod
  • Pod registers as agent
  • Pod dies after job

Used when:

  • Cloud-native pipelines
  • GitOps environments

8) Agent Lifecycle (DevOps Thinking)

Type Lifecycle
Static VM Always running
Docker agent Per job
Kubernetes pod Per job
Cloud VM Auto-scale

Trend: ephemeral > permanent

9) Best Practices DevOps Must Follow

  • ❌ Don’t run builds on controller
  • ✅ Use labels correctly
  • ✅ Prefer ephemeral agents
  • ✅ Separate build, test, deploy agents
  • ✅ Rotate or destroy agents
  • ✅ Minimal permissions per agent
  • ✅ Monitor agent health

10) Common Mistakes (Interview Traps)

  • “Everything runs on Jenkins master” ❌
  • “Agents are optional” ❌
  • “One agent is enough” ❌
  • “Controller can run Docker builds” ❌

Correct mindset:

Jenkins without agents is not production-ready.

11) Interview-Ready Summary (Memorize)

“Jenkins agents are worker nodes that execute pipeline steps. We use them to scale CI/CD, isolate builds, support multiple environments, and improve security. In modern DevOps, agents are ephemeral—often Docker or Kubernetes-based—and selected via labels in Jenkinsfiles.”

Top comments (0)