RFE: Support network aliases

[larsks]

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

/kind feature

Description

In addition to DNS-based container discovery using the container name, Docker permits an operator to assign aliases to the container. This can be tremendously useful if you've got a container name that looks something like "postgres-12-postgis", and you would like to be able to simply refer to it as "database":

docker run --network=mynetwork --network-alias=database ...

The podman-run man page currently documents the --network-alias option, but lists it as "Not implemented".

Additional environment details (AWS, VirtualBox, physical, etc.):

Implementing this would permit podman-compose to support docker-compose.yml files that include aliases.

[mheon]

I imagine the code for dnsname to support this won't be particularly bad, but it could be a real pain to plumb it through to CNI

…

On Mon, Nov 18, 2019, 15:33 Lars Kellogg-Stedman ***@***.***> wrote: *Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)* /kind feature *Description* In addition to DNS-based container discovery using the container name, Docker permits an operator to assign aliases to the container. This can be tremendously useful if you've got a container name that looks something like "postgres-12-postgis", and you would like to be able to simply refer to it as "database": docker run --network=mynetwork --network-alias=database ... The podman-run man page currently documents the --network-alias option, but lists it as "Not implemented". *Additional environment details (AWS, VirtualBox, physical, etc.):* Implementing this would permit podman-compose to support docker-compose.yml files that include aliases <https://docs.docker.com/compose/compose-file/#aliases>. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#4530>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB3AOCCU2QALX4UGH6AAIILQUL3YTANCNFSM4JOZXOIQ> .

[baude]

I like the idea as well; it would break current dnsname api (i imagine passing a []string of names instead of a string). i double checked the behavior with docker and like us, they require a new network to be made so that name resolution works. I guess --network-alias becomes a throw-away otherwise?

[larsks]

and like us, they require a new network to be made so that name resolution works.

Well, sort of. They don't support name resolution on the default bridge network because they are preserving legacy behavior (such as the support for --link, which is otherwise much less useful than DNS).

I don't see any reason to follow that model. I would say that --network-alias should work for any network on which the dnsname plugin is enabled, which may include the default network on cni-podman0 if someone has made the appropriate change to the configuration.

[github-actions]

This issue had no activity for 30 days. In the absence of activity or the "do-not-close" label, the issue will be automatically closed within 7 days.

[rhatdan]

Any movement on this?

[baude]

We discussed this today and how to apply it to Podman. We believe that while this RFE has merit, any implemented would undercut that same merit with performance hits. Using Docker as an example of implementing this shines light on at least one (maybe more) use issues:

In Docker, suppose you add a container named foo. You now have a container named foo and a dns entry for foo. If you add another container named foo-db with --network-alias foo, dns will not point at the new foo-db container. We think that should never happen. The reverse is also true I believe.

Preventing the first case is reasonable easy but is a perf hit to Podman. If a new container with a network-alias of foo is created, we could check for any containers named foo and and network aliases called foo. The perf hit is fenced off and only impacts those using network-aliases. However, it is the reverse case that is troublesome. In the event that a container exists with an alias of foo but the user creates a new container named foo, there would not be a perf hit to container creation to hit that.

In our discussion, that is where the benefit/cost begins to erode. We will keep this issue open however.

[rhatdan]

@baude Still want this issue opened?

[disaster123]

I would like to run jitsi through podman but i'm unable todo so because the docker-compose heavily uses network aliases:
https://github.com/jitsi/docker-jitsi-meet/blob/master/docker-compose.yml

currently i've no idea on how to run this with podman.

[baude]

@disaster123 I've outlined how we could do it and the up/downsides of it. Do you have a better way to implement this or better yet, care to contribute?

[rj-gp]

I also make use of network aliases when creating containers with a network. And I also have no idea how to workaround this with podman. I thought I could do the following:

1. create containers (podman create)
2. podman cp containers:/etc/hosts to someplace
3. edit these container /etc/hosts files with appropriate aliases, then copy them back into the containers, and then start the containers

However this leads to another issue. The (not running) container:/etc/hosts files do NOT contain a line for the container host name.

For (not running) containers, created with docker create, the container:/etc/hosts contains this line. In order to properly edit the /etc/hosts files we need the actual ip addresses that podman has assigned them.

For podman containers the container:/etc/hosts file only contains the hostname when actually running. eg
podman exec container cat /etc/hosts

The missing --network-aliases is a currently a showstopper for me.

[mheon]

The copy workflow isn't really supported with Podman (it looks like Docker does not handle that file as a bind mount, while we do - so the file in the container when it's not running will be mounted over even if changed). I think that launching the container once and editing /etc/hosts within the container would work, though - would that be sufficient?

[mheon]

Ahhh, nevermind - it looks like we recreate /etc/hosts for each run of the container, to account for changing internal IPs. Hmm.

[rj-gp]

Being a podman newby I thought I was most likely missing out on something obvious on a better way to handle a network alias. But then I discovered this RFE and after reading the comments I am apparently not missing out.

[mheon]

We could potentially do this as part of the more-general aliases code I want to add, but that could be a way off, given our current focus on the new HTTP API

[niklas88]

Just wanted to add my two cents in saying that I too think this feature is really important and worthwhile. For me it is the one major podman difference that drives me to use docker instead, even though I really prefer podmans simplicity and daemon less design. Over at my friends gantry project this is also the one thing stopping podman support
ad-freiburg/gantry#46

As for @baude 's concerns, while I do get the naming clashing problem I'm really not convinced this is anything but theoretical and/or user error. If the user configures name clashes that's really their own fault and resolving clashing names to either entity in whatever preference sounds like perfectly okay behavior in that situation and nothing podman should spent CPU time on preventing. Especially since it will not be that hard to debug and even on manual setups shouldn't easily happen by accident.

This is especially true since I feel like in 99% of cases the aliases and container names will be created by a tool like podman-compose or gantry that creates them from a configuration that it can easily check for such name clashes without any noticeable performance overhead. To me podman really focuses on local/small setup use and that benefits so immensely from compose style tools that making them possible should IMHO be a priority.

[disaster123]

+1

[rj-gp]

I agree with @niklas88 in that any name clash issues are the users issue/fault.
This shouldn't be podman's job to "coddle" us users.

[rhatdan]

I think PRs would help to move this along. Hint, Hint.

[rhatdan]

@baude @niklas88 Where are we on this one?

[rj-gp]

I don't know about @baude and @niklas88 but I am still needing this before I can actually use podman.

[rhatdan]

@baude @mheon I think we should bring this one back to the foreground.

[mheon]

@rhatdan Only so much time in the day 😄

[rhatdan]

Understood.

[rj-gp]

@baude @mheon I think we should bring this one back to the foreground.

Yes, Yes, Yes!!...

[mhmr]

I understand this might still open issue, but is there anyway to go around this, any currently existing feature that we can use to go around it?

[trusch]

@mhmr I think the only (really hacky) way of doing this right now is to exec into the rootless-cni-infa container and update the /run/containers/cni/dnsname/default/addnhosts file after you started (not only created) all of your containers. You can then look in that file for your container name and just append all the aliases that you want (like sed -i 's/alpine1/alpine1 alpine_one/' /run/containers/cni/dnsname/default/addnhosts)

edit: you also need to force the dnsmasq daemon to restart by quickly starting another container after updating the addnhosts file. Its really hacky, but it works.

[mheon]

This is actively being worked on and will probably make it into Podman 2.2

[rj-gp]

This is actively being worked on and will probably make it into Podman 2.2

Fantastic!

[baude]

merged today upstream.