Docker Community Forums

Share and learn in the Docker community.

Need help connecting containers in swarm mode

Hello,

Wondering if someone can help us connect containers in swarm mode. We have noticed that when containers are created in swarm mode, they cannot communicate with each other as they don’t know each others’ IP address. To fix this, we have to manually enter IP addresses in the /etc/hosts file. This is extremely burdensome. How can we avoid this? A detailed description of our issue is here: https://stackoverflow.com/questions/56998706/docker-swarm-unable-to-connect-to-other-containers-because-ip-lookup-fails. We haven’t gotten a satisfactory answer so checking if posting here helps. Thanks in advance!

forget my initial post - i should have read your complete SO post before I responded.

What you want is to add standalone containers to an overlay swarm network.

Strong advise: create your overlay network outside the swarm stack like this:

$ docker network create -d overlay --attachable my-attachable-overlay

Then use containername.networkname to adress other containers.

this solved it (at least it looks like it does). thanks. I am very surprised I couldn’t find this information in any docs. the command you mention is how we are creating the overlay network. but we were using {containername} to connect instead of {containername}.{networkname}

we see a DNS fwd/rev mismatch though. what does this mean?

nc -zv peer2-kp 7051

DNS fwd/rev mismatch: peer2-kp != peer2-kp.dscsa_net

peer2-kp [10.0.0.187] 7051 (?) open

root@b47231ed072d:/home# nc -zv peer2-kp.dscsa_net 7051

peer2-kp.dscsa_net [10.0.0.187] 7051 (?) open

making some notes for help in debugging later.

fwd lookup. this time it succeeds even though network has not been specified.

root@a4f1e73314ed:/home# host orderer1-ord

orderer1-ord has address 10.0.0.89

root@a4f1e73314ed:/home# host orderer1-ord.dscsa_net

orderer1-ord.dscsa_net has address 10.0.0.89

root@a4f1e73314ed:/home# host 10.0.0.89

rev lookup

89.0.0.10.in-addr.arpa domain name pointer orderer1-ord.dscsa_net.

no error this time (fwd/rev mismatch)

root@a4f1e73314ed:/home# nc -zv orderer1-ord.dscsa_net 7050

orderer1-ord.dscsa_net [10.0.0.89] 7050 (?) open

official link that says containername should be sufficient:

https://docs.docker.com/engine/reference/commandline/network_connect/

Once connected in network, containers can communicate using only another container’s IP address or
name. For overlay networks
or custom plugins that support multi-host connectivity, containers connected to the same multi-host network but launched from different Engines can also communicate in this way.

Metin,

Can you explain why we need to add the .{network} suffix to our {containername}?

The official documentation for docker does not say that. Note that we are not creating a service. We are creating standalone containers on an overlay network. This scenario is covered under https://docs.docker.com/network/network-tutorial-overlay/#use-an-overlay-network-for-standalone-containers .
And on Step #7 they don’t add the .{network} suffix to the {containername}. Then why do we need to do that?

Just trying to understand. The version of docker we are using is 18.06.1-ce for linux. fwiw we came across https://github.com/docker/for-win/issues/2301 which mentions a dns lookup issue for 18.06
but that is for windows.

Honestly, I don’t know why the network name its required - i just know that it works :slight_smile:

I just exerpienced when I moved from compose to swarm deployments on Docker EE 17.06 that suddenly the network name was required as well. So much for the promise that the concepts would apply regardless whether you are on cli, compose or swarm - there are plenty of details that differ.

Even though, later versions of Docker shouldn’t require a hostname or network alias for a service, I still declare them for my services to ensure that the network name is not required for container to container communication. I prefer this approach over the container name.network name approach, as it breaks the portability of the stack.