skaffold: Builds don't work if the docker socket isn't in `/var/run/docker.sock` location (using lima instead of Docker Desktop)
Actual behavior
It looks like running skaffold run fails when the docker socket isn’t in the default location of /var/run/docker.sock. Even when setting the options in the skaffold.yaml to use useDockerCLI: true the build still fails.
Expected behavior
That the docker socket file location is can be anywhere when the options in the skaffold.yaml file are set to use the docker cli and/or provide a way of overriding the expected socket location that skaffold uses.
Information
- Skaffold version: v1.35.2
- Operating system: MacOS 11.6.1
- Installed via: Homebrew
I’m using limactl version 0.8.2 instead of Docker Desktop, installed via Homebrew, along with the docker cli also installed via Homebrew. VM was created using the sample docker.yaml at https://github.com/lima-vm/lima/blob/master/examples/docker.yaml
Steps to reproduce the behavior
limactl start https://raw.githubusercontent.com/lima-vm/lima/master/examples/docker.yaml- Run the suggested commands to configure a docker context in the message output from
limactl skaffold run- Receive the following error:
getting imageID for <image id-dirty>: Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?. Docker build ran into internal error. Please retry.
If this keeps happening, please open an issue..
Normal docker commands work fine, just commands via skaffold have the issue.
I currently have a workaround where I manually create a symlink from /var/run/docker.sock to the socket that lima creates in $HOME/.lima/<vm>/sock/docker.sock
About this issue
- Original URL
- State: closed
- Created 2 years ago
- Reactions: 18
- Comments: 16 (3 by maintainers)
Hi, I succeeded to run Docker build when specified
DOCKER_HOST=unix:///home/dir/.colima/docker.sockI’m also experiencing the same issue with colima. Would love to see Docker context support added 😁
i have the same issue when using docker desktop for linux in ubuntu, as the documentation says there is another context that uses another endpoint different from
unix:///var/run/docker.sock, the context for docker desktop for linux isunix:///home/<user>/.docker/desktop/docker.sockhttps://docs.docker.com/desktop/linux/install/#context
@gsquared94, I understand that the original issue description here was about build tools that have a docker socket but place it elsewhere, and that the DOCKER_HOST workaround applies there.
But the issue description also references “useDockerCLI: true”. I think @MarlonGamez 's comment earlier mentioned that the useDockerCLI setting was a little incomplete, contributing to this problem. It sounds like build tools that do not have a docker socket at all (like using podman but without the podman system service) will still not work because of this, right?
I know there may not be bandwidth to complete the cleanup of useDockerCLI. But could an issue be created to track that it’s incomplete? Right now it kind of seems that useDockerCLI doesn’t do anything from the user’s point of view, does it? Since skaffold is still going to use the Docker Engine API anyway via the required docker socket. And/or a documentation update clarifying the state of useDockerCLI?
Thanks for your time!
@MarlonGamez, it sounds like there’s not currently a workaround for podman users not using the podman system service (and podman.sock and DOCKER_HOST) as @drewp mentioned, since there is still some code not respecting useCLI, right?
E.g. I see from our skaffold build (v1.39.2) attempting to use podman:
@agxs it looks like there are a couple places in our code where we’re not respecting the user’s use of useCLI. Would be great to comb through these and make sure we’re using docker cli where appropriate when specified. I’m not sure our team has the bandwidth to look at this/fix this soon, but PRs are always welcome
Also facing this issue trying to use Podman in place of Docker. On Mac, using a symlink to any Podman socket doesn’t work either. There is ongoing discussion in the Kubernetes Slack server, channel #skaffold related to this issue.
#5739 and #5773 are both open issues that could easily provide an alternative via Minikube, but this has been deprioritized for unexplained reasons. The Minikube team appears to have done their part for this and is waiting for the Skaffold team to do the same as noted here.
Hope these breadcrumbs help others seeking a solution.