5

What do we have:
We have a Gitlab EE with multiple projects running on a droplet, next to that we have a runner server for the CI runners. All projects are Docker projects and 4 runners can be busy at the same time.

What we need to know:
Now is my question, is it better to have like 4 runners on the runner server for all the projects OR is it better to have 1 runner per project?

I know when the CI gets stuck, the runner will be stuck too and it will mean that it is missing 1 runner till it gets reset. So at that point single runner per projects seems better, but it will make a large list of runners which perhaps use some idling resources from the server ?

See here nothing is running or doing work: enter image description here

Anybody can tell me what is better in your opinion and why it is better in your opinion as both ways seem legit in my opinion and i want to know others experience.

2 Answers 2

4

After some research i found out that shared runners are good for the projects that are very much the same, and specific runners are better for the projects that are not like any project.

Shared runners can eat all resources available in the end with its queue's which makes specific runners more interesting.

My choice now is more like a little bit of both, so shared for all small and likewise projects, and specific for the large new projects as the documentation recommends.

From Shared vs specific Runners:

... The main differences between a shared and a specific Runner are:

  • Shared Runners are useful for jobs that have similar requirements, between multiple projects. Rather than having multiple Runners idling for many projects, you can have a single or a small number of Runners that handle multiple projects. This makes it easier to maintain and update them. Shared Runners process jobs using a fair usage queue. In contrast to specific Runners that use a FIFO queue, this prevents cases where projects create hundreds of jobs which can lead to eating all available shared Runners resources.
  • Specific Runners are useful for jobs that have special requirements or for projects with a specific demand. If a job has certain requirements, you can set up the specific Runner with this in mind, while not having to do this for all Runners. For example, if you want to deploy a certain project, you can setup a specific Runner to have the right credentials for this. The usage of tags may be useful in this case. Specific Runners process jobs using a FIFO queue.

A Runner that is specific only runs for the specified project(s). A shared Runner can run jobs for every project that has enabled the option Allow shared Runners under Settings ➔ CI/CD.

Projects with high demand of CI activity can also benefit from using specific Runners. By having dedicated Runners you are guaranteed that the Runner is not being held up by another project's jobs.

You can set up a specific Runner to be used by multiple projects. The difference with a shared Runner is that you have to enable each project explicitly for the Runner to be able to run its jobs.

Specific Runners do not get shared with forked projects automatically. A fork does copy the CI settings (jobs, allow shared, etc) of the cloned repository.

Still i would like to know everyone's mindset about this, as im still interested about your way of doing it!

0

Thanks for your conclusion, it fits in mine too.

In my situation, I have projects of different types like pure Java, .NET and some packaged in Docker. For the moment, the number of jobs to build is not consequent but I'm afraid about some jobs creation peak for specific project before a major release for example...

I only configured shared runner with tags (dotnet, java, docker,...) and the project specifies the correct tag in their .gitlab-ci.yml :

job:
 tags:
  - java

If I detect/anticipate a peak of job creation, I can assign temporary a runner to a project. Of course the peak detection and the lock/unlock can be automatized with Runner API but it's not my case for the moment.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.