Gitlab runner setup with podman

Hi all,

I’m managing a local gitlab serveur for some years but never setup a gitlab runner for CI.
I’ve setup an old server with Alma Linux8 and I manage to use it for CI. gitlab-runner is deployed whith:
dnf install gitlab-runner
I read that podman can be used out-of-the-box in place of docker and is supported since gitlab 15 (I’m using gitlab 16).
Podman is installed, I can launch the busybox instance and use it on the dedicated server.
Runner is registred on the gitlab server, I can see it as an available runner.
I follow the small tutorial Tutorial: Create and run your first GitLab CI/CD pipeline | GitLab but each time it fails with:
Cannot connect to the Docker daemon

So something is wrong in my process.
Is there a basic howto for a gitlab-runner setup based on podman ? I’ve read many things but the documentation (including podman) is really wide for setting up a first basic configuration and none of my configs were successful.

Thanks for your advices.

Patrick

I don’t know if there is some comprehensive guide. Start with installing Podman and GitLab Runner.

After you install Podman you should have a systemd unit podman.socket defined in /usr/lib/systemd/user/podman.socket. This socket is Docker compatible interface for apps. Because Podman is designed to run separately for each Linux user you need to enable and start this under the user you want the GitLab Runner to use for containers. This can be the gitlab-runner user or any other user.

# switch to the user
sudo su -l gitlab-runner

# prepare user environment so we can use user-scoped systemd
loginctl enable-linger $USER
echo 'export XDG_RUNTIME_DIR=/run/user/$(id -u)' >> .bash_profile
source .bash_profile

#start and enable `podman.socket`
systemctl --user enable --now podman.socket

# get path to the socket
systemctl --user status podman.socket | grep Listen
# example: /run/user/978/podman/podman.sock

Since GitLab Runner doesn’t support Podman as executor you need to adjust it a bit. GitLab Runner is looking for Docker socket on the standard place, but since we have Podman instead you need to tell GitLab Runner where to look for the Podman socket

In this config.toml snippet I am using the path to the socket file which I got from the steps above.

[[runners]]
    [runners.docker]
        host = "unix:///run/user/978/podman/podman.sock"

Many thanks Balonik for this detailed answer. You provide me exactly all that I have missed.

There is just an additional point I had to do (solved before posting this thread) to enable gitlab-runner user to launch the container:

usermod --add-subuids 100000 165536 gitlab-runner
usermod --add-subuids 100000-165536 gitlab-runner

This problem seams related to the rpm package when it creates the gitlab-runner user withoud sub-uid/gid setup. The setup is correct for basic users created with the classical linux useradd command.

Now that the basic architecture is in place, next step will be to provide a container with all the prerequisites for testing. Some reading about podman to do!

Hi balonik,
I’ve just a final problem with this setup as containers are launched by gitlab-runner with root as default uid in the container. I’ve found several discussion about this but none providing a solution.
Any idea on how to default to an unprivilegied user with sudo allowed in the container?
Thanks
Patrick

The user within the container depends on how the container was built. Most community built containers are running under root. But if the container was built to run as another user (it has USER directive in Dockerfile) it will run under such user.

For example using container with USER 1000 in Dockerfile and running id in Job will result in

$ id
uid=1000(1000) gid=0(root) groups=0(root)

You can override the default user GitLab Runner will run commands under using user in [runners.docker] section, but if such user is not in the container it will fail.

Thanks balonik.
i did all this, my docker file ends with a “WORKDIR” and a USER directives.
Launching the container with “podman run” I have the correct user and I am in it’s home now.
But the clone of the repo is still in /builds and belongs to root when the container is used from gitlab-ci.
So something is missing I think. And of course the user cannot compile the project in the builds directory.

If I set the user name in the [runners.docker] section this will be for all containers and all projects, not only the container used for this project. Or should I register twice the gitlab-runner to my gitlab server, with and without setting the user name in /etc/gitlab-runner/config.toml ? But how to select the right behavior in gitlab-ci ?
I’m a little bit confused with all of this.

Patrick

Ah, right. The files are cloned by the gitlab runner helper container, which creates a volume and then Runner bind mounts it into the container running the job. The helper container runs as root so the files are cloned like that.

I was searching if there is a way to alter how it is cloned, but with no success.

Hi balonik,
thanks for this feed back. I’v tryed a new approach where, in the build stage, I copy the files from /builds (where they belong to root) to the user home. Then it’s OK for the compilation. BUT this break artifacts as they must be in the /builds tree (where the simple user cannot write).
May be all must run as root ? I can force OpenMPI to execute whith the root user, but is this a safe approach, even in podman environment ? Not sure.
Patrick

Since you are running Podman in rootless mode (under a normal user) the root user in container is not really a root in the system, because it’s mapped to one of the UIDs specified in /etc/subuid.
I’d say it’s OK from security point of view.