In the world of continuous integration and delivery (CI/CD), Jenkins stands as one of the most popular automation tools. One of the key features that make Jenkins powerful and scalable is its master-slave architecture. In this blog, we will delve into the concept, explain how it works, and provide real-world scenarios to make it easier to understand.
What is the Master-Slave Architecture in Jenkins?
The master-slave architecture is a distributed system setup in Jenkins where a master node delegates work to one or more slave nodes. The master node is the central controller, while the slave nodes are worker machines that perform the actual tasks. This design allows Jenkins to handle large and complex build processes by distributing the load across multiple machines.
Components of the Architecture
Master Node:
Responsible for scheduling jobs.
Maintains the build configurations, plugins, and user interfaces.
Delegates tasks to slave nodes when necessary.
Slave Node:
A worker machine that performs tasks assigned by the master.
Runs build jobs in its environment (e.g., Linux, Windows, macOS).
Communicates with the master to send job statuses and logs.
How Does It Work?
When a build is triggered on the Jenkins master, it evaluates where the job can best be executed based on resource availability, node labels, or specific job configurations. If the job requires a specific environment, it will delegate the task to a slave node configured for that purpose.
Real-World Scenarios
Scenario 1: Cross-Platform Builds
Imagine a software product that needs to run on multiple platforms: Windows, Linux, and macOS. You can configure Jenkins with a master node and three slave nodes, each running a different operating system. When a build is triggered, Jenkins distributes the workload to the appropriate slave based on the target platform.
For example:
Windows builds run on the Windows slave.
Linux builds run on the Linux slave.
macOS builds run on the macOS slave.
This setup ensures that you can test and build your software in multiple environments simultaneously, saving time and resources.
Scenario 2: High-Volume Builds
A large e-commerce company has multiple development teams working on various microservices. Each team triggers builds frequently, causing a bottleneck when all jobs are queued on a single master node. By setting up multiple slave nodes, Jenkins can distribute these builds across the slaves, significantly reducing build times.
For instance:
Microservice A’s build runs on Slave 1.
Microservice B’s build runs on Slave 2.
Microservice C’s build runs on Slave 3.
Advantages of the Master-Slave Architecture
Scalability: Add more slave nodes to handle increased workloads.
Flexibility: Configure slaves with specific environments or tools.
Efficiency: Parallel execution reduces build times.
Fault Tolerance: If a slave fails, the master can redistribute tasks to other available slaves.
Setting Up a Master-Slave Configuration in Jenkins:
STEP-1: Launch 2 instances with key-pair (Master, Slave)
STEP-2: Install Jenkins on Master
#STEP-1: INSTALLING GIT
yum install git -y
#STEP-2: GETTING THE REPO (jenkins.io --> download -- > redhat)
sudo wget -O /etc/yum.repos.d/jenkins.repo \
https://pkg.jenkins.io/redhat-stable/jenkins.repo
sudo rpm --import https://pkg.jenkins.io/redhat-stable/jenkins.io-2023.key
#STEP-3: DOWNLOAD JAVA11 AND JENKINS
yum install java-17-amazon-corretto -y
yum install jenkins -y
#STEP-4: RESTARTING JENKINS (when we download service it will on stopped state)
systemctl start jenkins.service
systemctl status jenkins.service
STEP-3: Install Java17 on Slave Server
yum install java-17-amazon-corretto -y
STEP-4: Go to Jenkins Dashboard » Manage Jenkins » Nodes
Click on New Node
Host: Slave-server-Private-IP
Now click on Add credentials
Kind: SSH Username with Private Key
Username: ec2-user
Now add the Private Key (PEM file)
Now click on save
Now we have implemented Master-Slave Architecture, Lets build a job and execute it on slave-server
Go to Jenkins Dashboard and click on New Item
Enter the Job name and select the type
Now enter tyhe label name as dev
Save and build the job, it will be executed in slave server.
Lets Open the console output to confirm
As you can observer, the job is executed on remotely (slave1).
Conclusion
The master-slave architecture in Jenkins is a robust solution for handling complex CI/CD workflows. By distributing tasks across multiple machines, it ensures efficient, scalable, and fault-tolerant operations. Whether you’re dealing with cross-platform builds, high-volume tasks, or resource-intensive processes, this architecture empowers you to optimize your development pipeline.
Start leveraging the master-slave setup in Jenkins today and watch your CI/CD pipeline scale seamlessly!