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

Docker compose service with "network_mode: service: [...]" does not inherit parent's service networks #7458

Closed
saponace opened this issue May 15, 2020 · 2 comments

Comments

@saponace
Copy link

Description of the issue

Hi,

Let say I have two services: A and B.
If A has

networks:
  - some_network

and B as network_mode: service:A, then B does not appear to be in the network some_network: docker instpect B does not show some_network in the NetworkSettings.Networks field.

Context information (for bug reports)

Output of docker-compose version

docker-compose version 1.25.5, build unknown
docker-py version: 4.2.0
CPython version: 3.8.2
OpenSSL version: OpenSSL 1.1.1g  21 Apr 2020

Output of docker version

Client:
 Version:           19.03.8-ce
 API version:       1.40
 Go version:        go1.14.1
 Git commit:        afacb8b7f0
 Built:             Thu Apr  2 00:04:36 2020
 OS/Arch:           linux/amd64
 Experimental:      false

Server:
 Engine:
  Version:          19.03.8-ce
  API version:      1.40 (minimum version 1.12)
  Go version:       go1.14.1
  Git commit:       afacb8b7f0
  Built:            Thu Apr  2 00:04:16 2020
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          v1.3.4.m
  GitCommit:        d76c121f76a5fc8a462dc64594aea72fe18e1178.m
 runc:
  Version:          1.0.0-rc10
  GitCommit:        dc9208a3303feef5b3839f4323d9beb36df0a9dd
 docker-init:
  Version:          0.18.0
  GitCommit:        fec3683

Output of docker-compose config

networks:
  web:
    name: web
services:
  net_holder:
    command:
    - --port=9999
    container_name: net_holder
    image: containous/whoami:v1.5.0
    networks:
      web: null
  whoami:
    container_name: whoami
    image: containous/whoami:v1.5.0
    network_mode: service:net_holder
  whoami2:
    container_name: whoami2
    image: containous/whoami:v1.5.0
    networks:
      web: null
version: '3.8'

Steps to reproduce the issue

  1. docker-compose up the stack
  2. docker inspect whoami2
  3. The attribute NetworkSettings.Networks of whoami2 contains the "web" network
  4. docker inspect whoami
  5. The attribute NetworkSettings.Networks of whoami DOES NOT contains the "web" network. I believe it should.

I believe this issue is a direct consequence of this and this.

Some backstory

I use network_mode: service[net_holder] on service whoami because I need it to have its network traffic routed through the container of service net_holder.
I need whomai to be in the network web because I use traefik with the traefik.docker.network=web label. Since docker (and hence traefik too) does not see whoami is in the network web, traeffik emits an error:

"Could not find network named 'web' for container '/whoami'! Maybe you're missing the project's prefix in the label? Defaulting to first available network." container=whoami-stackname-xxxxxxxxxx serviceName=whoami providerName=docker

It works when net_holder is in only one network. But if net_holder is in X networks, B will have a probability of 1/X to be exposed to traefik according to the traefik documentation.

If you want to reproduce this bug behavior with traefik, please see this gist. It has two compose files: the one presented in this issue, and another one with traefik.

Anyway, thank you for your amazing work !

Let me know if you have any question.

@stale
Copy link

stale bot commented Nov 11, 2020

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the stale label Nov 11, 2020
@stale
Copy link

stale bot commented Nov 19, 2020

This issue has been automatically closed because it had not recent activity during the stale period.

@stale stale bot closed this as completed Nov 19, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant