Support special IP designator host-gateway in --add-host.

[willmtemple]

Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)

/kind feature

Description

Related: #8466

Podman doesn't support host-gateway as a special IP designator when creating a container. Instead it creates an automatic mapping from host.containers.internal to the host NIC's IP address, but unfortunately that doesn't really help in situations involving scripts that call docker, where the host has the podman docker CLI shim installed.

This is one of those argument configurations (--add-host host.docker.internal:host-gateway) that floats around on the web as a solution for the problem of "talking to the host" when using docker, so it ends up integrated into a fair amount of tools that call the docker CLI. It'd be nice if podman could support this argument well for compatibility.

Steps to reproduce the issue:

1. Try to launch a container with a host-gateway mapping: podman run --rm --add-host foobar:host-gateway fedora

Describe the results you received:

$ podman run --rm --add-host foobar:host-gateway fedora
Error: invalid IP address in add-host: "host-gateway"

Describe the results you expected:

As with moby-engine:

$ docker run --add-host foobar:host-gateway -it fedora
[root@87ec49b55693 /]# cat /etc/hosts
127.0.0.1       localhost
::1     localhost ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
172.17.0.1      foobar
172.17.0.2      87ec49b55693

I'll spare you all the additional info in the issue template, since this is just a feature request.

Notes:

Unless ContainerConfig.HostAdd is used in other places, I think this can be implemented by special-casing host-gateway as an IP string in ValidateExtraHost and then in libpod/container_internal_linux Container#createHosts by simply mapping over the extra hosts and replacing any that have host-gateway as their IP string with the selected host IP from libnetwork.

[willmtemple]

I wrote a quick baseline implementation that has the behavior I am hoping for with respect to this command line option, but I don't have enough knowledge of how the libpod systems work to know if having this host-gateway string hanging out in ContainerConfig.HostAdd might break anything else.

PR: #14392

[rhatdan]

Hey William, long time.

Another option would be to just add this by default to all containers, and then allow it to be turned on and off via containers.conf.

@Luap99 @mheon WDYT?

[willmtemple]

long time

@rhatdan You can take the man out of the pod, but not the pod out of the man.

[willmtemple]

add this by default to all containers

The issue is really about compatibility with the docker CLI for the purposes of using podman with scripts that call docker. I know 1:1 compatibility with docker CLI is not really a goal for podman given the architectural differences, but some CLI options worm their way into 3rd party scripts that call the docker CLI more than others. This is one of those options. As evidence of that: if you google "docker talk to host" the first several StackOverflow results and docker forum results all suggest using host-gateway.

It's also a container instance setting, not a global engine setting. The CLI option in moby-engine allows mapping any arbitrary hostname to host-gateway in each container instance. Basically, it just understands the string "host-gateway" to be a special sentinel meaning "the IP of the container host." So the following should be allowed:

$ podman run -it --rm --add-host foo:host-gateway --add-host bar:host-gateway fedora bash

Let's say my local IP is 192.168.1.10; both foo and bar should map to that IP in the container's hosts file. The resulting hosts entries should be:

192.168.1.10    foo
192.168.1.10    bar

[github-actions]

A friendly reminder that this issue had no activity for 30 days.

[Luap99]

@willmtemple Do you still work on this?

[github-actions]

A friendly reminder that this issue had no activity for 30 days.

[rhatdan]

@Luap99 can you take it over?

[dkliban]

@rhatdan I talked to @Luap99 on IRC and it sounds like he doesn't have the bandwidth to work on this issue. Please assign it to me and I'll work on this issue.

[rhatdan]

@dkliban you got it.

[dkliban]

After upgrading to podman 4.1 I realized that host.containers.internal now routes correctly to the host. I no longer need this feature.

[dtmdl]

I've just hit this. My slightly crazy use case is to 'override' a particular hostname to resolve to the host's IP in the container. Unfortunately that hostname is not 'host.containers.internal', so the existing automatic entry doesn't quite cut it.

(But perhaps my use case is too weird to be a justification for this feature...)

[rhatdan]

@dkliban Any movement on this

[github-actions]

A friendly reminder that this issue had no activity for 30 days.

[rhatdan]

@Luap99 Any chance you can work on this?

[niklasfi]

Hey I've run into this as well. My use case is, that I am running podman-compose and sharing a compose-file with co-workers who are using docker-compose. podman-compose just forwards the extra_hosts configured in the compose-file to podman which unfortunately leads to the problem, that podman does not understand host-gateway. I have tried to override the behavior by using a podman-compose.yaml that then automatically gets merged with docker-compose.yaml, but it is not possible to clear the extra_hosts array, just append to it that way. All in all this means we have to maintain two separate compose files with just a two line delta between them and call podman-compose explicitly with -f podman-compose.yaml.

Soo given all of this. Any chance to get the PR merged? Is the missing documentation string really all that is holding us back here? I would gladly add that if that is all it takes.

[rhatdan]

Just need to get someone to work on it.

[Nauscar]

#14392 appears to have been abandoned. Does that PR require any additional efforts beyond updating the comment function and a rebase?

[Luap99]

@Nauscar This #14392 (review) is still valid, the change must be made in containers/common to support both podman and buildah.

[rhatdan]

@Nauscar if you want to take if over, that would be great.

[Luap99]

This was fixed in containers/common#1549 and #19152 and will be included in podman v4.7