Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support host.docker.internal DNS name to host #264

Closed
2 of 3 tasks
Mahoney opened this issue Mar 31, 2018 · 272 comments
Closed
2 of 3 tasks

Support host.docker.internal DNS name to host #264

Mahoney opened this issue Mar 31, 2018 · 272 comments

Comments

@Mahoney
Copy link

Mahoney commented Mar 31, 2018

  • This is a bug report
  • This is a feature request
  • I searched existing issues before opening this one

Expected behavior

As in docker-for-mac and docker-for-windows, inside a container, the DNS name host.docker.internal resolves to an IP address allowing network access to the host (roughly the output of ip -4 route list match 0/0 | cut -d' ' -f3 inside the same container).

Actual behavior

host.docker.internal resolves to nothing

Steps to reproduce the behavior

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

See it returns nslookup: can't resolve 'host.docker.internal': Name does not resolve

Output of docker version:

Client:
 Version:	18.03.0-ce
 API version:	1.37
 Go version:	go1.9.4
 Git commit:	0520e24
 Built:	Wed Mar 21 23:10:09 2018
 OS/Arch:	linux/amd64
 Experimental:	false
 Orchestrator:	swarm

Server:
 Engine:
  Version:	18.03.0-ce
  API version:	1.37 (minimum version 1.12)
  Go version:	go1.9.4
  Git commit:	0520e24
  Built:	Wed Mar 21 23:08:36 2018
  OS/Arch:	linux/amd64
  Experimental:	false

Output of docker info:

Containers: 0
 Running: 0
 Paused: 0
 Stopped: 0
Images: 1
Server Version: 18.03.0-ce
Storage Driver: overlay2
 Backing Filesystem: extfs
 Supports d_type: true
 Native Overlay Diff: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: bridge host macvlan null overlay
 Log: awslogs fluentd gcplogs gelf journald json-file logentries splunk syslog
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: cfd04396dc68220d1cecbe686a6cc3aa5ce3667c
runc version: 4fc53a81fb7c994640722ac585fa9ca548971871
init version: 949e6fa
Security Options:
 apparmor
 seccomp
  Profile: default
Kernel Version: 4.13.0-37-generic
Operating System: Ubuntu 17.10
OSType: linux
Architecture: x86_64
CPUs: 1
Total Memory: 1.947GiB
Name: rob-VirtualBox
ID: 3L2C:BTV3:TQO2:4SAG:XVW5:744G:MPWQ:62FK:56DP:KH3Z:EQ7Z:TBR5
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
Labels:
Experimental: false
Insecure Registries:
 127.0.0.0/8
Live Restore Enabled: false

WARNING: No swap limit support

Additional environment details (AWS, VirtualBox, physical, etc.)

Running Ubuntu in VirtualBox 5.2.8 on OS/X 10.13.4

@bscheshirwork
Copy link

bscheshirwork commented Apr 2, 2018

same situation. I want to use this in docker-compose.yml for replace remote_host

    environment:
      XDEBUG_CONFIG: "remote_host=192.168.0.83 remote_port=9001 var_display_max_data=1024 var_display_max_depth=5"
$ docker-compose -f ~/projects/docker-yii2-app-advanced/docker-run/docker-compose.yml run --rm --entrypoint nslookup php "host.docker.internal"
Creating network "dockerrun_default" with the default driver
Creating dockerrun_mysql_1 ... done
Creating dockerrun_db_1    ... done
nslookup: can't resolve '(null)': Name does not resolve

nslookup: can't resolve 'host.docker.internal': Name does not resolve
...
Kernel Version: 4.4.0-116-generic
Operating System: Ubuntu 16.04.4 LTS

@bscheshirwork
Copy link

https://docs.docker.com/docker-for-mac/networking/#use-cases-and-workarounds

I want to connect from a container to a service on the host

The host has a changing IP address (or none if you have no network access). From 18.03 onwards our recommendation is to connect to the special DNS name host.docker.internal, which resolves to the internal IP address used by the host.

The gateway is also reachable as gateway.docker.internal.

@JuxhinDB
Copy link

JuxhinDB commented Apr 11, 2018

Same situation, when taking a closer look at /etc/hosts I notice the following:

172.17.0.2 f85e063d8c3e

Which suggests that it's just setting it to a random ID rather than host.docker.internal which is what I need.

@Zomis
Copy link

Zomis commented Apr 15, 2018

When I tried to find out how to connect to host from Docker I found this question/answer on Stack Overflow: https://stackoverflow.com/a/43541732/1310566

