Communication between docker containers - localhost

Rancher 1.x
1

  1. How does networking work on rancher? i.e Where would localhost resolve to from one host to the next host?

  2. If you made a web service request using the following endpoints
    "ProductUrl": “http://localhost:5101” - running on host2
    "OrderingUrl": “http://localhost:5102” - running on host3
    "InvoicingUrl": “http://localhost:5103” - running on host4
    "IdentityUrl": “http://localhost:5105” - running on host1

What would happen when Identity service is on HOST1 and Product service is on HOST2 and product service made a web service call to the identity service (localhost:5105)? is localhost specific to the HOST so its not going to find it?

2

Hi Rob,

Answering your first question. If you log on to the container (either docker exec or ssh console from the rancher server/cattle ) and display /etc/hosts then you will see where “localhost” will call :slight_smile:
Usually it’s the loopback or ip on the internal network interface.

If containers are on the same network (e.g. bridge) then you can communicate with other containers by their service names or network alias which were added in the docker-compose.yml file.

If you need more sophisticated solution then you might implement internal DNS solution.

Answering you r second question.

I’m missing few details in your second question so it’s a little bit unclear.

First thing is where do you invoking URL, at your machine or at rancher server or maybe at node where the docker is running ?

If you are trying to reach your “apps”? via localhost you could get a tunnel via ssh to remote node. In such case you have to explicitly specify ports and destination containers IP. In such situation if URLs and ports changed then you will not find your service.

If you’re trying to access services at host where the docker engine is running and ports are exposed, then localhost: will always refer to container which exposed particular port.

Hope I partially answered your questions.

3

Thanks for your useful response :slight_smile:

2nd question - localhost url invokes the url via local docker container.

I’m trying to understand how two docker containers are able to communicate with each other when they are on two different host, within the same network. what is localhost on host1 vs localhost on host2?

Example 2
host1 has running serviceA1, serviceB1, serviceC1
host2 has running serviceA2, serviceB2, serviceD1

What endpoint do you use for serviceA1 on host1 to call serviceD1 on host2?

4

Hi Rob,

In my case when I create stack with use of docker-compose each service is named.
In the same network each container is having its network alias.
If you would invoke docker network insepct then you would see all containers.

For example :

[user@host]# docker network inspect bridge
[
{
“Name”: “bridge”,
“Id”: “c84060e75b4469605c261f0d3dd46da3f3de14260e690dc5139d23f7f0320de9”,
“Created”: “2017-04-05T13:03:53.104783046-05:00”,
“Scope”: “local”,
“Driver”: “bridge”,
“EnableIPv6”: false,
“IPAM”: {
“Driver”: “default”,
“Options”: null,
“Config”: [
{
“Subnet”: “172.17.0.0/16”,
“Gateway”: “172.17.0.1”
}
]
},
“Internal”: false,
“Attachable”: false,
“Containers”: {
“09ecc824a1250807ce03e5bd1109c50c289f37bc3cf9ed0f4b9db195556a714a”: {
“Name”: “r-network-services-metadata-1-99db119e”,
“EndpointID”: “9d9c5ff69b7a613aea2050f6a98f9ba258cddade9bbc1f4067a92761b5be671c”,
“MacAddress”: “02:48:e6:a2:b9:ff”,
“IPv4Address”: “172.17.0.9/16”,
“IPv6Address”: “”
},
“f1ec4f75e141a065584ba1fdceb475272177f8b5c486d50f58ad90c33bef9263”: {
“Name”: “proxy-test”,
“EndpointID”: “e11cefce46d6c238cf701188e4c635d1f9bd09af90e601bd4655932acc5a49cf”,
“MacAddress”: “02:42:ac:11:00:08”,
“IPv4Address”: “172.17.0.8/16”,
“IPv6Address”: “”
},
“fa2a22b4c12d834240039b3dcb6668424a27a95e6441383e92169bb2535f9270”: {
“Name”: “storage”,
“EndpointID”: “a25e6badacbd26682ec0cd60bf8835d5c5f18199f94d7e357572381339ab46ba”,
“MacAddress”: “02:42:ac:11:00:03”,
“IPv4Address”: “172.17.0.3/16”,
“IPv6Address”: “”
}
},
“Options”: {
“com.docker.network.bridge.default_bridge”: “true”,
“com.docker.network.bridge.enable_icc”: “true”,
“com.docker.network.bridge.enable_ip_masquerade”: “true”,
“com.docker.network.bridge.host_binding_ipv4”: “0.0.0.0”,
“com.docker.network.bridge.name”: “docker0”,
“com.docker.network.driver.mtu”: “1500”
},
“Labels”: {}
}
]

So in this example if you would log on via ssh to container “storage”, and you tried to “ping” container “proxy-test”, it would be resolved to “172.17.0.8” . This is basic docker networking which is used by Rancher.

Unfortunately if you would like to create stack with custom bridge network (custom name of the network which is bridge type), then I guess Rancher doesn’t supports it. This is actually my case.

EDIT: I just noticed that you’re asking for connectivity between 2 separate hosts (like vm’s or bare metal). Honestly I don’t know how it’s handled by docker/rancher. Maybe specific IP Table is created. Don’t know but it might be done this way. Maybe tunnel between 2 separate hosts is also solution.

5

Just to let you know, I cant communicate with localhost via the docker service! My host machine can access localhost, but my docker service can not! I’m trying to figure out how to have two or more docker services talk to eachother - At this moment, I only know one way to do this and its via public ip! (I tried the docker private ip and that doesnt work)

6

There seems to be a fundamental misunderstanding here. localhost is always the current namespace, I.e. the current container if in a container or the current host if on the host itself. Regular vanilla docker has no mechanism to communicate between hosts.

Rancher deploys containers which create an IPSec overlay network between all the hosts. Each container (set to managed networking) gets assigned a 10.42.x.y up address and can use those to talk to any other container in the environment (unless restricted by network policy management).

Using random IP addresses is not terribly convenient, so we also provide a DNS server which will resolve any service or container name. So if your want to talk to the product service in the same stack you open a connection to product.

1 Like