They're close, but "docker.for.mac.host.*" and "docker.for.win.*" should be better

[atrauzzi]

When running Docker for Windows and Docker for macOS, we get these handy aliases like docker.for.mac.localhost, docker.for.mac.internal, docker.for.win.localhost and docker.for.win.internal.

Unfortunately, when my projects are being worked on between macOS and Windows, someone has to go changing any of these host names for the specific platform they're on, despite the premise of the two being the same! The fact that these two things that accomplish the exact same outcome are named differently is unhelpful.

Is there any way we can get a new convention like docker.internal and docker.localhost? Would it also be possible to simply have them resolve localhost when used on Linux which obviously doesn't have the extra layer going on?

The name of the game here is that I need my containers to have a consistent way to reference not the VM, but the actual physical hardware they're running on. Bonus points if it's a consistent IP address so that I can configure my own DNS aliases!

Moreover, would it be possible either with or without my suggested change to get all these magic hostnames documented somewhere? They seem to be rather un-googleable and largely defined by anecdotal knowledge rather than being clearly offered.

cc.

• They're close, but "docker.for.mac.host.*" and "docker.for.win.*" should be better moby/moby#36625
• They're close, but "docker.for.mac.host.*" and "docker.for.win.*" should be better for-win#1855

[akimd]

In recent releases (18.03.0-ce-rc1-mac54 for instance), we provide host.docker.internal. We were clearly wrong to use mac/win in the first place.

About the documentation part, you are right. we will do this. Currently this is "documented" in the ChangeLogs :)

[atrauzzi]

Oh jeez, so I'm just late to the party then?!? 😉

#slowpokealex

[akimd]

Done.

[seb-h-k]

Great to see. This makes things a lot simpler for us. Does it work on linux too? Would be great if we could get rid of special cases in the development configuration and have a single dns for all environments (win, mac, linux).

[atrauzzi]

Yeah, the linux case is especially important.

[tenoriojuann]

Seeing an issue after upgrading, neither host.docker.internal or gateway.docker.internal resolve when making a request within the containers to a service running on the host machine. Also the old docker.for.mac.host.internal does not work.

I am running Version 18.03.0-ce-mac60 (23751)

[Dominik-K]

@tenoriojuann Can't confirm your bug (exact same version). What does

docker run --rm alpine nslookup host.docker.internal

return?

[tenoriojuann]

@Dominik-K

The given command returns:

nslookup: can't resolve '(null)': Name does not resolve

Name:      host.docker.internal
Address 1: 192.168.65.2

My mac's IP address starts with 135.198.X.X so that 192.X.X.X is completely off

edit: I did a docker system prune --volumes and everything seems to be working now.

[atrauzzi]

@akimd - Any chance we can ensure this works on linux hosts as well? Just ran on ubuntu:

Unable to find image 'alpine:latest' locally
latest: Pulling from library/alpine
ff3a5c916c92: Pull complete 
Digest: sha256:7df6db5aa61ae9480f52f0b3a06a140ab98d427f86d8d5de0bedab9b8df6b1c0
Status: Downloaded newer image for alpine:latest

nslookup: can't resolve '(null)': Name does not resolve
nslookup: can't resolve 'host.docker.internal': Name does not resolve

Docker version 18.05.0-ce-dev, build d87b0c1

[atrauzzi]

Pinging again as this is really getting a bit stale and probably should be addressed soon to unblock this whole situation. This needs to be docker-universal.

@akimd - Any chance you can poke someone from your side of the fence over at for-linux? 😉

cc. docker/for-linux#264

[docker-robott]

Closed issues are locked after 30 days of inactivity.
This helps our team focus on active issues.

If you have found a problem that seems similar to this, please open a new issue.

Send feedback to Docker Community Slack channels #docker-for-mac or #docker-for-windows.
/lifecycle locked