Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

#

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Jump to bottom

Network priority not implemented in docker-compose version 3.0 #1372

Closed
ComBin opened this issue Sep 14, 2018 · 19 comments
Closed

Network priority not implemented in docker-compose version 3.0 #1372

ComBin opened this issue Sep 14, 2018 · 19 comments

Comments

@ComBin
Copy link

ComBin commented Sep 14, 2018

I have docker-compose.yml v3.0 and i have issue from docker/compose#4645. Acording by documentations it is not implemented in 3.0. Is it planned to implement it? Or is there any reason why this feature was removed?

# docker-compose --version
docker-compose version 1.22.0, build f46880f

# docker --version
Docker version 18.06.1-ce, build e68fc7a
@kddubb
Copy link

kddubb commented Oct 1, 2018

+1 Interested in a response to this and when this will make it into v3?

@Daniel-Valentine
Copy link

+1 as well.

@fago
Copy link

fago commented May 21, 2019

Running into this as well.
That and having it to automatically add a network alias with the service name is problematic when using traefik. See https://forums.docker.com/t/multiple-networks-in-a-docker-compose-file-precedence/39071

@unglaublicherdude
Copy link

+1 from me as well. We have a Swarm with thousands of containers running and some networks are basically used in every deployed stack for most services.

We have sometimes the case, that the network where all the traffic is in (because of the problem mentioned here), just doesn't respond anymore when at the same time, the communication via the stacks default networks works just fine. This is a real issue for us. As Workaround we now prefix the default-networks of all stack with aaaa manually now.

@dpiquet
Copy link

dpiquet commented Jul 31, 2019

+1 ! This is also an issue for us. Also using traefik.

@flikkes
Copy link

flikkes commented Jul 31, 2019

+1 ! as this is also an issue for us. We'd like to be able to rely on the order the networks IP addresses are added to /etc/hosts so we can use the first address as a default for certain configuration parameters. So being able to rely on the first network in the list being actually treated as the first one would be great!

@frgomes
Copy link

frgomes commented Jan 30, 2020

+1

2 similar comments
@epica-shai
Copy link

+1

@OhMyVolk
Copy link

+1

@willopez
Copy link

willopez commented Apr 6, 2020 •
edited
Loading

Not having this is causing problems with my deployment of Reaction Commerce.

@thelittlefireman
Copy link

+1

1 similar comment
@fhaferkorn
Copy link

+1

@jfellus
Copy link

jfellus commented Sep 30, 2020

