Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Control interface name in docker multiple networking #25181
With the workaround suggested in #17796 for multiple network mode for docker containers, it is not possible to control the interface name with the
My post boot script relies on the name of the interfaces and won't work if the order is changed and I require the interfaces to be up on boot. So, I can't use
Additional environment details: Running on a centos 7.1 bare metal.
Steps to reproduce the issue:
Results received: eth2 was assigned 10.100.4.3 and eth3 was assigned 10.100.3.3
Results expected: eth2 must be assigned 10.100.3.3 and eth3 must be assigned 10.100.4.3 or there needs to be a way to specify the interface name in
The issue happens occasionally and the probability of it occurring increases with the increase in the number of networks the container is connected to.
So, essentially, in your case you can work around it through subnet filtering, right? e.g., you know that a given subnet has been assigned to a given network, thus you can filter your iface list and find the one which is the one assigned to your desired network. Did you go through this path? Or did something different?
referenced this issue
Jun 19, 2017
With the "csv" style syntax for networks being worked on (see #31964, and PR's docker/cli#62 (for services), and docker/cli#156 for
ping @abhinandanpb @fcrisciani WDYT?
@abhinandanpb would it be different for services and "regular" containers? i.e.;
@thaJeztah I'm interested in being able to specify an explicit interface, so:
would be great...or something similar in
I also use docker-compose, so would also need to be able to specify the interface in the services block of a container.
Is there any likelihood that this will be implemented soon?
This is pretty serious, meaning that if you have more networks, the interfaces will get mixed up.
Almost all network applications base themselves on the fact that the interface names are the same.
Why would they be randomly assigned it is beyond my understanding, when it would have been much easier to assigned them in order at least based on the network name or the order the networks were connected to the container.
This was referenced
Oct 31, 2017
I am interested in this as well. As a use case...
Have a service that is in two networks... one for reverse proxying (frontend) and one for its own backend (backend). In order to receive traffic, the app (a Java app) needs to listen to the interface for the frontend. Since we aren't using static subnets, it's difficult to discover/know which interface we should use.
The proposed solution above would work for us.