Option or extension to add names to Windows' hosts file

I use DD for Windows integrated with WSL2 to develop a web app. Recent versions allow you to automatically change the C:\Windows\System32\drivers\etc\hosts file so that the *docker.internal names are resolved, but why can’t it do the same for other names?
Every time I restart the engine I have to change that file because the internal IP to which my app’s domain changes should map to have changed. It is as simple as adding a text box to collect these names, or a grid to map names on Windows to container names/IPs in Docker.
There is no extension to do this either?

Can you be more specific what you would like to achieve? You can’t set hostnames for Docker containers in the hosts file of Windows. host.docker.internal points to localhost on Windows and it points to some proxy server from containers that can forward requests to localhost on Windows. Even if you set a hostname for a container in your Windows “hosts” file, you couldn’t access the container’s IP address from the host unless you are running Windows containers. Is this the case?

Right, I made a mistake: the aliases on the hosts file wouldn’t point to the container names or IPs, but to the proxy, forwarded from host.docker.internal.
So what I’m asking about is an option or extension to add my.site.local, for example, to the hosts file pointing to the IP for host.docker.internal.

So you would like to have webserver on the host machine with multiple virtual hosts using different domains and have a Docker container that can access use the virtual host names to access a website on the host machine?

You can start a container that has nslookup in it and see the IP address.

docker run --rm -it --network test nicolaka/netshoot nslookup host.docker.internal

That will show the IP address. Mine is this: 192.168.65.254

So I can add an extra host to the container. The following example uses curl to test the hostname:

docker run --rm -it --network test --add-host my.site.local:192.168.65.254 nicolaka/netshoot curl my.site.local

In case of Docker Compose, you can add the hostnames using the extra_hosts option.

This way the hosts will not be deleted from the container.

There’s no webserver on the host, it’s on a container.
What I want to avoid is having to update the hosts file when the IP for host.docker.internal changes.

Why would that change and why would that matter? host.docker.internal on the Windows host is always 127.0.0.1 and it shouldn’t matter what IP you se from inside a container since eventually it will be redirected to 127.0.0.1 on Windows.

Can you explain what you exactly want with an example like I showed you how you could use custom hostnames?

So far you “jailed us” in what you think must be the solution for your problem, and only ask specifically about it. Though, this approach got us nowhere.

Please share the bigger picture, so we can start to see the use case you try to solve and recommend the solution you actually require.

Are you trying to inject domain names, so that a containerized reverse proxy can forward traffic to target containers depending on the domain names?

That is what I need, assuming what you mean by injecting names is telling Windows that they should be resolved by a container.

I have a webserver and a proxy running in containers. The server handles request to mysite.local and api.mysite.local between the containers (and the Ubuntu host running in WSL2), but to reach the site from Windows I need to update the hosts file so that those names point to the same IP address as host.docker.internal, which Docker itself updates in the file from time to time.
I would like to figure out a way to not have to change the hosts file manually.

I’m far from a network expert, but I don’t think this makes sense:

(From ipconfig on Windows)
Ethernet vEthernet (WSL) IP: 172.21.0.1
WiFi adapter: 192.168.50.12

The first one is what Ubuntu has for eth0, but the second one is what Docker adds to the hosts file in Windows as the address for host.docker.internal. Why the WiFi network? Shouldn’t that go to the WSL virtual adapter?

A port published in WSL2 is reachable from the host using localhost:port.

There is no need to track the wsl ip, you can just add the entries to your hosts file:

127.0.0.1 mysite.local
127.0.0.1 api.mysite.local

@rimelek already pointed this out in this post.

Thank you for adding more details!

Not really, but I didn’t expect it to be anything else than 127.0.0.1 either so I remembered completely wrong. I started my Windows today because on my macOS the host.docker.internal domain is missing and have only kubernetes.docker.internal even though Kubernetes is not enabled.

On Windows the host.docker.internaldomain points to my WIFI IP address.
Your WSL distribution is not the same WSL distribution in which Docker is running. The “WSL integration” feature allows you to access the Docker API from a custom distrbution but that’s all. When you are on Windows, the IP address can be an IP of the Windows host the same way as you can access a forwarded port from the Windows host and not from a WSL distribution. Private IP addresses are not available from the host or from a custom WSL distribution. If it were, you could easily have a WSL IP address in the same subnet as one of your Docker networks since they use the same IP ranges.

I don’t think it would be really useful to let Docker add other hosts to the hosts file, since would still need to set them manually which you can do in the text file as well, but I understand that you prefer using the GUI instead of editing a file as administrator, so if you still want it as a feature, you can ask for it in the roadmap:

This forum is mainly for discussions among community members before the Docker staff can be involved.

On the other hand I can recommend you another solution which I use when I need to work with hostnames: https://nip.io/

nip is a public DNS service that you can use locally since the domains contain the IP address. You can for example use this hostname

mysite.local.192.168.50.12.nip.io

The above example uses your Wifi IP which could be changed, but it doesn’t have to be that IP. I found another interface on my Windows host created by the free VMWare Workstation Player and I used that IP address for testing.

docker run --rm -it nicolaka/netshoot ping mysite.local.192.168.32.1.nip.io

That way your containers and you on Windows host would use the same hostname pointing to the same IP address. Otherwise if you just set a hostname in the hosts file on Windows, that doesn’t affect the containers so you would need to use extra hosts as I explained it before.

I know, this way the hostname is pretty long, but works. You just need to make sure the services you want to acces are listening on that IP address as well or in case of containers, you forwarded ports from that IP address to the containers like the reverse proxy that handles multiple hosts if you have that too.

Thank you, that worked! I’m a bit embarrassed I didn’t think of this before asking; I actually have been trying to look for a solution to this for several weeks…
I also didn’t understand that from the post you mentioned. But thank you again!

We are glad it is sorted out now :slight_smile:

I got it to work with 127.0.0.1 mysite.local as @meyay pointed out, so hopefully I don’t need to worry about those IPs changing anymore.

When I suggested having Docker add this mapping for me, my idea was that I wouldn’t provide a specific IP address, but tell Docker this name maps (mysite.local) to whatever the IP for host.docker.internal is (which is the value I’d use when manually changing the hosts file).

Anyway, thank you for the nip.io suggestion! I think I saw that a long time ago but completely forgot about it. I’m sure it’ll come in handy in the future :smiley:

Caveat: I know zip about Docker Desktop…

But it sounds like you really want a way to have dynamic DNS to your containers. I use hardillb/traefik-avahi-helper which sets up Avahi/Bonjour/Zeroconf names allowing completely dynamic routing. Technically, it’s intended to work with Traefik, but I think if you provide the correct container labels (as if you were routing to an HTTP container with Traefik) it would still work.