I may be wrong but it seems to me that docker-compose's implementation doesn't make a difference between v2 and v3. Connections are indeed created from an OrderDict sorted by priority, no matter v2 or v3 is used (see https://github.com/docker/compose/blob/master/compose/network.py#L325, and PR docker/compose#5566 clearly show that v3 is ok since at least jan 2018)

Could anyone who know what happens next on the docker side explain why this priority isn't taken into account (BTW v2 and v3 priorities are equally ignored) ?
A rapid test https://gist.github.com/jfellus/cfee9efc1e8e1baf9d15314f16a46eca shows that network interfaces are allocated following lexical order of network names, despite any priority settings.

  1. If I'm wrong, it would be great to make clear in the docs why v3 isn't displaying this cool feature, while v2 docs are still showing it albeit it doesn't really work... https://docs.docker.com/compose/compose-file/compose-file-v2/

  2. If I'm right, could someone propose an addition to v3 docs to close misleading issues such as this one ? And eventually explain why it may have worked in the past (is it really the case ?)

thanks !

@jfellus jfellus mentioned this issue Sep 30, 2020
Closed
@pwatk
Copy link

pwatk commented Feb 15, 2021

+1 This is real pain. Please fix this.

@mendorf
Copy link

mendorf commented Mar 21, 2021

+1, besides respecting the compose spec for docker stack deploy which is still not allowing to mix v2 and v3... :(

@tacodra
Copy link

tacodra commented Jun 2, 2021

+1 Network priority not being available is really annoying. Prefixing network names works for now, but thats not a solution.

@nospam2000
Copy link

nospam2000 commented Jun 2, 2021 •
edited
Loading

We use a macvlan network as secondary network for non ip based protocols (PROFINET IO or DCP, based directly on layer 2 ethernet). In the container we need to know the network interface name which is bound to the macvlan ("eth1"). When the order of the network interfaces changes two things happen:

  1. the default gateway gets no longer set to the network interface used for normal ip based communication, because only the first interface gets a default gw setting. The macvlan doesn't have a default gateway and cannot talk to the host ip stack at all.
  2. the network interface names get swapped that means the app will use the wrong network interface for layer 2 based communication over the macvlan interface

Our macvlan network is an external network defined by the company which delivers the OS running on the device.
The additional networks are defined by the developers of the apps which run on that device.
It is really annoying that we have to call the macvlan network "zzz_layer2_net1" to be halfway safe that it always comes last, because we don't know the name of the other networks which are defined by the app developer and use automatic naming prefixes the developer is not even aware of.

When a user names the directory which contains his docker-compose.yaml "zzzz_1234" we will get a problem, because docker compose uses this as a project name which will be used as the prefix of the default network name and causes the network interfaces to be swapped. The name of that directory might not even be under the control of the developer.

This is really annoying, please fix it.

@ndeloof
Copy link
Contributor

ndeloof commented Jun 13, 2021 •
edited
Loading

Network priority is included in the Compose Specification (compose-spec.io) and is supported both by docker-compose 1.28+ and new docker compose command in the Docker CLI.

Based on this, IMHO this issue could be closed (cc @thaJeztah)

@ndeloof ndeloof closed this as completed Jun 14, 2021
@ndeloof
Copy link
Contributor

ndeloof commented Jun 14, 2021

Created https://github.com/docker/compose-cli/issues/1785 as a follow-up issue to investigate correct implementation in Compose v2

@ndeloof ndeloof mentioned this issue Sep 2, 2021
Closed
DennisGaida added a commit to DennisGaida/docker-traefik that referenced this issue Jan 27, 2022
@DennisGaida
Rename socket_proxy to zsocket_proxy
74deba0 
docker-compose v2 had network priority, unfortunately docker-compose v3 does not have this functionality (yet?). See docker/cli#1372

Networks are assigned to containers using alphabetical order, in this case it means that "socket_proxy" is always ordered before "t2_proxy", this in turn means that the default gateway in containers is always the "socket_proxy" gateway and therefore the outgoing IP address to other containers. I believe this is wrong and the outgoing containers' IPs should always be the default networks gateway and respective IP as well as the traefik containers' IP - never the socket-proxy IP.

I recently ran into this problem due to Authelia refusing oauth requests from container-to-container since I didn't allow the socket-proxy network to communicate via Authelia (because why should it, it should always just be container <-> docker sock).

Taking the traefik container as an example:

### Before the change

```shell
$  docker exec traefik route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         192.168.91.1    0.0.0.0         UG    0      0        0 eth0
192.168.90.0   *               255.255.255.0   U     0      0        0 eth1
192.168.91.0   *               255.255.255.0   U     0      0        0 eth0
```

### After the change
(note the assignment of eth0/eth1)

```shell
$  docker exec traefik route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         192.168.90.1    0.0.0.0         UG    0      0        0 eth0
192.168.90.0   *               255.255.255.0   U     0      0        0 eth0
192.168.91.0   *               255.255.255.0   U     0      0        0 eth1
```

This could have been changed in docker-compose v2 with the `priority` attribute (assigning e.g. `priority: 10` to traefik), but this just doesn't work with docker-compose v3. 😐
@DennisGaida DennisGaida mentioned this issue Jan 27, 2022
Open
# for free to join this conversation on GitHub. Already have an account? # to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests