mirror of
https://github.com/nektos/act.git
synced 2026-04-26 01:15:51 +03:00
[GH-ISSUE #2393] Setting docker socket inside runner on Fedora with Podman (using the official packages podman & podman-docker) and act #1100
Labels
No labels
area/action
area/cli
area/docs
area/image
area/runner
area/workflow
backlog
confirmed/not-planned
kind/bug
kind/discussion
kind/external
kind/feature-request
kind/question
meta/duplicate
meta/invalid
meta/need-more-info
meta/resolved
meta/wontfix
meta/workaround
needs-work
pull-request
review/not-planned
size/M
size/XL
size/XXL
stale
stale-exempt
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/act#1100
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @brianjmurrell on GitHub (Jul 10, 2024).
Original GitHub issue: https://github.com/nektos/act/issues/2393
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:and 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 https://github.com/nektos/act/issues/1744#issuecomment-1873335752
@brianjmurrell commented on GitHub (Jul 10, 2024):
Didn't seem to work for me.
Ultimately, shouldn't the docker socket path (i.e.
$DOCKER_HOSTif specified) that is being used byactto start the container that the runner is in[1] be the same socket path that is used bydockercommands inside the runner?[1] The path that is specified as the very first line of
act's output:time="2024-07-10T09:58:27-04:00" level=info msg="Using docker host 'unix:///run/user/1001/podman/podman.sock', and daemon socket 'unix:///run/user/1001/podman/podman.sock'"which in my case comes from my$DOCKER_HOSTenv. variable.@ChristopherHX commented on GitHub (Jul 10, 2024):
ln -sfis too weak to survive adocker -v <host-path>:/var/run/docker.sock, something like mount --bind is betterYes 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
DOCKER_HOST=unix:///run/user/1001/podman/podman.sockcase that is expected to work@brianjmurrell commented on GitHub (Jul 10, 2024):
In fact
ln -sf(i.e. the workaround above) is working. But only if I set SELinux to permissive (which is a bad thing).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
actactually using it's hacky list of paths at this point? What is failing here is adockercommand initiated from the workflow in the runner. This is just regulardockerhere isn't it? It would use$DOCKER_HOSTif it were propagated into the runner namespace wouldn't it? Of course that assumes that the path that$DOCKER_HOSTpoints at is mounted into the runner also doesn't it?So are you asking for more information? I'd be happy to provide whatever is necessary. I can tell you that
DOCKER_HOSTis unset in runner. That seems like the minimum requirement for all of this to work doesn't it?@ChristopherHX commented on GitHub (Jul 10, 2024):
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
@ChristopherHX commented on GitHub (Jul 10, 2024):
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,
DOCKER_HOSTshould be enough for act if it is aunix://protocol to use podman of any socket location that is desired.Also act does never add any bind mount selinux labels, so I doubt act works well
@brianjmurrell commented on GitHub (Jul 10, 2024):
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
actrunner are intercepting thesedockercommands in therun:statement and turning them into API requests?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
actwhere to find the socket works fine. It's the problem of then using thedockercommand inside the workflow on the runner that is having the problem.@ChristopherHX commented on GitHub (Jul 10, 2024):
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)
Except that I'm writing about dind images, in your cases is the podman daemon outside of the workflow container
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
@ChristopherHX commented on GitHub (Jul 10, 2024):
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
After bind mount you have a dead symlink in the container
Keep in mind avoiding errors is not the same as making things work
@brianjmurrell commented on GitHub (Jul 10, 2024):
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
dockercommands inside the runner. I'm not sure how else docker would be used inside the runner.Yes, I am using podman just fine, modulo wanting to use
dockerin arun:step due to the assumption of binding/var/run/docker.sockinto the runner container. It seems to me thatactshould be binding whatever socket it is using into the container, not a hard-coded (or however it's determined)/var/run/docker.sock.@ChristopherHX commented on GitHub (Jul 10, 2024):
But act does exactly that for me, please expand the collapsed log in
https://github.com/nektos/act/issues/2393#issuecomment-2221174801.Only the dest socket
/var/run/docker.sockis hardcoded as of now, with the option to turn off that mountHowever it doesn't solve your problem, because the socket bind mount is the cause of your problem
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.
@brianjmurrell commented on GitHub (Jul 16, 2024):
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:
If so, any viable work-around?
@ChristopherHX commented on GitHub (Jul 19, 2024):
Yes exactly like that is always broken.
Workaround A:
-P ubuntu-latest=-self-hostedWorkaround B:
docker cp(you may need to pipe a tar file via-, not shure how the cli transfers files by default in this setup)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
@ChristopherHX commented on GitHub (Aug 11, 2024):
In https://github.com/nektos/act/issues/2393 is now a
--dindflag to get a priviledged dind container per job.The following
docker run -v $PWD:$PWD --rm alpine:latest ls $PWDworks in that scenarioWith
--reuseas well you can speed up a debug cycle by not purging the dind container and let it run between restarts of act.@ChristopherHX commented on GitHub (Aug 11, 2024):
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.
@github-actions[bot] commented on GitHub (Feb 8, 2025):
Issue is stale and will be closed in 14 days unless there is new activity