I was not aware at the time that it only applied to macOS and Windows (it was just recently edited)

@atolia
Copy link

atolia commented May 1, 2018

While this feature not on linux I use

web:
  image: httpd:2.4
  volumes:
    - ......
  entrypoint: 
  - /bin/sh
  - -c 
  - ip -4 route list match 0/0 | awk '{print $$3" host.docker.internal"}' >> /etc/hosts && httpd-foreground 

@bscheshirwork
Copy link

@atolia
This look like work with docker-compose exec web and don't work with docker-compose run --rm --entrypoint /bin/bash web

@hernandev
Copy link

hernandev commented May 8, 2018

Mimic on that can be done with:

echo -e "`/sbin/ip route|awk '/default/ { print $3 }'`\tdocker.host.internal" | sudo tee -a /etc/hosts > /dev/null

Notice @atolia already provided a similar solution, but he is not considering non-privileged default USER, this one will work for non-root images with passwordless sudo available, for images where default user is root, just remove the sudo part.

This command will make docker.host.internal available regardless of the Docker version OR execution mode. I'm using this on entrypoint files.

@acuthbert
Copy link

Firstly - docker is an amazing tool and so thank you for all who work tirelessly on it! As a leader of a large mixed team of linux and mac engineers this has been one of the biggest "why did we leave vagrant" questions I get hammered about when we called time on vagrant. It is very frustrating that this exists on mac and windows and not linux. We need connect back for xdebug and for letting selenium running in a container to access local urls for acceptance testing. This difference is bloating our build scripts with more and more fragility so it would be great if this was standardised. Is it not a worry if the same version of docker engineer on the 3 platforms can deviate in feature set?

@FX-HAO
Copy link

FX-HAO commented May 16, 2018

docker.host.internal is still unavailable on my mac. And I can't connect to my host with 172.17.0.1.
My docker version:

Client:
 Version:      18.03.1-ce
 API version:  1.37
 Go version:   go1.9.5
 Git commit:   9ee9f40
 Built:        Thu Apr 26 07:13:02 2018
 OS/Arch:      darwin/amd64
 Experimental: false
 Orchestrator: swarm

Server:
 Engine:
  Version:      18.03.1-ce
  API version:  1.37 (minimum version 1.12)
  Go version:   go1.9.5
  Git commit:   9ee9f40
  Built:        Thu Apr 26 07:22:38 2018
  OS/Arch:      linux/amd64
  Experimental: true

@chaospixel
Copy link

chaospixel commented May 16, 2018

In case you missed it: docker.for.mac.host.internal and docker.for.mac.localhost do work - but only on docker for mac...

@FX-HAO
Copy link

FX-HAO commented May 16, 2018

From 18.03 onwards our recommendation is to connect to the special DNS name host.docker.internal

Older aliases are deprecated in favor of this one. And I tried them, not working.

@mnd999
Copy link

mnd999 commented May 16, 2018

Not working here either (unsurprisingly).

@mnd999
Copy link

mnd999 commented May 16, 2018

@JuxhinDB it's not a random number, it's the container id. Still not useful though.

@jcoutch
Copy link

jcoutch commented May 18, 2018

I'm running a microsoft/dotnet-framework container on a Windows host (v18.03.1-cd-win65 17513), and host.docker.internal does not work.

@kunal-bhatia
Copy link

Any idea, when will linux support for connecting to special DNS will be fixed?

@bscheshirwork
Copy link

@kunalbhatia87 wait 4 resolve this issue? 😆

@rfay
Copy link

rfay commented May 23, 2018

There are several comments (and workarounds) here that mistakenly use "docker.host.internal", which I don't think was ever supported. The hostname we want to be supported is the one that's supported in Docker for Windows and Docker for Mac, "host.docker.internal"

@rfay
Copy link

rfay commented May 23, 2018

@Mahoney I think you should check "This is a bug report" in the OP. This is a bug. Docker team, please acknowledge it, thanks!

@Mahoney
Copy link
Author

Mahoney commented May 23, 2018

@rfay I'm not aware of this ever being a documented feature of Linux docker - as far as I can see it's only documented for docker-for-mac and docker-for-windows, and only as a recent change in each case. I couldn't find any discussion around the choice or anything to suggest it had been agreed as something all versions of Docker should implement, though it would make sense to me if it were.

So as far as I can see "feature request" rather than "bug" is the correct categorisation.

@brunosaboia
Copy link

brunosaboia commented May 31, 2018

