Setting Up Jenkins Master-Slave Architecture with Tomcat Deployment

Continuous Integration and Continuous Deployment (CI/CD) is a critical part of modern software development. Recently, I implemented a Jenkins Master-Slave architecture with automated deployment to a Tomcat server. In this blog post, I’ll walk you through what I did, why I did it, and how this setup helped in optimizing my Jenkins pipeline.

Why Use Master-Slave Architecture?

When you use Jenkins as a CI/CD tool, the Master node typically handles everything — scheduling builds, monitoring agents (slaves), managing build jobs, and running them. But as the workload increases, it becomes inefficient and resource-heavy to run all builds on the master.

To resolve this, I distributed the workload by using:

• 1 Jenkins Master (where Jenkins is installed)

• 2 Jenkins Slaves (Agents) (to handle actual build tasks)

What I Did – Step-by-Step Breakdown

✅ Step 1: Installed Jenkins on the Master Node

I set up Jenkins on an EC2 instance (you can use any server). This master instance is responsible for:

• Managing job configurations

• Distributing jobs to agents

• Monitoring the overall pipeline

✅ Step 2: Set Up Java on the Slave Nodes

Since Jenkins agents (slaves) only need to run builds, I installed Java on both slave nodes. This is essential because Jenkins jobs often involve compiling and packaging Java applications into .war or .jar files.

I made sure not to install Jenkins on the slave nodes — they only need to run commands sent by the master.

✅ Step 3: Connect Slaves to the Master

I used SSH method to connect slaves with the master Jenkins:

• Added new nodes under Manage Jenkins > Manage Nodes and Clouds > New Node

• Selected Permanent Agent

• Gave proper labels (like slave1, slave2)

• Provided credentials and remote root directory

• Configured it to launch via SSH

Once connected, the nodes appeared online and were ready to run jobs.

✅ Step 4: Configure Build Jobs to Run on Slaves

In the Jenkins job configuration:

• I used “Restrict where this project can be run” option

• Specified the slave label (e.g., slave1)

• Added build steps to compile the project and store the generated .war/.jar files on the slave

This keeps the master node free from heavy load and focuses only on orchestration.

✅ Step 5: Deploy Artifacts to Tomcat Server

After the build, I configured post-build actions to deploy the .war file to a Tomcat server running on a separate instance (or the same slave, depending on your setup).

Used Deploy to container plugin in Jenkins and provided:

• Tomcat URL (e.g., http://<server-ip>:8080)

• Credentials

• WAR file path (e.g., **/*.war)

🎯 Benefits I Observed

• ✅ Master node remains lightweight and responsive

• ✅ Build tasks distributed efficiently

• ✅ Artifacts are stored on slaves – improves separation of concerns

• ✅ CI/CD pipeline is faster and more scalable

• ✅ Easy to plug in more slaves as workload grows

🔚 Conclusion

By establishing a Jenkins Master-Slave architecture and deploying to Tomcat, I ensured a clean, efficient, and scalable CI/CD process. This setup not only helps in preventing master overload but also gives flexibility in managing resources and scaling operations.

If you’re building something similar or looking to optimize Jenkins pipelines, I highly recommend trying this architecture.