Correct me if I’m wrong but as far as I see there is no best practice given of how to best setup multiple runners on the same VM and I think logically that is a commonly considered use case.
Could you please give examples for Mac or Linux of how to setup multiple hosts on the same machine without sharing the same config.toml? Mostly interested in Linux setup, as for Windows there was a hint on stackoverflow.
Why can’t I run more than one instance of Runner? You can, but not sharing the same config.toml file.
Running multiple instances of Runner using the same configuration file can cause unexpected and hard-to-debug behavior. In GitLab Runner 12.2, only a single instance of Runner can use a specific config.toml file at one time.
On 1 VM (or normal host), create multiple runners, and register them on Gitlab. Do this, without violating the quoted rule above which comes directly from the Gitlab documentation.
Uhm, you don’t have to run multiple runners, instead you should run multiple executors. Imagine the runner as the hypervisor and the executor being the thread that’s actually executing your CI job(s).
Thank you for your answer! Apparently, I’ve had my terminology wrong. Now it makes sense. Executors is what I need and I guess now letting them share the same config.yaml is safe. Thanks
Well i would like to set up multiple Runner on one Host because i need one Runner who can only execute one Job at a time and another one who can execute 5-10 Jobs in parallel (small jobs).
As far as i read the Documentation correct, that cannot be done right ? So this would be a use case for that. Also you cannot specify this in the gitlab-ci.yml. You can’t say that this job can only be executed ONCE in parallel across all branches / PRs / etc.
It’s possible to run multiple GitLab runners on the same host by encapsulating the runner and its executor dependencies inside a container.
For example, since I use GitLab with the Docker executor, I created a container that encapsulates the GitLab runner + a docker engine. This way, the container is acting as a virtual host (much like a VM) and the jobs run inside that container, isolated from the host. I can then easily deploy several of these on the same host.
To launch these VM-like containers, I used Docker plus the Sysbox runtime, as it allows deploying such containers easily and without using privileged containers.
There is a blog on this here. Check out section “GitLab Runner & Docker in a System Container”.
The terminology still seems a bit confusing since “executor” is used to mean two different things. In @aljaxus’ example all the executors (first meaning) use the docker executor (second meaning), but I guess you could also have several executors (first meaning) using different executors (second menaing).
Shouldn’t another term be found (does it already exist, and I just haven’t found it) for the first meaning, i.e. the thing you register?
You’re a bit late to the conversation, but yes - I was also using the word “executor” incorrectly. “register the first executor” should be “register the first runner” because the “hierarchy” of the terms is as follows:
each system (OS, be it dedi or VM) has one runner service installed
each runner service has n runners (where n >= 0)
each runner has one executor
This is just how I see it from the perspective of GL ce admin and user, it might differ from actual setup that GL uses, check docs to form your own opinion.
I know the discussion is a bit old, but it still seemed better to reply here than to start a new thread. I see it the same way you do, but would like another name for the second bullet, it’s quite confusing especially to people who are not that involved in administrating GitLab.
I have 2 things to mention. Some insight on the terminology and a use case for multiple runners.
I was confused at first (and possibly still am) about the terminology, but after working with gitlab-ci for a few months here is my understanding, at least in an AWS auto-scaling environment with docker+machine executor.
A gitlab runner is registered on a host machine (which is running the gitlab runner service). This runner is just a coordinator of jobs and executors. When you trigger a pipeline job, it send the job to the runner which then gives that job to one of it’s executors. Then your build(or test,deploy,whatever) job runs on the executor. The runner never ran any build or test, it is just the host controlling the executors.
That explanation may not be a perfect fit for other environments, but I don’t have experience with them so I can’t say for sure.
Duplicate below- I am going to make a separate post for my question below. Leaving because it pertains to this conversation
The second thing I want to mention is a use case for having 2 runners on one host machine.
We have a pipeline that uses our private gitlab runner to run tests and build docker images. It has worked fine until recently when we tried running code coverage. Our tests aren’t the most efficient, so running the coverage needs more RAM than what our current executors are provisioned with. I could just bump up the instance size in the config.toml, but then we are paying for a larger instance for coverage that we only run occasionally.
I don’t want to provision a separate runner only for these “big” jobs, as it will sit idle most of the time. It is essential that it is available when we need it though. I would like to have a second runner configured with an idle count of 0, on the same host machine that houses our smaller runner that we use frequently. I would like to have different tags on the “big” runner so that it needs to be called specifically for the jobs that require it.
There may be a way to have a dual config like this with a single runner, but I have combed the documentation and couldn’t find a way, though the documentation does hint that it is possible. Otherwise, just having a second runner on the underutilized host seems like it would be the cleanest solution, if it is possible.