@Mahoney while I do agree that this is a feature request, it's an important one. In the end, you want your dev team to use a shared config file all across — the underlying OS should be indifferent.

For me, running Linux on a Mac-based team, it's very bad to have to either create and ignore the changes to a config file, or to have to create hosts entries in each VM to mimic Docker for Mac behavior. I think it's simpler to just have an additional entry on the Docker networking so that the host is always reachable using the same hostname.

@jtreminio
Copy link

@brunosaboia What I do while waiting for this to be resolved is create Linux-specific config files and mount them via docker-compose.override.yml.

Not the perfect workaround, but it is the best solution right now.

@mrpink76
Copy link

I'm running a windows container on a windows host:
microsoft/dotnet:2.1-aspnetcore-runtime-nanoserver-1709

host.docker.internal does not work to connect to a service on the host.

@Mahoney
Copy link
Author

Mahoney commented Jun 14, 2018

Issues with docker for windows should be raised in the docker/for-win repo after an appropriate search such as https://github.com/docker/for-win/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+host.docker.internal

@atrauzzi
Copy link

Yeah, this definitely needs to be implemented so that we can have consistency.

Really, containers should always have had something like this anyway.

@Olegt0rr
Copy link

Olegt0rr commented Jun 15, 2022

@Mahoney, why the issue is closed? It's still actual for linux :(

@Mahoney
Copy link
Author

Mahoney commented Jun 15, 2022

See comments #264 (comment) and #264 (comment)

@pheirendt-jama
Copy link

pheirendt-jama commented Jun 15, 2022

Note that a related bug was recently fixed in Docker Desktop (for Windows?) 3.3.0 (2021-04-08). Search for "host-gateway" to see the bug.

Also note that the solution is undocumented -- a search of all Docker docs for "host-gateway" shows no mention in the documentation. (Except for slight mention in the Docker Daemon CLI (dockerd) document.)

@joffrey-bion
Copy link

joffrey-bion commented Nov 24, 2022

Sorry to bring this back, but how can I get the Docker daemon itself to reach the host?

I'm trying to do docker login localhost:8390 from the host machine, where the registry is a local server that does NOT run in a container. On Windows and macOS, I need host.docker.internal because the daemon is running in the Linux VM, so when reaching the registry running on the host it needs to reach the host OS. I'd like to be able to use the same code and address on all OSes.

Is there any configuration I can do on Linux so the daemon itself knows about host.docker.internal? I cannot --add-host to the daemon, right?

@tomu123
Copy link

tomu123 commented Nov 29, 2022

Note that a related bug was recently fixed in Docker Desktop (for Windows?) 3.3.0 (2021-04-08). Search for "host-gateway" to see the bug.

Also note that the solution is undocumented -- a search of all Docker docs for "host-gateway" shows no mention in the documentation. (Except for slight mention in the Docker Daemon CLI (dockerd) document.)

Also the only documentation that mentions it says the host-gateway defaults to the default bridge ip instead of saying that it defaults to the docker internal host address which makes it really confusing even if you find this piece of documentation. I'm not really sure they mean the same since I'm not really knowledgeable in networking. Hopefully anyone could give me insight on that and they update the documentation soon.

@droplet-js
Copy link

any news update?
why docker in linux must add ' --add-host="host.docker.internal:host-gateway" ', and docker in mac not need '--add-host'?

@droplet-js
Copy link

how to setup docker in linux?

@dimitri-lda
Copy link

dimitri-lda commented Feb 4, 2023

when taking a closer look at /etc/hosts I notice the following:

172.17.0.2 f85e063d8c3e
Which suggests that it's just setting it to a random ID rather than host.docker.internal which is what I need.

Thanks! That's helped me. I had 172.22.0.5

@zeorin
Copy link

zeorin commented Apr 13, 2024

On Linux with Docker version 24.0.5, the magic variable host-gateway refers to the default bridge network only. Using extra_hosts to explicitly set host.docker.internal to host-gateway will set it to the default bridge network's host IP address, even if the container is not connected to that network.

I worked around this by adding

echo "$(ip route | awk '/default/ { print $3 }' | head -n 1)\thost.docker.internal" | sudo tee -a /etc/hosts > /dev/null

To the command in docker-compose.yml.

NeedleInAJayStack added a commit to NeedleInAJayStack/jays-server that referenced this issue Aug 31, 2024
Not working because custom networks (`monitoring`) cannot access use `host-gateway` to access the host machine: docker/for-linux#264 (comment) Solving requires attaching to default bridge network or doing some janky iptables stuff...
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests