It would be really helpful for some to have the mechanism for connecting containers to additional networks after they are created.

for example an NGINX container could potentially be connected to other docker bridges and macvlan subinterfaces to reverse proxy them without ever needing to expose the container to the LAN or doing portforwarding - take the case of an app where you want to use TLS, but there is no built in support for that and you only want the app to be accessible from a specific network or IPs

 

This is could be a check list where you can pick all the valid docker networks the container can be attached to (optionally specifying the IP for the container as well).

Some early development and work in progress.

 

The docker container overview allows each container to connect and disconnect to the available networks on the fly.

 

 

In the picture above the container "Heimdall" participates in multiple networks.

 

Clicking on the network name shows a dropdown menu with the available networks. In the example above the 'host' network is unavailable because it is incompatible with the originally assigned  'bridge' network, it is allowed to mix bridge and macvlan (custom) networks.

# docker exec -it Heimdall bash

root@0a4759289e39:/$ ifconfig
eth0      Link encap:Ethernet  HWaddr 02:42:AC:11:00:02
          inet addr:172.17.0.2  Bcast:0.0.0.0  Mask:255.255.0.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:126 errors:0 dropped:0 overruns:0 frame:0
          TX packets:66 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:11508 (11.2 KiB)  TX bytes:16594 (16.2 KiB)

eth3      Link encap:Ethernet  HWaddr 02:42:AC:12:00:02
          inet addr:172.18.0.2  Bcast:0.0.0.0  Mask:255.255.0.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:17 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:1326 (1.2 KiB)  TX bytes:0 (0.0 B)

eth4      Link encap:Ethernet  HWaddr 02:42:0A:00:69:84
          inet addr:10.0.105.132  Bcast:0.0.0.0  Mask:255.255.255.0
          inet6 addr: fe80::42:aff:fe00:6984/64 Scope:Link
          inet6 addr: 2a02:a448:32d5:105:42:aff:fe00:6984/64 Scope:Global
          inet6 addr: 2a02:a448:32d5:105::6/64 Scope:Global
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:195 errors:0 dropped:0 overruns:0 frame:0
          TX packets:9 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:28096 (27.4 KiB)  TX bytes:766 (766.0 B)

eth5      Link encap:Ethernet  HWaddr 02:42:0A:00:65:81
          inet addr:10.0.101.129  Bcast:0.0.0.0  Mask:255.255.255.0
          inet6 addr: fe80::42:aff:fe00:6581/64 Scope:Link
          inet6 addr: 2a02:a448:32d5:101::8/64 Scope:Global
          inet6 addr: 2a02:a448:32d5:101:42:aff:fe00:6581/64 Scope:Global
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:130 errors:0 dropped:0 overruns:0 frame:0
          TX packets:180 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:10206 (9.9 KiB)  TX bytes:795206 (776.5 KiB)

root@0a4759289e39:/$ route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.0.105.1      0.0.0.0         UG    0      0        0 eth4
10.0.101.0      0.0.0.0         255.255.255.0   U     0      0        0 eth5
10.0.105.0      0.0.0.0         255.255.255.0   U     0      0        0 eth4
172.17.0.0      0.0.0.0         255.255.0.0     U     0      0        0 eth0
172.18.0.0      0.0.0.0         255.255.0.0     U     0      0        0 eth3

The IP address and TCP port of the container GUI are automatically adjusted when networks are added or removed, clicking on the context menu and selecting webUI gives access to the container even if it is moved to a completely different network.

 

Some caveats:

- The on-the-fly changes do not stick permanently, so a container update will revert to original network assignment

- Containers can not have statically assigned addresses, each time a container is connected to a network it receives a dynamic IP address by Docker

 

Cool, but having the network connections specified in the template allows "persistent" settings that last beyond container updates.

and could allow static IP settings too.

 

So maybe a two part UI

* one in the template level to do stuff like setup a multiple NIC container with static ips.

* another like what you showed us.

 

+1 to this.

I have the same use case of wanting to expose many different containers to nginx but not to each other or the rest of the network.

Note that the docker developers have voiced intentions not to add the ability to specify multiple networks on the run command.

 

A quick solution to this would be a field in the template for commands to run after the container is (re)started. e.g.:

docker network connect bridge2 container && docker network connect bridge3 container

 

Prioritizing creating a good UI for this function might be harder than the size of its audience justifies; but adding that run-after field is much simpler and likely covers other use cases.

@bonienl Did any of these features ever come to fruition? In 6.7 perhaps?

+1 for persistent network connections. 

Using --link currently but came here to request this after a scary not from docs.docker.com:

 

Warning: The --link flag is a legacy feature of Docker. It may eventually be removed. Unless you absolutely need to continue using it, we recommend that you use user-defined networks to facilitate communication between two containers instead of using --link. One feature that user-defined networks do not support that you can do with --link is sharing environment variables between containers. However, you can use other mechanisms such as volumes to share environment variables between containers in a more controlled way.

 

Probably will be a while before it goes away.