-
Notifications
You must be signed in to change notification settings - Fork 86
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
Comments
same situation. I want to use this in docker-compose.yml for replace 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
|
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. |
Same situation, when taking a closer look at
Which suggests that it's just setting it to a random ID rather than |
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) |
While this feature not on linux I use
|
@atolia |
Mimic on that can be done with:
Notice @atolia already provided a similar solution, but he is not considering non-privileged default This command will make |
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? |
|
In case you missed it: docker.for.mac.host.internal and docker.for.mac.localhost do work - but only on docker for mac... |
Older aliases are deprecated in favor of this one. And I tried them, not working. |
Not working here either (unsurprisingly). |
@JuxhinDB it's not a random number, it's the container id. Still not useful though. |
I'm running a |
Any idea, when will linux support for connecting to special DNS will be fixed? |
@kunalbhatia87 wait 4 resolve this issue? 😆 |
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" |
@Mahoney I think you should check "This is a bug report" in the OP. This is a bug. Docker team, please acknowledge it, thanks! |
@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. |
@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. |
@brunosaboia What I do while waiting for this to be resolved is create Linux-specific config files and mount them via Not the perfect workaround, but it is the best solution right now. |
I'm running a windows container on a windows host: host.docker.internal does not work to connect to a service on the host. |
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 |
Yeah, this definitely needs to be implemented so that we can have consistency. Really, containers should always have had something like this anyway. |
@Mahoney, why the issue is closed? It's still actual for linux :( |
See comments #264 (comment) and #264 (comment) |
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.) |
Sorry to bring this back, but how can I get the Docker daemon itself to reach the host? I'm trying to do Is there any configuration I can do on Linux so the daemon itself knows about |
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. |
any news update? |
how to setup docker in linux? |
Thanks! That's helped me. I had 172.22.0.5 |
Setup `xdbug.client_host` to `host.docker.internal`. See https://docs.docker.com/desktop/networking/#i-want-to-connect-from-a-container-to-a-service-on-the-host See docker/for-linux#264 Also setup other config values which can be configured throught the `XDEBUG_CONFIG`.
On Linux with Docker version I worked around this by adding
To the |
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...
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 ofip -4 route list match 0/0 | cut -d' ' -f3
inside the same container).Actual behavior
host.docker.internal
resolves to nothingSteps 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
:Output of
docker info
:Additional environment details (AWS, VirtualBox, physical, etc.)
Running Ubuntu in VirtualBox 5.2.8 on OS/X 10.13.4
The text was updated successfully, but these errors were encountered: