Open Fantastitech opened 4 years ago
Try to ping the service name, i.e., dgraph_zero
, instead of the hostname. That should resolve to the stable virtual IP of the service (VIP).
I'm having the same issue when using multiple networks for a service. My stack file is as follows:
version: "3"
services:
nginx:
image: ${registry}/siteipc_nginx:develop-dev
volumes:
- nfs_codebase:/var/www/html/
- nginx_logs:/var/log/nginx/
- nginx_confs:/etc/nginx/conf.d/
networks:
- public
deploy:
placement:
constraints: [node.labels.mylabel == true]
solr:
image: ${registry}/siteipc_solr:develop-dev
environment:
SOLR_DEFAULT_CONFIG_SET: search_api_solr_4.1.6
SOLR_HEAP: 512m
networks:
- private
- public
volumes:
- solr_index:/opt/solr/server/solr
deploy:
placement:
constraints: [node.labels.otherlabel == true]
resources:
limits:
cpus: '1.0'
memory: 1400M
reservations:
cpus: '0.1'
memory: 700M
networks:
private:
public:
external:
name: "nginx_prod_public"
The solr
service cannot be resolved to the right IP address if it is in multiple networks, but if I remove one of them, then it starts to work properly.
I tryed to ping the service name as @neben suggested, but it did not help. The only work around was removing one the networks.
Any ideas?
Did this ever got resolved? Seeing the same behaviour..
Did anyone manage to figure it out? Cheers!
Expected behavior
When deploying containers via
docker swarm deploy
using a Docker Compose file with hostnames for the containers, each container should be able to resolve the other containers via hostname.Actual behavior
Containers are getting valid ipv4 addresses and can ping one another, but hostnames are resolving to different IP addresses on the same subnet.
Steps to reproduce the behavior
Create four LXD containers running the latest version of Docker from the official Docker repository for Ubuntu 18.04. Create a swarm.
Deploy containers to the swarm with the following docker-compose.yml file via
docker stack deploy -c docker-compose.yml dgraph
:On the master node holding the
zero
container, rundocker container inspect
on thezero
container and note the IP address. In the case:The IP address on the overlay network is
10.0.9.3
Now move to an LXD node running a worker container and run
docker exec -it dgraph_alpha1 /bin/ping zero
where dgraph_alpha1 is the name of your worker container and zero is the hostname of your manager container.You can see the hostname
zero
is resolving to10.0.9.2
instead of the correct10.0.9.3
address. In my tests the resolved IP address' last octet is always one lower than the actual IP. All DNS entries are consistently off by a seemingly reproducable number. When directly pinging another container's actual IP address the connection is successful.Same result using
dig
:Output of
docker version
:Output of
docker info
:Additional environment details (AWS, VirtualBox, physical, etc.)
Test environment topography is as follows:
UFW state is inactive. No iptables rules are present other than the defaults created by Docker. The only running firewall on the network is on the WAN and all containers are within the LAN. LXD containers can ping one another and they are all present as peers via
docker inspect
.