Understanding the master and slave architecture

A standalone Jenkins instance can grow fairly quickly into a disk-munching, CPU-eating monster. To prevent this from happening, we can scale Jenkins by implementing a slave node architecture, which can help us offload some of the responsibilities of the master Jenkins instance. Let's clarify this concept. A Jenkins slave node is simply a device configured to act as an automation executor on behalf of the master. The Jenkins master simply represents the base installation of Jenkins. The master will continue to perform basic operations and serve the user interface, while the slaves do the heavy lifting.

This distributed computing model will allow the Jenkins master to remain responsive to users, while offloading automation execution to the connected slave(s). To illustrate the concept of a master, and slave mode architecture let's look at an example. Figure 2-1 shows a Jenkins master and three slave nodes of varying OS types:

Figure 2-1: A Jenkins master connected to three slave node devices

The Jenkins slave agent can run on virtually any Java (JRE) capable device that has a network connection. This cross-platform connectivity model spans across devices of varying hardware types, processor architectures, and operating systems. This includes Windows, Mac OS X, Linux, Unix, and embedded devices. The architecture described in the preceding figure is a very simple example of a cross-platform distributed Jenkins solution. By design, this architecture can expand and contract as needed.

With all of the added capabilities that the Jenkins master and slave solution offers, it is important to know that the Jenkins master will continue its assigned responsibilities and will offload them only when specified. It is also important to know that, even after slaves are created, the Jenkins master will continue to own certain tasks that are designated solely to the master. Even when slave agents are connected to the master, the master will continue to manage some of the less resource-intensive work. Some responsibilities that are specific to the Jenkins master and cannot not be delegated to the slave nodes include:

This may seem a bit confusing, but it doesn't need to be. To help clarify let's illustrate the architecture in better detail. Figure 2-2 shows a Jenkins master and slave architecture with a set of diagrams depicting the responsibilities of each:

Figure 2-2: Expanded Jenkins master and slave connectivity diagram

As we can see, there will continue to be a set of core responsibilities that the Jenkins master continues to perform. Jenkins slave nodes will manage resource-intensive automation execution, while the Jenkins master will maintain the lighter tasks, such as serving the user interface, performing source control polling, and delivering notifications.

Creating slave nodes in the UI

In this section, we will learn how to define a new slave node through the Jenkins user interface. The Jenkins administration area provides a node management dashboard, which provides us with the ability to create new slave devices, remove old ones, and edit the ones in use. Let's jump right in and learn how to create a new slave node.

To get started, navigate to the following location:

Jenkins | Manage Jenkins | Manage Nodes | New Node

Once the screen has loaded Jenkins will present us with the new node basic configuration form. This basic configuration form allows us to specify some high-level configuration details about our new slave node. It lets us select either Dumb Slave or Copy Existing Node (as shown in Figure 2-3). The copy existing node option will only be present if we have slaves already defined in Jenkins. In our example we entered Microsoft Windows Slave Node 01 for the node name, and selected Dumb Slave as the type. Once the fields have been configured click OK to proceed to the Detailed node configuration form.

Figure 2-3: New node configuration form

The following screenshot outlines the detailed node configuration form that Jenkins presents us with. This form provides us with the ability to specify the network connection information, node labels, JVM options, and other important configuration criteria regarding our new slave node. At a minimum, we need to provide the slave node's name, description, remote root directory path, and launch method:

Figure 2-4: Detailed slave node configuration form

The information we specify on the detailed node configuration form will have a profound impact on the slave node's behavior. It is important to fully understand the fields available, their functionality, and their impact on the slave node. For edification, this table details each of the available configuration options in the detailed slave node configuration form:

Jenkins slaves can be configured to operate in any number of ways. Initially we will want to simply get the node up and running. We can later adjust any settings or minor configuration items to fine-tune the node. One of the key items we will need to define is the launch method.