Skip to content
New issue

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

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

Already on GitHub? Sign in to your account

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

Open
vinilneves opened this issue Oct 23, 2019 · 12 comments
Open

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

vinilneves opened this issue Oct 23, 2019 · 12 comments
Labels
area/cli Relates to the CLI client lifecycle/frozen

Comments

@vinilneves
Copy link

@ 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 #5325
But someone closed it and said "feel free to reopen it" but ignored when people asked to reopen.

@beaufrusetta
Copy link

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
Copy link

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
Copy link

wutr commented Jan 17, 2021

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
Copy link

frankyw commented Mar 9, 2022

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?

@craig-osterhout craig-osterhout added the area/cli Relates to the CLI client label Aug 3, 2022
@docker-robott
Copy link
Collaborator

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
Copy link

/remove-lifecycle stale

@docker-robott
Copy link
Collaborator

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

This comment was marked as off-topic.

@GeorgeHahn

This comment was marked as off-topic.

@yelodevopsi
Copy link

yelodevopsi commented May 31, 2023

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
Copy link

balki commented May 13, 2024

This forum post provides more details. Link

@Troughy
Copy link

Troughy commented Jul 19, 2024

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/cli Relates to the CLI client lifecycle/frozen
Projects
None yet
Development

No branches or pull requests