Answers: <p>I don't experience same issue with similar setup to what you describe. 'A' &amp; 'B' can ping &amp; access services on 'C' just fine. Few things to look at:</p>
  <ul>
  <li>Port aside, can you ping 'C' from either of the other containers?</li>
  <li>You probably shouldn't (can't?) name containers capital 'A', 'B', 'C' if you're going to build them in docker-compose. If that's what's actually used, try more meaningful names.</li>
  <li>Does name resolution work if you do <code>nslookup c</code> from either a &amp; b? It should resolve via <code>nameserver 127.0.0.11</code></li>
  <li>firewall on 'C' or service not up on <code>c:8080</code>?</li>
  </ul>
  
Answers: CC BY-SA 4.0
Answers: 2021-01-10T14:22:12.470Z
Answers: Thanks napovi. The real hostnames and container names have just been replaced for convenience. I could ping C from either of the containers and `nslookup c` was resolved via `nameserver 127.0.0.11` as you said. The actual issue was that the service on C was listening on `localhost:8080`. Binding the service to `C:8080` worked. I'm a bit confused as the services on A and B are bound to `localhost:8080` but docker seems to automatically map them to `A:8080` and `B:8080` but does not do the same for the service on C. Do you know why this could be the case?
Answers: progress
Answers: CC BY-SA 4.0
Answers: 2021-01-11T13:07:42.330Z
Answers: This is likely more down to how service listening on `:8080` is configured than Docker. Possibly it's expecting to be in default Docker subnet which is usually `172.17.0.0/16` but with two 'internal' NICs on `C`, subnets may be `172.18.0.0/16` and `172.19. 0.0/16` (or some other values). Usually services in containers would listen an all IPv4 & IPv6 NICs: take default NGINX config for example `listen 80;` and `listen [::]:80` which may not be the case in service on C.
Answers: apo
Answers: CC BY-SA 4.0
Answers: 2021-01-17T12:25:12.157Z
Answers: I see, thanks for all your help.
Answers: progress
Answers: CC BY-SA 4.0
Answers: 2021-01-07T20:10:07.353Z
Answers: 2021-01-07T20:10:07.353Z
Answers: apo
Body: <p>I have two containerised services, A and B, with which I wish to isolate network communications with docker compose. There is also a shared service C which is not isolated from A or B and is free to communicate with either.</p>
  <p><a href="https://i.sstatic.net/td5Jp.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/td5Jp.png" alt="enter image description here" /></a></p>
  <p>I have tried to achieve this with the following docker-compose.yaml:</p>
  <pre><code>version: &quot;3.3&quot;
  services:
    C:
      build: C
      depends_on:
        - A
        - B
      expose:
        - 8080
      networks:
        - A
        - B
    A:
      build: A
      expose:
        - 8080
      networks:
        - A
    B:
      build: B
      expose:
        - 8080
      networks:
        - B
  
  networks:
    A:
      internal: true
    B:
      internal: true
  </code></pre>
  <p>With this, C is able to connect to both A and B on the hosts A:8080 and B:8080 respectively and  A and B are isolated as required. However, neither A nor B is able to connect to C on C:8080. Removing the network options from the compose file, all services are able to talk to each other. What am I doing wrong?</p>
  
Tags: <docker><docker-compose><networking>
Title: Isolate service networks with Docker Compose
UserDisplayName: progress
ThreadText: # Isolate service networks with Docker Compose
  
  (Asked by: username_0 on 2021-01-04)
  
  I have two containerised services, A and B, with which I wish to isolate network communications with docker compose. There is also a shared service C which is not isolated from A or B and is free to communicate with either.
  
  [![enter image description here](https://i.sstatic.net/td5Jp.png)](https://i.sstatic.net/td5Jp.png)
  
  I have tried to achieve this with the following docker-compose.yaml:
  
  ```
  version: "3.3"
  services:
    C:
      build: C
      depends_on:
        - A
        - B
      expose:
        - 8080
      networks:
        - A
        - B
    A:
      build: A
      expose:
        - 8080
      networks:
        - A
    B:
      build: B
      expose:
        - 8080
      networks:
        - B
  
  networks:
    A:
      internal: true
    B:
      internal: true
  
  ```
  
  With this, C is able to connect to both A and B on the hosts A:8080 and B:8080 respectively and A and B are isolated as required. However, neither A nor B is able to connect to C on C:8080. Removing the network options from the compose file, all services are able to talk to each other. What am I doing wrong?
  
  **Tags:** docker, docker-compose, networking
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2021-01-07. Score: 1 | Accepted answer
  
  I don't experience same issue with similar setup to what you describe. 'A' & 'B' can ping & access services on 'C' just fine. Few things to look at:
  
  * Port aside, can you ping 'C' from either of the other containers?
  * You probably shouldn't (can't?) name containers capital 'A', 'B', 'C' if you're going to build them in docker-compose. If that's what's actually used, try more meaningful names.
  * Does name resolution work if you do `nslookup c` from either a & b? It should resolve via `nameserver 127.0.0.11`
  * firewall on 'C' or service not up on `c:8080`?
  
  > **Comments:**
  > **username_0**: Thanks napovi. The real hostnames and container names have just been replaced for convenience. I could ping C from either of the containers and `nslookup c` was resolved via `nameserver 127.0.0.11` as you said. The actual issue was that the service on C was listening on `localhost:8080`. Binding the service to `C:8080` worked. I'm a bit confused as the services on A and B are bound to `localhost:8080` but docker seems to automatically map them to `A:8080` and `B:8080` but does not do the same for the service on C. Do you know why this could be the case?  
  > **username_1**: This is likely more down to how service listening on `:8080` is configured than Docker. Possibly it's expecting to be in default Docker subnet which is usually `172.17.0.0/16` but with two 'internal' NICs on `C`, subnets may be `172.18.0.0/16` and `172.19. 0.0/16` (or some other values). Usually services in containers would listen an all IPv4 & IPv6 NICs: take default NGINX config for example `listen 80;` and `listen [::]:80` which may not be the case in service on C.  
  > **username_0**: I see, thanks for all your help.  
  
  ---
  
  