cli
cli copied to clipboard
[RFD] add configuration option to add `host.docker.internal` by default
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).
/cc @djs55 @nebuk89
Please don't forget docker-compose as well. Thanks!
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
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?).
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.
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?
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.
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.
Any news about this issue?
Being able to use --add-host host.docker.internal:host-gateway or extra_hosts: ... is nice but cumbersome and error prone for most users.
Having a way to add this configuration as a default for all containers would be really useful.
@zapho I'm on the same boat. We have hundreds of containers and it gets cumbersome.
I would be awesome if this option was added so any new deployments can have it enabled by default!
The proposed option could also be added in dockerd daemon.json file.
Any updates on this one?
Two more years passed and this is still a pain. Any update on this?