Azure / draft-classic

A tool for developers to create cloud-native applications on Kubernetes.
https://draft.sh
MIT License
3.93k stars 397 forks source link

"draft up" fails while building Docker Image with error "Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?" on WSL #759

Closed cnadolny closed 6 years ago

cnadolny commented 6 years ago

Not sure if it helps but: I have docker aliased to docker.exe in my bashrc, and I'm otherwise able to run docker commands normally without this error.

I'm using Ubuntu on Windows.

bacongobbler commented 6 years ago

Hmm, there might be some oddities with how Docker for Windows is able to communicate with the HyperV VM, but not from the WSL side. Since you've symlinked docker.exe in your bashrc, it's going to run it under the Windows runtime. I bet if you tried a native Linux client for docker you might hit the same error as you are with Draft.

Since you have docker running on the Windows side, can you try using the native Windows client for Draft (rather than the Linux client) and see how that goes? I've had much better success if I'm running everything from one side of the pond (Windows vs. WSL). It doesn't seem to work that well if I'm running half the stuff on Windows and the other half on WSL.

squillace commented 6 years ago

ping Sarah Cooley about this; bet she knows how it should be done. and Craig Wilhite.

cnadolny commented 6 years ago

Confirmed that it worked on the native Windows client for draft!

I also ended up exposing the daemon on tcp://localhost:2375 without TLS in Docker settings, and set an environment variable in WSL for DOCKER_HOST, export DOCKER_HOST="tcp://127.0.0.1:2375", which then got past the error with Docker I was seeing.

squillace commented 6 years ago

also, @cnadolny, see thread: https://twitter.com/nunixtech/status/996502232932679680

bacongobbler commented 6 years ago

I looked into this and it doesn't look like there's any other solutions for this: Docker needs to be running from the Windows side. The workarounds as you mentioned (native Windows client for Draft or exposing the engine's API and setting DOCKER_HOST) are what needs to be done to use Draft from WSL.

The other alternative is to run Draft with an alternative container builder (such as ACR Build, documented here) which eliminates docker as a runtime dependency, and therefore makes life a little simpler for folks running Draft on WSL. Perhaps if we integrate with genuinetools/img we could switch that over as the default container builder, but that depends on whether img works on WSL.

Thank you for taking the time to look into this! :)

nunix commented 6 years ago

as @squillace mentioned, there's a couple blogs done by Microsoft or the WSL community that could solve this issue. Concerning the error, a "rapid" way to fix it would to use the npiperelay done by Microsoft (partially explained in the blog post). This one will allow to have an unchanged behavior (read: use the docker socket) in WSL. As for the access, while you are in your machine it doesn't really matter, but here is a TLS setup (quite easy to follow): https://raesene.github.io/blog/2018/03/29/WSL-And-Docker/

hope this helps.