I have installed the official latest helm charts on my kubernetes cluster and have set everything up, builds are working correctly. However I cannot figure out how I am supposed to run any docker commands. I keep receiving the error, “Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?” I read that in the kube native version there should be no need for mounting the host docker (although I have also made endless attempts to do that without any luck).
Here is my simple pipeline:
kind: pipeline
type: kubernetes
name: default
steps:
name: test
image: plugins/docker
commands:
docker ps -a
Oddly enough I am able to run the task via settings, which does build and push my image so I’m not sure what it is doing differently. For my needs I do no want to build and push and image. I want to build an image, run the image, and then depending on the output, push that image, so I need something more customizable. I see the command the image runs but when I try to call them myself they don’t work, what is this image doing inside differently that allow it to call docker build, while I cannot?
Been banging my head off the wall for hours now, any help is much appreciated:)
Oddly enough I am able to run the task via settings, which does build and push my image so I’m not sure what it is doing differently.
this is because when you added commands to the plugin step, the commands replace the plugin container’s entrypoint and therefore replace all plugin functionality, which includes starting an internal docker-in-docker daemon.
Ah I had tried both of those in so many different ways but it looks like I had been missing the sleep! A lot of different info out there with docker vs kubernetes and being new to this made it all very confusing. Thank you.
Hmmm, the solutions for docker vs kubernetes are pretty much the same. We are not adverse to feedback that things are confusing and we recognize there is room for improvement, however, we would kindly ask for specific, actionable feedback, otherwise it is difficult to improve.
Honestly I think it all came down to the missing sleep, which appears to have not been included in a lot of the articles I found online, which led me to believe I was doing something that would work for docker only or that I was potentially using the kubernetes runner wrong
If you’re already pulling the docker layers as a result of using docker:dind, you can use the timeout command to watch for the daemon to become responsive. I think it’s a better approach than trying to guess a good timeout value since that will vary between runners.
- name: wait-for-dind
image: docker.io/library/docker:stable
commands:
- timeout 15s sh -c -- 'while (! docker info > /dev/null 2>&1); do :; done;' || true
- docker info
The || true makes sure docker info runs no matter what and helps ensure you don’t end up with silent (unlogged) failures from swallowing the output in the loop.
I use the above with a TLS based dind service and the docker command seems to have a built in ~3s wait before retries. If you’re binding directly to the socket and don’t want to hammer it you could add sleep to the loop.
- timeout 15s sh -c -- 'while (! docker info > /dev/null 2>&1); do sleep 1; done;' || true