Jenkins Master Slave Architecture

Jenkins No comments

Here's a detailed explanation of Jenkins Master-Slave Architecture tailored for interviews, especially for a Senior CI/CD Engineer role:

Jenkins Master-Slave Architecture (Now "Controller-Agent")

Jenkins follows a distributed architecture to scale and handle multiple build jobs efficiently using:

Master (Controller)
Slaves (Agents)

🔹 1. Master (Controller)

The Jenkins Master (or controller) is the central orchestrator. It’s responsible for:

Feature	Description
UI & CLI	Hosts the Jenkins Dashboard and API
Job Scheduling	Schedules build jobs and assigns them to agents
Load Distribution	Decides which agent runs which job
Plugin Management	Manages and runs all installed plugins
SCM Polling	Triggers jobs based on Git changes
Running Lightweight Jobs	Can also run jobs if no agent is assigned

🧠 Note: Ideally, reserve the master for orchestration only; avoid heavy builds on it.

🔹 2. Slave (Agent)

Agents are worker nodes where Jenkins actually executes build jobs.

Feature	Description
Executes Build Steps	Compiles, tests, packages, etc.
Platform-Specific Jobs	Can run on specific OS, JVMs, or toolchains
Labeling	Tagged with labels to match job requirements
Multiple Agents	You can configure many agents for parallelism and scaling

✅ Agent Types:

Permanent Agent: Configured manually with fixed specs and labels
Cloud Agent (Ephemeral): Spawned on-demand using Kubernetes, AWS EC2, etc.
Docker Agent: Spins containers dynamically for isolated build environments

🔄 3. Communication

SSH: Most common method (Jenkins → Agent)
JNLP (Java Web Start): Used when agent initiates the connection (firewall-friendly)
WebSocket: Newer, more secure, used with Kubernetes agents

📘 Example Scenario

You configure:

Master: Orchestrator
Linux Agent: For Maven, Java builds
Windows Agent: For .NET builds
Docker Agent: For isolated builds using containers

A job with label linux && docker will be dispatched only to Linux agents with Docker installed.

🧠 Why Use Master-Slave Architecture?

Benefit	Explanation
Scalability	Handle 100s of builds in parallel
Isolation	Run jobs in separate environments (avoid tool conflicts)
Efficiency	Avoid overloading the master
Flexibility	Run platform-specific or label-specific builds

🔐 Security Considerations

Restrict agent permissions
Use node-level security
Secure communication using SSH keys or agent certificates
Restrict script execution on agents

⚙️ Tools and Integrations

Cloud Agents via:
- Jenkins Kubernetes Plugin
- Amazon EC2 Plugin
Monitoring:
- Prometheus Plugin
- Monitoring master/agent CPU, memory, disk

📝 Interview Tips

✅ Real-world Talking Points

“We used Kubernetes plugin to dynamically scale Jenkins agents.”
“To reduce master load, we offloaded all CPU-intensive builds to agents.”
“We used custom Docker images per job with pre-installed tools.”

✅ Key Terms

Labels
Executors
Load balancing
Ephemeral agents
Declarative pipeline agent { label '...' }

Jenkins Master Slave Architecture