Cli: [RFD] add configuration option to add `host.docker.internal` by default

[thaJeztah]

Pull request https://github.com/moby/moby/pull/40007 implemented a "magic" host-gateway value to allow users to add host.docker.internal to /etc/hosts in containers, mapping it to the gateway IP address (the IP address itself can be configured in the daemon configuration).

With this feature, users running dockerd on Linux can get parity with Docker for Mac / Docker for Windows to have host.docker.internal resolve inside containers.

Currently, this option is "opt-in" on Linux; containers will not be able to resolve host.docker.internal unless they are created with --add-host host.docker.internal:host-gateway

Proposal

Users may want to have the host.docker.internal host added _automatically_ for every container created (similar to how it's currently added automatically on Docker Desktop (Docker for Mac / Docker for Windows).

I suggest to:

• add an option to the CLI configuration file (~/.docker/config.json) that allows configuring a default (set of) custom hosts for new containers
• possibly (t.b.d.) an environment variable to configure this

The configuration option could potentially be used by the Docker Desktop team, as a replacement for the current (proprietary) implementation; doing so would make the implementation on Linux and Docker Desktop identical (which would make it less confusing).

[thaJeztah]

/cc @djs55 @nebuk89

[rfay]

Please don't forget docker-compose as well. Thanks!

[thaJeztah]

Good point, yes: I'm not sure to what extend docker-compose currently reads/uses the CLI configuration file, so that's something to be looked at. @ndeloof @ulyssessouza

[silvin-lubecki]

I think this feature makes more sense per context basis. One global configuration won't allow fine grain control, as I guess that if you target different environments, you don't want this feature enabled everywhere (ex maybe on prod environment?).

[ibaldonl]

The host is always accessible by default, this only adds a well known DNS reference to it, so it should be always there by default too I think, and all the configuration complexity is not warranted for this case.
Extreme configuration and flexibility is the enemy of simplicity so it should be a balance; in this case, I think that it shouldn't be configurable at all, it just should always exist and doing the right thing in all platforms without users worrying about it.
Just wanted to express this personal opinion for your consideration guys, thanks a lot for reading and for your time.

[ibaldonl]

Sorry, let me elaborate with an example: you do a Docker Compose environment and hope it works mostly without too many tweaks and assumptions about the users environments.

Docker Compose definitions are terse and to the point, they are simple and straightforward.

If host.docker.internal is by default absent, you as the author of the Docker Compose environment can't rely that users have it enabled, so if you need to use it, then in the services that you need to use it you must add a line in the YAML specifying it, making things more verbose, less straightforward and too the point, less concise.

Whats the danger of just having this option enabled by default?

Does it make something slower, something more bloated, something less secure?

[zwass]

Is there a way as this is implemented currently to explicitly add the host.docker.internal in the docker-compose file? This change is going to break a compose file that I provide my users for testing.

[HeroCC]

I'm curious why the proposed functionality is different than the Docker Desktop default of always exposing it. Wouldn't it make more sense to always expose the host by default, and allow users to disable it if they like? That's what the behavior of the Desktop apps are AFAIK, and personally I like that method better. Plus, if you eventually want to reach parity with the desktop apps, swapping from opt-out to opt-in would be a breaking change.