From the course: Intermediate Jenkins: Automate, Integrate, and Secure CI/CD Workflows at Scale

Distribute builds with agents - Jenkins Tutorial

From the course: Intermediate Jenkins: Automate, Integrate, and Secure CI/CD Workflows at Scale

Start my 1-month free trial Buy for my team

Distribute builds with agents

“

Up to this point in the course, we've been running jobs directly on the Jenkins server, which is also referred to as the controller. A best practice is to limit the jobs that are run on the controller and only run jobs on other servers, which are referred to as nodes or agents. This approach frees up resources on the Jenkins controller so we can focus on scheduling and managing jobs. One of the most common node types is a Secure Shell or SSH node. In this case, Jenkins connects to a server as a specific user with an SSH key. A server running any operating system can be configured as an SSH node as long as it accepts SSH connections, has a user and a key that Jenkins can use, and also has a recent version of Java installed. Having Java installed on the node is essential because the agent process is a Java-based application. Jenkins can also use nodes and agents that run as containers, also known as Docker agents. With Docker agents, the Jenkins controller runs every job in a newly created container. This has the benefit of the job running in a fresh and isolated environment every time. For Docker agents to work, a Docker process must be running on the node. When we start using nodes and agents in pipeline jobs, we have to pay more attention to the agent configuration. So far, we've been using Agent Any, which allows Jenkins to run the job on the first available agent. But as we start adding nodes and agents with different capabilities, we can use labels and keywords that identify a specific agent. We may also need to configure a pipeline to install any tools that it needs to run. This will give a pipeline more control over the version of a specific tool while also making sure the tool is available to use. And probably the most important thing we need to pay attention to is checking out code when a job is associated with a repository. When Jenkins uses a pipeline from a repo, the first checkout is on the Jenkins controller. This allows Jenkins to read and process the Jenkins file to get the project configuration. But when Jenkins starts running the job on an agent, the code that was initially checked out isn't available. In this case, the pipeline needs to be updated with a step to check out the code so it can be used on the node. Before we get hands-on with nodes and agents, let's take a look at a tool configuration that needs to be in place. I'm logged into my Jenkins server and I've opened up the Manage Jenkins page. In upcoming lessons, I'll be demonstrating how a tool can be installed on a node and I want to show you a configuration that I have in place for Maven. From here, I'll select Tools. And if I scroll down to the Maven section and view the Maven installations, you can see that I've already set up an installation called Maven-3.9.12 and it's set up to install automatically. With this configuration in place, I'll be able to reference this tool by name in the pipelines I'll be using. If you're following along and using the exercise files, please set up a Maven installation and using the same configuration.

Contents