Setting docker socket inside runner on Fedora with Podman (using the official packages podman & podman-docker) and act
#2393
Comments
Didn't seem to work for me. Ultimately, shouldn't the docker socket path (i.e. [1] The path that is specified as the very first line of |
Yes a broken symlink let act's auto detected to abort searching it's hacky list of paths.
Hmm, please note due to the immense amount of log content for the case DOCKER_HOST unset in this issue there is not enough information for the valid |
In fact
I suppose it's searching it's hacky list of paths ought to avoid broken symlinks and move on to the next candidate. But is
So are you asking for more information? I'd be happy to provide whatever is necessary. I can tell you that |
No it's the go client library of docker to send api requests a lot of docker cli behavior doesn't apply, all docker commands shown in the log are all symbolical and no real command |
|
I'm not using SELinux, since I use ubuntu and have a permissive developer system. This can indeed make things much worse I think you misunderstood, Also act does never add any bind mount selinux labels, so I doubt act works well |
To be perfectly clear, what is failing here is a step like this in my workflow file: and/or: Are you telling me that the go client library and/or the
Well, "developer system" is not really any reason to make SELinux permissive (on distros that support SELinux). In fact it's a great way to develop software that then breaks on end-user enforcing systems.
The use of $DOCKER_HOST outside of the runner, to tell |
|
Yes it helps to provide more context, like you did now. Information is all and nothing.
No, you didn't tell me that this is inside a user defined run step, how should I guess that? All errors posted here were about act's log output coming from the go client library used inside of act Your problem is of the following nature (act_runner is a Gitea Actions runner for an open source github alternative)
You need dind for this to work, but act doesn't have such a feature as of now I can use podman, beside the container nesting problem that you just introduced |
I doubt docker info works inside the workflow if you do that without pointing with DOCKER_HOST to a unix socket that is not a symlink Keep in mind avoiding errors is not the same as making things work |
The title of this issue is Setting docker socket inside runner. Unless there is something I am missing, inside [the] runner implies the use of
Yes, I am using podman just fine, modulo wanting to use |
But act does exactly that for me, please expand the collapsed log in
Only the dest socket However it doesn't solve your problem, because the socket bind mount is the cause of your problem C4Context
title System Context diagram for Internet Banking System
Boundary(system, "Host System") {
System(podmansock, "podman", "Allows to run containers")
Boundary(podcontainers, "Podman Containers") {
System(jobContainer, "Job Container")
System(dockerruncommand, "Docker Run Command")
}
System(act, "act", "Allows to run workflows")
}
Rel(act, podmansock, "")
Rel(act, jobContainer, "")
Rel(jobContainer, dockerruncommand, "Broken Bind Mounts!!!")
Rel(jobContainer, podmansock, "Broken Bind Mounts!!!")
The job container now tries to mount the path of the $PWD of the container from your host system to the "Docker Run Command" container. You want to mount the path of the $PWD of the container from your container to the "Docker Run Command" container. Only if podman is part of jobcontainer and "Docker Run Command" is spawned inside of jobcontainer everything is working like with VM and no container. |
|
And so does this become an issue particularly when you try to bind paths inside the runner into the docker container you start in the runner? I.e. doing something like: - name: Run in Docker
run: |
set -eux
rm -rf result
mkdir -p result
touch result/flag
docker run --name build-"$unique"-${{ matrix.distro }} \
"${docker_args[@]}" \
-v "$PWD":"$PWD" -w "$PWD" \
-v "$PWD"/result:/var/tmp/result \
build bash -c "if [ ! -e /var/tmp/result/flag ]; then \
echo \"/var/tmp/result/flag does not exist\" \
exit 1 \
fi"If so, any viable work-around? |
Yes exactly like that is always broken. Workaround A:
Workaround B:
I have been busy this week for learning in my university, I'm actually maintaining two tools to run GitHub Actions Locally one using the official actions/runner based on .net (that also supports Azure Pipelines) and this one This issue mentioned here happens on the official runner as well, if they run both a job container via docker/podman, while running both tools directly on a VM both act and the official runner has no problem at all |
Open
|
In #2393 is now a The following With |
|
I'm mounting the same folder of the job container has as mounts, so both have the same container paths for these mounts. So /opt/hostedtoolcache, github.workspace and the directory of the extracted actions can be bind mounted as if you would use a VM. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Problems with this setup (Fedora 39 + Podman)
After some digging, I've identified several issues:
/var/run/docker.sockis a broken link to/run/podman/podman.sock. The file/run/podman/podman.sockdoesn't exist because by default Podman works in daemonless mode, so there's no daemon and therefore no socket. For the file/run/podman/podman.sockto exist, I've had to start/enable the systemd service for Podman (on Fedora:podman.socket&podman.service)./var/run/docker.sock, but not for/run/podman/podman.sock. To solve this, I've decided to enable the systemd service as an unprivileged user rather than as root, and set the environment variableDOCKER_HOSTto point to/run/user/$EUID/podman/podman.sock.actseems to use theDOCKER_HOSTenvironment variable for some steps of the process, but not all of them. When I setDOCKER_HOST=unix:///run/user/$EUID/podman/podman.sock, pulling the Docker image works, but creating the container still fails. In the end, I've decided to overwrite the symbolic link at/var/run/docker.sockto point to/run/user/$EUID/podman/podman.sock.How to diagnose the root cause
Here are the steps I've used to find out the root cause:
Check that the socket files exist and have the right permissions:
Create the socket if it doesn't exist:
Check that your user can read the sockets:
Enable the socket/service as an unprivileged user instead of root:
Verify again using the user socket:
Overwrite the symbolic link at
/var/run/docker.sockifact/podmanis still trying to access/var/run/docker.sockinstead of using theDOCKER_HOSTenvironment variable:sudo ln -sf /run/user/$EUID/podman/podman.sock /var/run/docker.sockand check again:
Solution for Fedora 39 + Podman
In the end, these are the commands that I've used to fix the problem on Fedora 39 using Podman:
Notice that this is an acceptable workaround for me, since I'm the only user who uses
act&podmanon my computer, but it may not work if multiple unprivileged users need to useact&podmanon the same computer, because the user socket only has permissions for that specific user.Originally posted by @jonancm in #1744 (comment)
The text was updated successfully, but these errors were encountered: