1

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

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?

1 Answer 1

1

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?
3
  • 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
    Jan 10, 2021 at 14:22
  • 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
    Jan 11, 2021 at 13:07
  • I see, thanks for all your help.
    – progress
    Jan 17, 2021 at 12:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.