Support network_mode in docker stack deploy

[D3nn]

I'd like to request that the "network_mode" from the docker-compose file be supported. I know that there's already been some discussion around this from those who'd like to use it for network_mode:host capabilities, but personally I'm more interested in the network_mode:"service:<svc name>".

I'd also like to see this supported in the docker service create command or at least have the --network option be able to include the same semantics as the network_mode does in the compose file.

The use cases I see for this are:

• launching containers that share the same network stack so that applications can communicate with each other over a loopback interface. This would allow lower-latency communications between the containers and also obviate service discovery requirements for such containers.
• launching a container which contains a network toolset so that I can do some network diagnostics on processes that run in containers derived from "scratch" (such as containers running go programs).

The first use case would definitely benefit from reviving container affinity constraints from the old swarm, but that could be worked around for now using the supported placement constraints from v3 compose format (or by making the network_mode:service itself be a deployment constraint).

[cirocosta]

As @thaJeztah points out in #25873 (comment) maybe this can be closed ? 🤔

With

version: '3.3'
services:
  nginx:
    image: 'nginx:alpine'
    networks:
      - 'outside'

networks:
  outside:
    external:
      name: 'host'

you can get "NetworkMode": "host", 👍

---

Client:
 Version:      17.07.0-ce-rc2
 API version:  1.31
 Go version:   go1.8.3
 Git commit:   36ce605
 Built:        Mon Aug  7 23:42:06 2017
 OS/Arch:      linux/amd64

Server:
 Version:      17.07.0-ce-rc2
 API version:  1.31 (minimum version 1.12)
 Go version:   go1.8.3
 Git commit:   36ce605
 Built:        Mon Aug  7 23:48:34 2017
 OS/Arch:      linux/amd64
 Experimental: true

[D3nn]

I don't think so for this issue. I was looking more for the equivalent of "network_mode:service <service id/name>". Unless it would be possible to have the following network config:

networks:
  outside:
    external:
      name: 'service: <svc name/id>'

Specifically, I'd like to have the ability to have one service use the network stack of another's so that it could communicate over a localhost interface rather than over a bridged/vxlan interface.

[cirocosta]

Oh, sorry, I misunderstood. That makes sense 👍

[djmaze]

I'd like to add the network_mode: none is also missing (and there is no equivalent in swarm mode afaik). This is e.g. useful for services which operate on volumes only.

[wlan0]

+1

ping - I hope this issue sees some more momentum! Is there anyone working on this issue?

I also have a request - In addition to support for

networks:
  outside:
    external:
      name: 'service: <svc name/id>'

I'd also like to request support for

networks:
  outside:
    external:
      name: 'container: <name>'

so that multiple containers can share the same net namespace. Similar to network_mode: container:name

[xmoki9]

+1

[jarlave]

Is here anything new? Looking for this too.

[dstapp]

Is there any progress? Or any workaround to make network_mode service:abc working?

[19wolf]

Is there any news on this?

[DoctorBryson]

Any news anybody?

[thaJeztah]

@DoctorBryson what option are you looking for specifically? host networking should be possible (see above), as well as other networks, but using service: / container: or none is not supported by Swarm, so can't be supported in stack files.

[fsgreco]

@thaJeztah is there any alternative solution when using Swarm? I have this exact problem and it's driving me mad.
Basically I need to tell swarm that container A needs to pass its traffic to container B (that happens to be a vpn).

[thaJeztah]

Swarm services do not currently provide options to co-schedule containers / "pod" / "sidecar"-like constructs. For a "task of service a" to be using the network stack of "task of service b", those tasks must be scheduled on the same node, in addition to their lifecycle be coupled (e.g. if the "vpn" task would exit, all tasks using its network stack must also be recreated). Perhaps there's some creative ways to achieve this, but it's not currently supported out of the box (/cc @dperny)

[fsgreco]

Thanks for the response, I maybe find a creative way to achieve this result, will try this: qdm12/gluetun#40 (comment)

I think this is iterating over this idea: https://serverfault.com/questions/1012325/hiding-a-docker-container-behind-openvpn-in-docker-swarm-with-an-overlay-netwo

[fsgreco]

Another solution could be this one: https://superuser.com/questions/1217990/connect-to-a-vpn-openvpn-from-a-docker-service-on-swarm

But this means you need to configure NAT on every node of the swarm (?) it seems not ideal to me.