Having explored the role of agents and their use cases, the next step is understanding how to set them up for effective communication with the Jenkins master. Let’s begin by looking at the communication protocols that facilitate this interaction.

Communication Protocols

To establish a connection between the master and the agent, a bi-directional communication link must be formed. Here are the primary methods to initiate this connection:

  • SSH:
    • Jenkins master connects to the agent using the standard SSH protocol. Jenkins includes a built-in SSH client, so all you need is an SSHD server configured on the agent machine.
    • This method is favored for its convenience and reliability, as it leverages standard Unix mechanisms.
  • Java Web Start:
    • This method involves launching a Java application on each agent machine, which establishes a TCP connection with the Jenkins master.
    • It's particularly useful when agents are behind a firewall and the master cannot initiate the connection.
  • Windows Service:
    • In this method, the master registers an agent on the remote machine as a Windows service.
    • However, this method is generally discouraged due to its complex setup and limitations with graphical interface usage.

Now that we understand the communication protocols, let’s discuss how to configure the agents.

Setting Up Agents

At a fundamental level, agents communicate with the Jenkins master through one of the protocols mentioned earlier. However, there are various ways to attach agents to the master, which can differ based on two key aspects:

  • Static vs. Dynamic: The simplest approach is to add agents permanently to the Jenkins master. While this is straightforward, it requires manual adjustments if you need to increase or decrease the number of agents. A more flexible option is to dynamically provision agents as needed.
  • Specific vs. General-Purpose: Agents can be tailored for specific tasks (e.g., different agents for projects using Java 7 vs. Java 8) or serve as general-purpose resources (e.g., an agent functioning as a Docker host where pipelines are built within Docker containers).

These considerations lead us to four common strategies for configuring agents: