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

CC BY-SA 4.0
2021-01-10T14:22:12.470Z
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?
progress
CC BY-SA 4.0
2021-01-11T13:07:42.330Z
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.
apo
CC BY-SA 4.0
2021-01-17T12:25:12.157Z
I see, thanks for all your help.
progress
CC BY-SA 4.0
2021-01-07T20:10:07.353Z
2021-01-07T20:10:07.353Z
apo
<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>

<docker><docker-compose><networking>
Isolate service networks with Docker Compose
progress
# 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.

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 nusername_1vi. 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.  

---

