Open charlyschulte opened 2 months ago
Thank you for your issue report!
One thing I see here is that the current setup starts a Docker container that is deployed on a Hetzner instance. That also means that running docker build
will try to talk to the Docker daemon, but of course it won't be accessible as it is already running inside a container. And exposing the Docker socket is a bad idea AFAIK :thinking:
Do you have a stripped down version of your Github CI YAML? The underlying Github container I am using is built using docker/setup-buildx-action
which theoretically should also make this use case work. See here for an example.
Thanks for the quick response. here is my ci yaml: name: Build and Publish
on: push: branches:
jobs: prepare_env: runs-on: ubuntu-latest name: Create new Hetzner Cloud instance for build steps:
uses: stonemaster/hetzner-github-runner@HEAD with: github-api-key: ${{ secrets.GH_API_KEY }} hetzner-api-key: ${{ secrets.HETZNER_API_KEY }} hetzner-instance-type: cx22 hetzner-location: fsn1 build-with-commit-tag: runs-on: self-hosted needs: prepare_env steps:
name: Add SHORT_SHA env property with commit short sha
run: echo "SHORT_SHA=echo ${GITHUB_SHA} | cut -c1-8
" >> $GITHUB_ENV
uses: actions/checkout@v2.5.0
name: Create .env file run: | touch .env.local echo "SECRETS=#######" >> .env.local
name: Set up Docker Buildx uses: docker/setup-buildx-action@v3
name: Log in to GitHub Container Registry uses: docker/login-action@v2 with: registry: ghcr.io username: ${{ github.actor }} password: ${{ secrets.TOKEN }}
name: Build and push Docker image uses: docker/build-push-action@v6 with: context: . file: ./Dockerfile platforms: linux/arm64 push: true tags: ####### cache-from: type=gha cache-to: type=gha,mode=max
when i run the docker/setup-buildx-action i also get an "Cannot connect to the Docker daemon" error. maybe you have an idea thanks again Charly
@stonemaster do you have any idea why it is not working? greetings Charly
@charlyschulte I am very sorry for my delayed response.
I just reproduced your testcase with an own repository and also ran in the permission denied issue
you have seen.
It indeed is due to the fact that the action Github runner runs in a Docker container which in turn cannot have access to the Docker daemon right now.
I will have to think about a solution (very probably exposing the docker socket file into the runner container on Hetzner), but out of security concerns I will probably also have this behind a new flag in this action.
Please bare with me as I am a little short on time right now but I'll definitely work on this and will keep you posted through this issue!
Hey @stonemaster thanks for looking into it. I am happy, that you could reproduce the error, that means i dont have and errors on my side.
If you could implement that, it would be really awesome. But i am bot sure about the Security concern, as the the Server will get deleted afterwards, so any potencial Thread will just result in an afterwards deleted Server or am i missing something? Anyways, thanks for your time. I am looking forward for the implementation Greetings
This is actually a very good point. The primary security concern is that it would allow Github CI jobs to start docker containers on the host. Giving the temporary nature of the Hetzner cloud instances in this action I might be just overthinking it :+1:
maybe also configure
I have trying some stuff and getting the Docker container used in this marketplace action to work but unfortunately it is trickier than I initially thought :disappointed: The setup works per se and I found an elegant way to communicate to the host's Docker daemon which in turn allows to build other containers, but my test CI project didn't work out because the Github CI actions themselves rely on mounting local data to the docker containers they spawn (which in turn doesn't work).
I am unsure in which direction to go now, but I think the current implementation using a Docker Container for the Github runner seams to be a dead-end. I found this official Github repository which provides VM images for runners and could be used as a basic for Hetzner instances. This might be a solution but is probably a lot work right now ...
Is using podman an option?
Is using podman an option?
Good question. I personally don't have any experience with podman
but reading through some information suggest that podman
doesn't need root privileges. But any CI job using this hetzner action would then need to be adapted to use podman instead of Docker (given that podman works).
Hello, first of all thanks for your great work. i would really like to use the script and build my container on the hetzner cloud. i have now tried for many hours get it working, the problem is, that i get ERROR: Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running? every time i try to use docker build in my workflow. do you have any idea to get the build command to work? or is it simply not possible to build a container within the container?