Skip to content
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

[RFD] add configuration option to add host.docker.internal by default #2290

Open
thaJeztah opened this issue Jan 27, 2020 · 12 comments
Open

Comments

@thaJeztah
Copy link
Member

Pull request moby/moby#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
Copy link
Member Author

/cc @djs55 @nebuk89

@rfay
Copy link

rfay commented Jan 27, 2020

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

@thaJeztah
Copy link
Member Author

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
Copy link
Contributor

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
Copy link

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
Copy link

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
Copy link

zwass commented Jan 29, 2020

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
Copy link

HeroCC commented May 8, 2020

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.

@zapho
Copy link

zapho commented Feb 8, 2022

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.

@gaby
Copy link

gaby commented Apr 4, 2022

@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!

@gaby
Copy link

gaby commented Apr 4, 2022

The proposed option could also be added in dockerd daemon.json file.

@aradalvand
Copy link

Any updates on this one?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

10 participants