`--add-host=host.docker.internal:host-gateway` doesn't work like it does on Linux

[Atemu]

For repro, start something on the host that listens on a certain port like python3 -m http.server.

Then run

docker run -it --rm --add-host=host.docker.internal:host-gateway nixery.dev/shell/pingtcp pingtcp host.docker.internal 8000

On a Linux machine, this successfully pings port 8000. With colima, it's unable to handshake because host.docker.internal now resolves to the Linux VM where the python http server isn't running.

This flag (and its equivalent docker-compose declaration) is often used in order to give Linux users' containers access to the host address because host.docker.internal doesn't work there by default.

[abiosoft]

This flag (and its equivalent docker-compose declaration) is often used in order to give Linux users' containers access to the host address because host.docker.internal doesn't work there by default.

But host.docker.internal works with docker containers on Colima, or does it not?

[Atemu]

Yes, that works by default but not when adding this flag, which is often done by docker-compose files for compatibility with Linux.

[paymog]

looks like this issue may be stale. I have a docker compose file with that host mapping for compatibility across linux and mac. However, when trying out my compose file with colima, everything worked flawlessly.

 ❯❯❯ colima version
colima version 0.4.6
git commit: 10377f3a20c2b0f7196ad5944264b69f048a3d40

runtime: docker
arch: aarch64
client: v20.10.20
server: v20.10.18

[rfay]

host.docker.internal is always 192.168.5.2 on colima/lima.

[efgpinto]

I think I'm facing the same issue.

While on colima:

$ colima version
colima version HEAD-030393c
git commit: 030393ccc5ab74153809ed00dbe965325d3cd7af

$ python3 -m http.server
Serving HTTP on :: port 8000 (http://[::]:8000/) ...

Cannot do the handshake:

$ docker run -it --rm --add-host=host.docker.internal:host-gateway nixery.dev/shell/pingtcp pingtcp host.docker.internal 8000
(...)
Digest: sha256:d35346995775beb2f3b1cf0f7c4411ca493359a791cbf1dedd3d1cc2cf4f5367
Status: Downloaded newer image for nixery.dev/shell/pingtcp:latest
WARNING: The requested image's platform (linux/amd64) does not match the detected host platform (linux/arm64/v8) and no specific platform was requested
PINGTCP host.docker.internal (172.17.0.1:8000)
Unable to handshake with host.docker.internal:8000 (172.17.0.1): attempt=1
(...)
^C
--- host.docker.internal:8000 pingtcp statistics ---
13 handshake(s) started, 0 succeeded, 100.000% loss, time 12447.670 ms
rtt min/avg/max/mdev = 0.000/0.000/0.000/0.000

However, if I turn down colima and run with Docker Desktop, it handshakes successfully: Handshaked with host.docker.internal:8000 (192.168.65.2): attempt=1 time=0.963 ms

Another interesting thing is that a simple curl actually works even with the Colima setup:

$ docker run --rm curlimages/curl:7.86.0 -L -v http://host.docker.internal:8000` 
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0*   Trying 192.168.5.2:8000...
* Connected to host.docker.internal (192.168.5.2) port 8000 (#0)
> GET / HTTP/1.1
> Host: host.docker.internal:8000
> User-Agent: curl/7.86.0-DEV
> Accept: */*
(...)

This is on a MacOS M1. Any hints on how to debug this further would be very appreciated.

[abiosoft]

You do not need the --add-host flag for Colima. host.docker.internal works out of the box except you specify a custom dns server.

[efgpinto]

You do not need the --add-host flag for Colima. host.docker.internal works out of the box except you specify a custom dns server.

I see now, it actually works if I remove the --add-host. And it also works if I don't specify the extra_hosts: with "host.docker.internal:host-gateway" on a docker compose file (which was my original issue).

Great to have this working! Thanks @abiosoft !

So my question now would be, would it make sense to somehow make this compatible to ease the drop-in replacement from docker desktop to colima, allowing the same docker compose to be used? Or is there any other workaround to make it so someone with colima can still run such docker compose without issues? Sorry if the answer to this is obvious.

[abiosoft]

@efgpinto yeah, it can be made to work. Kindly bear in mind that this is not a priority for the next release v0.5.0 but it would be considered.

[efgpinto]

Understood, thank you very much @abiosoft ! 🙇