Support external DOCKER_HOST from inside WSL #7420
Comments
|
that is correct, we currently only use the Docker without using respecing the DOCKER_HOST env var (mostly because of the complexity of handling minikube docker-env) @nnashok do you mind sharing your DOCKER_HOST env ? excuse me for my ignorance on windows and WSL2, but is this a problem that anyone runnning it on WSL would have (will they all have a custom DOCKER_HOST) ? or do you happen to have a custom DOCKER_HOST because of your own company or settings ? alternatively, I am curious is it possible to install docker inside WSL so you don't have to use the Docker outside the WSL vm ? |
medyagh
added
kind/bug
It's set to
This is a standard setting, not specific to myself or my company.
I have not tried to install Docker daemon within my WSL. With the way i have setup, I can use Docker for Windows and use the same daemon to run my containers from Windows |
tstromberg
changed the title
tstromberg
removed
co/docker-env
tstromberg
changed the title
tstromberg
changed the title
|
This is not yet a priority for the minikube project, but if someone is interested in making this work, I suggest starting by commenting out: minikube/pkg/drivers/kic/oci/oci.go Line 482 in bfdb710 It may be possible that things just work if this method was updated to only overwrite DOCKER_HOST if it points to 127.0.0.1. |
tstromberg
added
kind/feature
|
I'm interested in fixing this. I'll create the PR etc, will have to wait for clearance from my company though. |
|
@nnashok are you still interested in doing this PR ? |
|
@medyagh @nnashok: I'm also very interested in this PR/a fix. My team and I are currently looking for a way to launch minikube instances on Kubernetes pods using the DinD as a sidecar method. We're having issues getting minikube running in one pod container to communicate with a Docker daemon running in another pod container (and listening at 0.0.0.0:2375). Seems as though the Note that btw - operating on Linux/Fedora32/Centos7 |
|
Yes, I'm still interested.
On Tuesday, May 12, 2020, 9:25:59 PM PDT, 0xO1 <notifications@github.com> wrote:
@medyagh @nnashok: I'm also very interested in this PR/a fix.
My team and I are currently looking for a way to launch minikube instances on Kubernetes pods using the DinD as a sidecar method. We're having issues getting minikube running in one pod container to communicate with a Docker daemon running in another pod container (and listening at 0.0.0.0:2375).
Seems as though the DOCKER_HOST envvar is not being respected by minikube nor is the --docker-opt[=-H tcp://localhost:2375] cmd-flag.
Note that docker ... commands run fine.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
|
As long as your external docker daemon is able to run privileged containers, it "should" work. The URLs will all be 127.0.0.1, but should not be an issue as long as running on the same host. Like Thomas said, probably we should look for Or we could just leave the variables as they were, if they were not originally set by minikube ? Currently it wipes all of them - always, which is why it is not respecting the user settings anymore. // DockerHostEnv is used for docker daemon settings
DockerHostEnv = "DOCKER_HOST"
// DockerCertPathEnv is used for docker daemon settings
DockerCertPathEnv = "DOCKER_CERT_PATH"
// DockerTLSVerifyEnv is used for docker daemon settings
DockerTLSVerifyEnv = "DOCKER_TLS_VERIFY" // DockerDaemonEnvs is list of docker-daemon related environment variables.
DockerDaemonEnvs = [3]string{DockerHostEnv, DockerTLSVerifyEnv, DockerCertPathEnv}The original idea was to not talk to the docker-in-docker in minikube, but to the host: // Universally ensure that we never speak to the wrong DOCKER_HOST
if err := oci.PointToHostDockerDaemon(); err != nil {
glog.Errorf("oci env: %v", err)
}Not to reset the user's docker settings, of using Eventually we will need to fix the scenario where docker / podman is not running on localhost. That is, if you publish a port in the docker daemon we expect it to be available from Just not for Podman: #8003 @0x0i : you might want to open a separate issue, about your minikube in Kubernetes use case. It would be nice to document it, next to the minikube in CI scenario: |
|
PR added: 4 bytes... (moved two brackets) - and some The user will still be disappointed if their docker or podman environment is not running on localhost (like WSL or pod), but didn't add any code to validate that they only use e.g. tcp://localhost:2375 I suppose you could also set up your own tunneling, but it gets a bit tedious since minikube uses random ports. So ultimately it will need to tunnel those ports too, just like it tunnels k8s for docker. But for these scenarios (i.e. WSL and pod), then I think it is accessible from "localhost" since it shares some kind of networking bridge between them. In the case of WSL2, I guess it's a VM ? https://docs.microsoft.com/en-us/windows/wsl/compare-versions#accessing-network-applications https://kubernetes.io/docs/concepts/cluster-administration/networking/ |
|
I was trying to download the binaries from this PR to test locally but couldn't find a link. Do I need to build it locally? I thought every PR's binaries could be downloaded. |
Sounds good and will do @afbjorklund. |
|
Thanks @tstromberg . I tried to use the minikube-linux-amd64.tar.gz from my Ubuntu (running over WSL) with Observations:
|
seems like if use the 127.0.0.1 IP in WSL that would work, the question is how can we detect we are running in WSL ? I have not used WSL myself, when u are in WSL do u use the minikube linux binary ? |
medyagh
added
priority/important-soon
|
related microsoft/WSL#423 |
|
@nnashok here is the link to the binary from a PR that I think might fix this issue, do you mind trying it out ? http://storage.googleapis.com/minikube-builds/8368/minikube-linux-amd64 |
I should mention that this is not the case for me - my About Docker screen
docker version$DOCKER_HOSTdocker psdocker run hello-worldEDIT: More than that, trying to set Same happens with P.S. Also added more details about the setup. |
|
Having said that, I've just tried the Linux binary from #7420 (comment) and it worked! |
Excellent , glad to see that worked for you, it will be included in the next release, we plan to have a beta release in two weeks |
Can this be merged into a more official release?I can confirm that this build does fix the DOCKER_HOST uptake. Because it conects from my WSL-> to my Docker Desktop on tcp://localhost:2375
|
|
Sadly, this did not fix the issue on my setup: I changed DOCKER_HOST to use 127.0.0.1, but same result: |
|
@dandosi @nezorflame https://github.com/kubernetes/minikube/releases/tag/v1.12.0-beta.0 closing as it was fixed |
|
Why was this closed? I said in #7420 (comment) that its not fixed. I think? I tried again with the release binaries and they still don't work. |
|
I transfer data from unix socket to tcp port, it works for me.
|
|
@relaxgo This works!! I need to run that command in the background, i.e. |
Steps to reproduce the issue:
Full output of failed command:
Full output of
minikube startcommand used, if not already included:Optional: Full output of
minikube logscommand:😿 minikube is exiting due to an error. If the above message is not useful, open an issue:
👉 https://github.com/kubernetes/minikube/issues/new/choose
The text was updated successfully, but these errors were encountered: