2

I have been looking everywhere for this answer. To me it seems like an obvious question, however, the answer has eluded me.

My current setup is, I have redis, mongodb and two api servers on the same bridge network. The first server serves as a gateway api that does all the auth, and exposes certain api calls. The backend api is the one that handles all the db interactions and data munging. If I hit the backend (inner) api alone, I am able to see the contents (this api would not be exposed in real production environment). However, if I make the same request from within the gateway api, I am not able to hit the backend (inner) api that is also part of the bridged network I created.

Below is a diagram of the container interactions.

Docker container interaction

ericg
  • 103
  • 8
  • What address is the Gateway API using to connect to the Inner API? And are you running this in plain Docker? Compose? Can you post the commands you run to bring this setup up? – johnharris85 Dec 13 '16 at 21:00
  • The way I have it right now is, plain docker, gateway API exposed at 0.0.0.0:8090 and the inner API is exposed as 0.0.0.0:8099. `docker run --net=isolated_network -itd -v /volume:/opt/volume --name busybox1 -p 8010:8090 busybox "some command" docker run --net=isolated_network -itd -v /volume2:/opt/volume2 --name busybox2 -p 8010:8090 busybox "some command 2"` – ericg Dec 13 '16 at 21:12

1 Answers1

0

I still use legacy linking, but I'm a little bit familiar with this. I think the problem is that you are trying to hit "localhost" from inside your gateway container. The inner API container cannot be resolved as "localhost" inside of the gateway API container. You are able to hit "localhost:8099" from the host machine or externally because of the port mapping, but none of your other containers will be able to resolve that address/port because they 'think' it's a remote machine.

Here's a way to test what I'm thinking. In your host's shell, run the bridge inspect command shown here. Copy the IP address from Containers.<inner-api-hash>.IPV4. Then open a shell in the gateway container with docker exec -it <gateway-id> /bin/bash and then use curl or wget to see if you can hit that IP address you copied.

If my thinking is correct, you will see that you must use your inner-API node's Docker assigned IP address from the other containers. Amongst other options, you can start containers with a static IP address as shown here.

This is starting to escape the scope of my knowledge, but you can also configure a container DNS. Configure container DNS.

Community
  • 1
  • 1
gregbert
  • 446
  • 2
  • 5
  • When calling the inner api from the gateway api, I am calling the inner gateway by the name given when the container was created: `curl -X GET http://busybox2/api/resource/one` – ericg Dec 13 '16 at 21:44
  • I tried what you suggested, however, I can ping both busybox2 and the ip assigned to the container. But the name+port combo is not working. I guess if I have a network bridge setup, do I have to expose a port on the busybox2 container? Or would the name suffice? – ericg Dec 13 '16 at 21:54
  • The docs say "Containers in this default network are able to communicate with each other using IP addresses. Docker does not support automatic service discovery on the default bridge network." So, just using the name will not work without further configuration. – gregbert Dec 13 '16 at 21:59
  • I'm not sure about if you still need the port mapping. I'll look into it. – gregbert Dec 13 '16 at 22:02
  • Inside of your Docker network, the containers will be able to communicate (via IP address) without manually exposing any ports. Just make sure there's not a port collision. If you want to expose a port, namely, your GatewayAPI, you can still expose that port outside of the network and map it to whatever you'd like. – gregbert Dec 13 '16 at 22:10
  • Thanks, I will try that. – ericg Dec 13 '16 at 22:12
  • I tried using the ip given to the container and with this, the container was available. The only thing I had to do is add the port to the ip. For `busybox2`, I did not have to expose the port, I just used the port that is used when the server is started. For the gateway server I did expose a port just to be able to hit it using localhost. – ericg Dec 13 '16 at 22:19
  • Great, so your gateway is accessible via the host and externally, and your internal api should be completely inaccessible to things outside your network. And yes, adding the port after the IP is essential. Apologies, I should have noted that before. – gregbert Dec 13 '16 at 22:24