Start container with multiple network interfaces

Question

With 1.9, is there a way to start a container directly with two or more network interfaces?

You can do it after the container is started with "docker network connect", but it means the process is already running and might miss the creation of the new one.

Answer 1

This question is top doing a search regarding docker and multiple network interfaces. Although is not the required version in the question I leave here some info:

With Docker 1.12+ it's possible to add more than one network interface to a docker container, but it is needed to create the container first and then attach the second (and subsequence) network NICs prior to start the container:

$ docker create --network=network1 --name container_name containerimage:latest
$ docker network connect network2 container_name
$ docker start container_name

It is needed to create the networks first:

$ docker network create --driver=bridge network1 --subnet=172.19.0.0/24
$ docker network create --driver=bridge network2 --subnet=172.19.1.0/24

Also, you can start the container attaching the dockerhost network interfaces by using the --network=host argument in docker run:

$ docker run --net=host containerimage:latest

Answer 2

As @gesellix answered, currently its not possible.

You can find this issue under https://github.com/docker/docker/issues/17750

There are some pending improvements in this area. As I see from discussions - current idea is to create container (with docker create), attach networks (docker network connect) and then start (docker start).

You can check reasoning in comments of https://github.com/docker/docker/pull/17796

UPD: #17750 is closed and will be available in 1.10

Answer 3

No, this isn't possible. The docs also show that the necessary command line option --net only accepts a single network name: http://docs.docker.com/engine/reference/run/#network-settings

Please also keep in mind that Docker 1.9 constantly updates the /etc/hosts file inside your containers, so that a running process cannot rely on the initial state of that file. The best way would be to make your process aware of updates, either through manually reading the /etc/hosts file or by querying a dns server. That way you wouldn't have issues when the second network will be connected.

Answer 4

Does someone still look for the answer of this issue? There are 2 solutions to do this: First is the one almost detailed completely here, but it do works with current docker releases - complete tutorial can be found here docker hub forum

Solution 2 is to do everything in the rock-bottom layer. I have included the details comment section of the link above, which I also copy here: Since docker is also using linux’s networking namespaces you can do this in the rock-bottom layer as well. Unfortunately, Docker tries to hide this from the user, but the namespaces are still existing under the hood. In order to get them to be managed by ip netns tool, do the following:

1. get the process id (pid) of your running container:

$ sudo docker inspect -f '{{.State.Pid}}' <container name>

<container name> is not your label:tag name, it is the name that docker automatically assign to it once a container is fired up - get yours via docker ps command and look for the last column (NAME).

2. create a symlink from the /proc/ filesystem to /var/run/ 2.1. First, create a netns directory in /var/run/ $ sudo mkdir -p /var/run/netns

2.2. Using the PID you have just obtained, create the symlink $ sudo ln -sf /proc/<PID>/ns/net /var/run/netns/<YOUR DESIRED NETNS NAME FOR YOU CONTAINER>

Now, if you execute ip netns list, you will see the networking namespace of your container.

From now on, there is no docker specific stuffs, just create a veth pair, bring them up, and attach one end of it to the container and you are fine: $ sudo ip link add veth1_container type veth peer name veth1_root

$ sudo ifconfig veth1_container up

$ sudo ifconfig veth1_root up

$ sudo ip link set veth1_container netns <YOUR NETNS NAME>

$ sudo ip netns exec <YOUR NETNS NAME> ifconfig veth1_container up

The last command might be a bit overcomplicated, but it seemed that bringing up this interface natively in the container is not possible due to missing permissions :)

Note that the MAC address could also be changed in the same way I have shown in solution 1, before attaching it to the container, or after - does not really matter, just different commands need to be used (recall the permission issue just mentioned above).

I hope it helps.