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!
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}
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.
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
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.