network_mode: "service:[service name]" not adequately documented.

[vinilneves]

@ the docs it reads

Network mode. Use the same values as the docker client --network parameter, plus the special form service:[service name].

But I can't find anything that clearly states what it's supposed to do, just guesses and vague answers.

Same as https://github.com/docker/docker.github.io/issues/5325 But someone closed it and said "feel free to reopen it" but ignored when people asked to reopen.

[beaufrusetta]

I'm currently using network_mode: service: <service_name> in a demo project I'm working on, and from what I can gather, it allows you to define a host container (that connects to a typical docker network), and then you can have 1 or more containers attach to the network stack of the host container.

Useful for service mesh proxy handing with apps running in containers.

Outside of that, I haven't used it otherwise.

[cecilphillip]

I'm also looking for some documentation on the details of how this feature works. I'm seeing it used in other placements, but I really don't understand the implications of this setting 🤷🏾‍♂️

[wutr]

It's pretty vague, but I believe (by reading both the Docker CLI and COMPOSE specification documentation) it is down to docker-compose implementing services which it can reference by name.

Docker CLI references containers directly (by name or id), whereas docker-compose uses services (which as far as I know, under the hood will be translated into containers).

Docker CLI states:

Network: container

With the network set to container a container will share the network stack of another container. The other container’s name must be provided in the format of --network container:<name|id>.

And the COMPOSE specification states:

network_mode

network_mode set service containers network mode. Available values are platform specific, but Compose specification define specific values which MUST be implemented as described if supported:

none which disable all container networking host which gives the container raw access to host's network interface service:{name} which gives the containers access to the specified service only

    network_mode: "host"
    network_mode: "none"
    network_mode: "service:[service name]"

I read this as if it implements this on top of the Docker CLI --network options. The service:[name] option is additional and seems to have the same effect as --network container:[name], except that you can refer to a service as defined in a docker-compose file, rather than having to explicitly state the container name.

[frankyw]

Referencing a service by name does not appear to work, and seems to actually be a one-time translation to container ID.

Truncated compose file, starts up no problem.

wireguard:
    container_name: wireguard
flexget:
    container_name: flexget
    depends_on:
      - wireguard
    network_mode: service:wireguard 

However, should the wireguard container be recreated, the reference no longer functions, apparently because docker uses an ID, rather than a name, under the hood.

ERROR: for flexget  Cannot start service flexget: No such container: f142b40b79b562b4e712de9a6315e661238960310d0003b1993305477c3b75d4

Anyone else having this same issue?

[docker-robott]

There hasn't been any activity on this issue for a long time. If the problem is still relevant, mark the issue as fresh with a /remove-lifecycle stale comment. If not, this issue will be closed in 14 days. This helps our maintainers focus on the active issues.

Prevent issues from auto-closing with a /lifecycle frozen comment.

/lifecycle stale

[ElianaTroper]

/remove-lifecycle stale

[docker-robott]

There hasn't been any activity on this issue for a long time. If the problem is still relevant, mark the issue as fresh with a /remove-lifecycle stale comment. If not, this issue will be closed in 14 days. This helps our maintainers focus on the active issues.

Prevent issues from auto-closing with a /lifecycle frozen comment.

/lifecycle stale

[GeorgeHahn]

/lifecycle frozen

[GeorgeHahn]

/remove-lifecycle stale

[yelodevopsi]

This definitely needs more documentation!

I've been testing and implementing connection between two containers which use VPN-services, and I'm trying to find any equivalent configuration with either "networks" that can resemble the :service[name] parameter.

From what I can do in docker container inspect <id> from networks:

..using network_mode: service:vpnclient where vpnclient is my service:

"NetworkSettings": {
        ...
        "Ports": {
            "3389/tcp": [
                {
                    "HostIp": "0.0.0.0",
                    "HostPort": "3389"
                }
            ]
        },
        "Networks": {
            "<name>_default": {
                "IPAMConfig": null,
                "Links": null,
                "Aliases": [
                    "vpnclient",
                    "vpnclient",
                    "0a0c636d808a"
                ],
                "NetworkID": "2fcc7c74f9a419ad9843289bd40d432086e38f6e97b250c3820b370d6fda20e9",
                "EndpointID": "60f8a387fe3999abb1a2199b1c5ff88e6dfd78f65738eca9c37edea31c391887",
                "Gateway": "172.19.0.1",
                "IPAddress": "172.19.0.2",
            }
        }
    }

I'm using - ports: "3389:3389" on the vpnclient service.

The inspect on the container using the network_mode: service:vpnclient is basically "blank".

       "NetworkSettings": {
            "Bridge": "",
            "SandboxID": "",
            "HairpinMode": false,
            "LinkLocalIPv6Address": "",
            "LinkLocalIPv6PrefixLen": 0,
            "Ports": {},
            "SandboxKey": "",
            "SecondaryIPAddresses": null,
            "SecondaryIPv6Addresses": null,
            "EndpointID": "",
            "Gateway": "",
            "GlobalIPv6Address": "",
            "GlobalIPv6PrefixLen": 0,
            "IPAddress": "",
            "IPPrefixLen": 0,
            "IPv6Gateway": "",
            "MacAddress": "",
            "Networks": {}
        }

however under HostConfig => NetworkMode"NetworkMode" we find: "container:0a0c636d808a3ad91177e1b6c7336d3bea75c30aa41a82367c7914ee2ffc9d86",

[balki]

This forum post provides more details. Link

[Troughy]

Referencing a service by name does not appear to work, and seems to actually be a one-time translation to container ID.

Truncated compose file, starts up no problem.

wireguard:
    container_name: wireguard
flexget:
    container_name: flexget
    depends_on:
      - wireguard
    network_mode: service:wireguard 

However, should the wireguard container be recreated, the reference no longer functions, apparently because docker uses an ID, rather than a name, under the hood.

ERROR: for flexget  Cannot start service flexget: No such container: f142b40b79b562b4e712de9a6315e661238960310d0003b1993305477c3b75d4

Anyone else having this same issue?

have you ever found a solution?

[erik434]

@Troughy just stumbled across this thread and another: https://github.com/docker/compose/issues/6626#issuecomment-2532919682

Does removing the depends_on block fix this for you? It seems that using network_mode adds an implicit depends_on, and adding an explicit depends_on yourself may actually cause problems (or at least that's been my experience).

[Troughy]

@erik434 hey, it's been almost a year but I do currently have some containers where network_mode: service:... is working properly. I do still have depends_on there. I have no idea how I managed to get it to work, if anyone's still having this issue, try using docker rm to remove everything and recreate it.

[FlorianHeigl]

I had it half-working but the lack of documentation is extremely frustrating nonetheless. it feels like it needs 3-4 examples, plus maybe some data flow diagram?