Libnetwork: Proposal: enable exposure of different ports to different overlay networks

[oiavorskyi]

Pardon me if this feature has been already requested/discussed. I wasn't able to find the respective issue.

The -p <ip>:<port>:<port> passed to the docker run allows to expose particular port to particular network interface of the host. However, I wasn't able to find similar option to expose a port into specific overlay network.

Let's consider a container that exposes 2 ports - 80 to serve the traffic and 9000 to provide the control/configuration functionality. The port 80 should be exposed to the network "service" while the port 9000 should be only exposed to the network "management". Currently when the container is added to both networks both ports are exposed. In some cases this would raise security concerns.

It would be nice to have ability to expose ports to the specific network (both in docker engine and in docker compose).

[mavenugo]

@oiavorskyi exposing a port is a container property and hence regardless of the network it is connected to, it must behave the same way. Infact a container can be disconnected from a network and attach to another network and the container must continue to provide the service.

Let's consider a container that exposes 2 ports - 80 to serve the traffic and 9000 to provide the control/configuration functionality.
Typically this is considered as 2 different services and 2 different containers provides these services and exposes ports appropriately to each network. Let the container communicate among them in a private network if required (or share volumes, etc..)

[oiavorskyi]

@mavenugo I see your point. The disconnect/reconnect scenario makes sense. But if we look into analogy with the bare metal we could have two NICs on the server with each of the NICs could be attached to different networks. However, if I run service there which exposes multiple ports I am able to select the NIC to which each of the ports is bound.

I disagree about the 2 different services being the common case. Very common example is a Spring Boot micro service which exposes REST endpoints and also management endpoints. It is still one process. Another example is a messaging broker. You might want to have management functionality exposed into another network for ops. Or let's take Consul. The serf protocol could be exposed only in internal Consul network while service 8500 port would be available for outside communication over other network.

[mavenugo]

@oiavorskyi if you are suggesting port-exposing within the network, then the container can listen to a port only on a specific interface (and not on 0.0.0.0) and that will take care of your scenario.

we do port-mapping (mapping host-port for a container-port) is done at a container level and not per-network.

Hope it is clear.

[oiavorskyi]

@mavenugo yes, I think I've got it. Essentially I should treat the attachment to the network as another resources (NIC) on the container machine and make sure that on the application level I bind the specific ports to the specific interface. With this approach even if container exposes port to all of the networks there will be no bindings to those ports on the wrong interfaces.

Thank you, I think I will close this issue then.

[mavenugo]

@oiavorskyi :+1: thanks.

[mikeklim]

I would agree with @mavenugo if we consider a container as a separate entity. But the feature would be extremely useful in the context of docker-compose or swarm.

I went through the same logical steps as @oiavorskyi and that's how I stumbled on this proposal. :)