Best Practice? Configuring docker service and containers with a custom Linux Bridge Device

Am trying to ferret out the required steps from numerous documents, looking for info relevant to current implementation of libcontainers (instead of LXC)… Hope someone can verify on the following and comment, Thx.

It looks like docker0 (which is created and configured automatically with all Docker installs) is commonly called a “Host Only” networking device by general virtual networking descriptions… ie containers and the Host can network with each other but without access to other networks and without special services like NAT.

I am looking at the procedure to create additional bridge devices with various network options, and then use them with containers.

Creating the bridge device and configuring on the Host

  • I assume a Linux Bridge Device can be created by any method, eg brctl addbr, virsh, etc.
  • My system (openSUSE) implements systemd, so the usual systemd method should be used to copy the existing Unit file to /etc/systemd/system and then customize the copy.
  • I assume that the customized Unit file should add the "-b " perhaps separated with a semi-colon to the ExecStart= command? Would need to experiment unless someone knows how to specify multiple bridge name or if a wildcard is supported. This also raises the question whether “docker0” needs to be specified since it isn’t by default. Maybe docker will use all Linux Bridge Devices on the Host by default?

Configuring on the Container
Assume this is something that is specified only when invoking the Container, ie.
docker run --net=br0
Then the question is whether the container can be modified later to point to another bridge device?
I assume that specifying the Linux Bridge Device can only be done with the “docker run” command and cannot be modified later with a “docker start” command?


I hope that covers most of your questions.

And yes, as far as I understand it, container settings like the --net=br0 are only set when you create a container, and not modifyable after the fact.