Installing and Configuring GitLab Runners

In Chapter 4, you learned about the fundamentals of GitLab CI/CD. We defined and introduced the vocabulary and concepts around CI/CD pipelines, which included CI/CD pipeline components, different pipeline types, how to observe and interact with pipelines in the GitLab UI, and how to write a pipeline’s configuration using the .gitlab-ci.yml file. A few paragraphs were also spent introducing GitLab Runner as the crucial component of GitLab CI/CD, which actually runs pipeline tasks and reports the results back to GitLab.

The sole focus of this chapter will be the topic of GitLab runners. You will learn in this chapter that GitLab runners act as the “muscle” in the CI/CD process. Runners are small programs that are installed separately from the main GitLab application. Their purpose is to receive new CI/CD jobs published by GitLab and follow the jobs’ instructions as specified in the .gitlab-ci.yml file. Runners can...

Technical requirements

Like the previous chapters, you’ll get the most out of this chapter if you have an account on a GitLab instance software-as-a-service (SaaS) or self-managed). In addition, installing the GitLab Runner agent requires a computer (Windows, Mac, or Linux) on which to install the runner binary. A personal laptop would be fine—the runner is lightweight and its system requirements are minimal. If you are using GitLab.com, CI/CD pipelines can also be run using GitLab’s SaaS runners, though be aware of possible usage charges.

Defining GitLab runners and their relationship to CI/CD

Recall that GitLab CI/CD is a series of tasks performed against code in your project, which often include some combination of build, test, and deploy jobs. Importantly, CI/CD pipelines are not run inside the GitLab application, as each job will generally require some specific platform and set of tools to successfully run.

Note

GitLab runners are programs that accept CI/CD jobs from GitLab, run the jobs’ tasks in an appropriate execution environment, and then report the results back to GitLab.

GitLab Runner is an open source application written in Go

The official repository for the GitLab Runner application lives in a project hosted on GitLab.com called gitlab-runner. At the time of writing, you can navigate to https://gitlab.com/gitlab-org/gitlab-runner to view the project’s development and source code. Like the main GitLab application, GitLab Runner follows a monthly release cadence. The latest version...

The runner architecture and supported platforms

Before going into further details about runner components, installation, and configuration, it’s worth clarifying a few pieces of terminology. So far in this chapter, the words GitLab Runner and runner may appear to have been used interchangeably. However, a bit of nuance is required. GitLab Runner refers to the application installed once on a computer. Once the GitLab Runner application is installed, it does not yet communicate with GitLab or run CI/CD jobs. In order to connect to GitLab and run CI/CD jobs, an administrator will need to execute a GitLab Runner command that registers individual runners with GitLab and specifies the execution environment those runners will use. Each registered runner will then be a dedicated process that checks into GitLab and runs CI/CD jobs.

This setup can appear confusing at first because a single GitLab Runner application will normally support registering multiple runner processes on the...

Installing the Runner agent

This section will be most helpful if you follow along and install and register a runner on your own computer. You will find that the installation steps will differ slightly depending on your system type: Windows, macOS, Linux with a supported package manager, or a generic Linux system. Regardless of platform, the same two-step process holds:

1. Install the GitLab Runner agent.
2. Register a runner with GitLab.

Installing GitLab Runner

As previously mentioned, the method of installation will differ slightly depending on your operating system. For major Linux distributions, the documentation (https://docs.gitlab.com/runner/install/linux-repository.html) will direct you to add the runner repository to your system, and then use your native package manager to install the gitlab-runner package. For Windows, macOS, and other Linux distros, you will use curl to get the program directly from GitLab, make it executable, then install and start the runner...

Considerations regarding the various runner types and executors

We’ve learned that there are many types of runners, configuration options, and execution environments. In this section, we will discuss some performance, security, and monitoring considerations to help guide your decision-making regarding which runners to use, and when to use them.

Performance considerations

As a developer or operator, you want to make sure that pipelines run as efficiently as possible. Key performance considerations around CI/CD job execution are runner availability and resources, repository size, and how you handle job and application dependencies.

Runner availability

Consider the three scopes of runners discussed earlier in this chapter:

• Shared runners configured at this instance level (if using self-managed GitLab), available to all projects in the instance
• Group runners available to all projects in a group and its subgroups
• Specific runners registered only to designated...

Summary

In this chapter, we described the part that runners play in GitLab CI/CD pipelines. We learned that runners can be thought of as the “muscle” of CI/CD executing jobs specified in .gitlab-ci.yml. Runners can be installed as standalone programs on most computer platforms and can be shared with all projects in GitLab, or with only certain projects or groups. Moreover, wherever you have a runner installed, you can choose the execution environment it uses to run CI/CD tasks.

Regardless of your role, it is helpful to understand how runner settings can affect pipeline performance, application security, and observability in the development life cycle. We encourage you to practice the process of installing and registering runners, even if maintaining the runner infrastructure is not part of your day-to-day responsibilities. A confident knowledge level of runner architecture and workflows will make you a better software practitioner as you continue your GitLab journey...