Feature: alias policy for networks to prevent accidental cross talk.

[chrisbecke]

Description

I have a swarm that uses traefik for ingress routing. Dev teams deploy stacks to this swarm in the expectation that things just-work. They may choose to have multiple api services with similar names in different stacks, both linked together over networks in the stack, and to public networks such as traefik. Because of the way docker resolves dns, this means that services from one stack can accidentally become linked to services in some other stack.

Steps to Reproduce

These steps are somewhat theoretical but the idea is this:

1. Have some stack traefik that exposes a network traefik_public.
2. Have a second stack stack1 with two services: api and api2. Both services expose swagger endpoints, and so are attached to traefik_public. api2 calls api using http://api and so it attached to stack1_default.
3. Have a third stack stack2 with some services including a service api. This service is attached to traefik_public.

Now, when api2 resolves "api", because it is attached to traefik_public which vip does it get? In theory it should be communicating both with its own stack1_api and, unexpectedly, with stack2_api.

Suggestions

• I can't find an official document anywhere describing how networks and dns interplay in docker to even know theoretically what is expected in this situation. Improved documentation on dockers dns would be nice.
• An immediate fix is to go through and set an explicit alias on each instance of of the traefik network in all my stack files to something that is never used in a connection string. This is horrid as it means I need to reach out to dev teams and fix their stuff and audit stack files I normally don't need to see. But it does indicate a more general fix: simply being able to set an alias policy at the network level would help - If, when creating public networks like traefik we could exclude them from alias creation automatically that would, somewhat elegantly solve issues like this.

Discussion

This obviously applies to more than just traefik, and swarm. Similar situations can happen on compose, and anywhere public networks are used, to gather logging or metrics across multiple stacks / compose stacks, this kind of crosstalk has the potential to occur.

[chrisbecke]

As per #43052 another thing thing that needs to be per-network is endpoint-mode, dnsrr or vip.

When creating overlay networks to allow many services to connect to one controller, OR
when the service (such as traefik) implictly does its own loadbalancing, creating vips for all services on that network halves the number of ips available. As #30820 and docs imply we still cannot depend on cidr larger than /24.

Being able to set endpoint mode defaults, and override them at the network level, would double the the number of available ips, and possibly reduce wasted resources as vips are expensive.

[firecow]

docker stack deploy --no-auto-network-aliasing

or

---
version: "3.8"

networks:
  default:
    name: network-name
    external: true
    policy: no-auto-aliasing

Would be extremely useful for huge stacks that have intertwined network attachments....

We have a whole bunch of stacks attached to the same network.
When doing CURL requests to http://{$STACK_NAME}_{$SERVICE_NAME} everything is awesome, but sometimes a developer just calls http://{$SERVICE_NAME} and gets very confused, because his requests hits 1 out of 20 different API's 😆