hi…
I’ve got an executable which listens to a TCP IP address specified on its command line. It runs in a docker service, sample_svc, which publishes a port. I would like to access the service from a separate service running on another node in the same swarm.
I suspect the Docker service implementation will, by default, direct ingress traffic to the eth0 device within the container. Is this is a safe assumption?
thanks!
Just to get it out of the way, the sample_svc does not allow a listen address of 0.0.0.0.
From the host:
docker network inspect ingress
… other services …
e526278vr097… a 32-byte UUID…:
{
“Name”: “sample_svc.1…”,
“EndpointID”: “… another 32-byte UUID …”,
“MacAddress”: “… a MAC …”,
“IPV4Address”: “10.255.0.12/16”,
“IPv6Address”: “”
}
within the container running sample_svc:
ifconfig
eth0 10.0.0.15
eth1 175.17.0.9
eth2 10.255.0.12
lo 127.0.0.1
So… it seems like the ingress network is connected to eth2. There is another overlay network in the swarm - an inspect shows it is connected to 10.0.0.15 in the sample_svc container. Likewise, docker_gwbridge seems to be connected to 175.17.0.9
cat /etc/hosts
… some ip6 addresses …
10.0.0.15 e526278vr097
This is run from the other container. I think this connects to eth2 in the sample_svc container.
getent hosts sample_svc
10.0.0.14 sample_svc
So I suspect that the ingress traffic is going to eth2 inside the sample_svc container. I’m not sure how i can test this, though.
I find that if i bind the sample_svc to eth0 and ensure that it is on the same overlay network as the other service then an “nslookup sample_svc” in the other service’s container retrieves an IP address which can be used to contact the sample_svc on the ingress port. I don’t know enough to say whether that’s consistent with the underlying design, but it seems to work for now.