Skip to content

Ensure proper assumptions

At the moment, people with an existing container scheduler will find this documentation and more or less copy/paste the commands. This will lead to a silent handover of control over the whole Docker daemon to the GitLab Runner containers.

I believe the documentation has been written under the assumption of having some other kind of isolation in place to begin with (probably a dedicated "GitLab Runner VM"), where running the GitLab Runner process inside a container vs. inside the host system is merely a "convenience" mechanism to i.e. not having to handle package management/updates.

Seeing how people are consuming and using this piece of documentation it's clear that this assumption is not being carried over to the readers. People with existing Docker daemons that run a bunch of other payloads will happily copy/paste the commands without understanding that they're passing control over the whole Docker daemon to the single containers.

While I'm unsure how to properly address this issue, as passing a docker socket into a container should IMO raise the same red flags as "curl | sudo bash", therefore presenting as a "you're holding it wrong" kind of problem, I believe it's beneficial or at least responsible to try to prevent those setups from coming into existence.

My "fix" here is a simple note, but I believe more clearly stating the assumptions under which this setup is recommended will be even more helpful.

Feel free to adjust, this should just be a starting point for a discussion.

Merge request reports