A Brief Guide to GitLab CI Runners and Executors

If you wish to create your own infrastructure for running GitLab CI jobs, you need to host your own GitLab Runners. But which executor to select? Shell, SSH, or Docker? Or something else?

GitLab CI employs a different architecture, compared to the default installation of more traditional CI servers, like Jenkins. In a nutshell, the GitLab server will always delegate the work of actually running a job to a GitLab Runner, which will sit somewhere on a different server.

Here are the most important concepts you need to understand:

• GitLab Job: the smallest component of a pipeline, which contains one or more commands that need to be executed.
• GitLab Runner: this is an agent installed on a different server from the GitLab server. The GitLab Runner receives instructions from the GitLab server in regards to which jobs to run. Each runner must be registered with the GitLab server.
• Runner Executor: each Runner will define at least one executor. An executor is essentially the environment where the job will be executed.

With GitLab, you can use different executors, depending on your needs:

• Shell
• SSH
• VirtualBox
• Parallels
• Docker