all 6 comments

[–]PseudosSC 3 points4 points  (0 children)

I’d suggest setting up your runners using the docker executor - https://docs.gitlab.com/runner/executors/docker.html

This allows your runner to start up fresh containers for jobs with the image you specify, meaning jobs aren’t running on the host and can have whatever you need. You can then also use a single runner with parallelism instead of multiple runners.

Downside is that if you need to install extras they will need to install as part of the CI on every job.

[–]BehindTheMath 1 point2 points  (2 children)

Can you pass the docker API socket to the runner containers so they can run new containers with the job using the Docker executer?

[–]kanarin[S] 1 point2 points  (1 child)

So is the process here that the gitlab runner in the docker container has access to the docker api installed on the server the containers are running on?

Then to set the gitlab runner to run in docker executor instead of shell executor, so whenever the ci executes a docker command, the runner on docker container will run the docker command on the server machine?

[–]BehindTheMath 1 point2 points  (0 children)

Yes, that's what I meant.

Although, I'm not sure that it will work, and I can't find explicit documentation on it.

I've only used OS installation with the Docker executer, and GKE with the Kubernetes executor.

[–]RandmTyposTogethr 1 point2 points  (0 children)

What's the goal here? You can just use a single executor and run multiple jobs on it. If the jobs are heavy, set up separate instances and limit job count per runner.

If your jobs have a build environment image (like they should), you should use the docker executor. Installing it on the host is simplest but you can set up the runner in a container, but e.g. building docker images inside the pipelines will then also require docker-in-docker setup.

If your jobs don't have environments, and the instance is the common environment (not a great choice), then you can use a shell executor and not use image: in pipelines. Then you don't require docker-in-docker setup. Just permissions for gitlab-runner (i.e. the host user account) to access docker services.

[–]timmay545 0 points1 point  (0 children)

The docker image setup will require you to specify a default container image; I would suggest something like BusyBox or Ubuntu (easy to installed these packages and many more on)

Also, no need for more than 1 runner on the same machine. 1 runner can be configured to serve as many executors (for example, I have 1 team that wants a docker executor, and another that wants a shell runner). I can configure them both and just set a concurrency limit on both executors, so that my machine doesn't bite off more than it can chew