Agents, Nodes, and Executors¶
Overview¶
Design a safe agent topology: nodes, labels, executors, and tool installations.
The built-in node (controller) must not run untrusted builds. Static agents, inbound agents, and later Docker/Kubernetes agents provide isolation. Understand connectivity basics and why workspaces live on agents.
This is a core tutorial in Module 6 · Agents, Nodes, and Executors of the REBASH Academy Jenkins for Cloud & DevOps Engineers series — written for Cloud, DevOps, Platform, and SRE engineers.
Prerequisites¶
- Completed prior modules in this track where linked in frontmatter
- Git and Docker for lab workflows
- Running Jenkins LTS from Installing Jenkins LTS when a live controller is required
Learning Objectives¶
By the end of this tutorial, you will be able to:
- Explain why builds must not run on the built-in node
- Define labels and bind a Pipeline
agent { label '…' } - Relate executors to concurrency and disk/CPU pressure
- Describe tool installations versus installing tools on the agent image
Architecture¶
This topic’s control points and relationships are shown below.
Theory¶
What it is¶
A node is a machine (or container) registered with Jenkins. Each node has one or more executors — parallel build slots. Labels are tags (linux, docker, gpu) that Pipelines select with agent { label 'linux' }. Tool installations (JDK, Maven, Gradle) can be managed globally and auto-installed on agents, but immutable agent images are often cleaner in cloud-native setups.
Agent connectivity: inbound agents dial out to the controller (port 50000 in classic JNLP setups) or use WebSocket; outbound SSH agents are started by the controller.
Why it matters¶
A compromised build on the controller can read credentials files, change jobs, or encrypt-lock JENKINS_HOME. Isolation is a security control, not just scaling. Labels also keep Windows, macOS, and Linux toolchains from colliding on one host.
How it works¶
- In Manage Jenkins → Nodes, inspect the built-in node; set its executors to
0in production-like labs when you have another agent. - Add an agent (SSH or inbound) with labels, or simulate policy in notes if you lack a second VM.
- Point Pipeline
agent { label 'linux' }at that label. - Observe the workspace path on the agent, not under the controller’s job config alone.
- Prefer baking tools into agent images over snowflake installs.
See Distributed builds style guidance in the handbook under using/scaling topics.
Key concepts and comparisons¶
| Policy | Rationale |
|---|---|
| Executors on built-in = 0 | Protect control plane |
| Labels per capability | Correct toolchain selection |
| One heavy job type per pool | Predictable capacity |
| Ephemeral agents later | Clean workspaces each run |
| Approach | Trade-off |
|---|---|
| Static VMs | Simple, always-on cost |
| Docker agent | Reproducible tools |
| Kubernetes pods | Elastic, needs cluster |
Common pitfalls¶
- Leaving built-in executors at 2 “just for convenience”.
- Oversubscribing executors on a small VM (thrashing).
- No disk cleanup — workspaces fill the agent.
- Mixing trusted release jobs and untrusted PR builds on the same writable agent without isolation.
Hands-on Lab¶
Create a workspace for this tutorial.
Focus: document a zero-executor controller policy and labelled agent Pipeline
Step 1 – Primary exercise¶
cat > agent-policy.md << 'EOF'
# Agent policy (lab)
- Built-in node executors: 0 in production
- Required labels: linux, docker
- Pipeline snippet:
agent { label 'linux' }
- Tools: prefer image-baked JDK/Maven over global auto-install when possible
EOF
cat > Jenkinsfile << 'EOF'
pipeline {
agent { label 'linux' }
stages {
stage('Where am I') {
steps {
sh 'uname -a; pwd; echo "Run on labelled agent, not controller"'
}
}
}
}
EOF
grep -E "label|executors|Built-in" agent-policy.md Jenkinsfile
Step 2 – Validate label directive¶
Final cleanup¶
# Keep ~/rebash-jenkins/ for later tutorials; stop Compose only if you are done with the controller
# docker compose -f ~/rebash-jenkins/module-02/docker-compose.yml down # optional; omit -v to keep JENKINS_HOME
Validation¶
- Lab commands run under
~/rebash-jenkins/module-06/ - You can explain each Theory section in your own words
- You used current Jenkins LTS / Pipeline practices where they apply
- You can describe one production failure mode for this topic
Code Walkthrough¶
Production practice for Agents, Nodes, and Executors always combines:
- Inspect before you change (status, plan, logs, dry-run)
- Prefer reversible, documented changes (Git, Jenkinsfile, JCasC)
- Capture evidence (console logs, plan artefacts) for handovers
- Prefer current LTS and supported plugins over legacy shortcuts
- Least privilege — escalate credentials only when required
Keep runbooks short enough to follow under pressure. Automate checks; keep humans for judgement.
Security Considerations¶
- Treat Jenkins credentials and cloud tokens as privileged — never commit them
- Keep builds off the built-in node; isolate untrusted pull requests
- Prefer short-lived auth (OIDC-style patterns, scoped RBAC) over long-lived keys
- Validate blast radius before apply/deploy/delete operations
- Collect audit logs; limit who can administer the controller
Common Mistakes¶
Builds on the built-in node
Set built-in executors to zero once agents exist; treat violations as severity-one security debt.
Unlimited executors
Match executor count to CPU/memory; watch queue time versus host thrash.
Shared mutable agents for PRs
Untrusted branches need isolation (ephemeral containers/pods).
Best Practices¶
- Encode Agents, Nodes, and Executors changes as code and review them in pull requests
- Prefer Jenkins LTS and pinned agent/tool versions
- Keep builds off the controller; use labelled agents
- Least privilege for credentials and cluster/cloud access
- Destroy or stop lab resources; keep
~/rebash-jenkins/notes for the track
Troubleshooting¶
| Symptom | Likely cause | Fix |
|---|---|---|
| Job stuck in queue | No matching agent/label or executors busy | Check nodes, labels, and executor counts |
| Checkout / SCM failure | Credentials, URL, or permissions | Verify credential ID and repository access |
| Pipeline CPS / script error | Syntax, sandbox, or library mismatch | Read error line; validate Jenkinsfile; pin library version |
| Plugin / UI broken after update | Incompatible plugin set | Restore backup; disable suspect plugin on test controller |
| Disk full on agent/controller | Workspaces or old builds | Clean workspaces; trim build retention |
Summary¶
Agents, Nodes, and Executors is essential for Cloud and DevOps engineers operating Jenkins. Practise the lab until the inspection and change path is muscle memory, then continue the track.
Interview Questions¶
- Why set the built-in node’s executors to zero?
- What is a label and how does a Pipeline select it?
- How do executors affect throughput?
- Inbound versus SSH agents — what differs?
- When do global tool installations hurt more than they help?
Sample answer — question 1
So untrusted build steps cannot run on the controller host that holds JENKINS_HOME and credential material.
Sample answer — question 2
Labels are tags on nodes; agent { label 'docker' } schedules only matching agents.