11.3. Master/Slave Strategies in Jenkins
There are a number of different ways that you can configure set up a distributed build farm using Jenkins,
depending on your operating systems and network architecture. In all cases, the fact that a build job is
being run on a slave, and how that slave is managed, is transparent for the end-user: the build results
and artifacts will always end up on the master server.
Creating a new Jenkins slave node is a straightforward process. First, go to the Manage Jenkins screen
and click on Manage Nodes. This screen displays the list of slave agents (also known as “Nodes” in
more politically correct terms), shown in Figure 11.1, “Managing slave nodes”. From here, you can set
up new nodes by clicking on the New Node button. You can also configure some of the parameters
related to your distributed build setup (see Section 11.5, “Node Monitoring”).
Figure 11.1. Managing slave nodes
There are several different strategies when it comes to managing Jenkins slave nodes, depending on
your target operating systems and other architectural considerations. These strategies affect the way you
configure your slave nodes, so we need to consider them separately. In the following sections, we will
look at the most frequently used ways to install and configure Jenkins slaves:
- The master starts the slave agents via ssh
- Starting the slave agent manually using Java Web Start
- Installing the slave agent as a Window service
- Starting the slave agent directly from the command line on the slave machine from the command
line
Each of these strategies has its uses, advantages, and inconveniences. Let’s look at each in turn.
11.3.1. The Master Starts the Slave Agent Using SSH
If you are working in a Unix environment, the most convenient way to start a Jenkins slave is
undoubtedly to use SSH. Jenkins has its own build-in SSH client, and almost all Unix environments
support SSH (usually sshd) out of the box.