dockerswarm container linking : "tasks.service1" vs directly "service1"

Question

When using a docker swarm, what is the difference between using "tasks.service1" or directly "service1" when curling/pinging ?

Practical exemple : i start a docker swarm with a service on the same overlay network as follow :

$> docker network create --driver=overlay public
$> docker service create --name service1 --replicas=2 --network public ubuntu sleep 10000

now i list containers :

$> docker ps -a
bd645378cb2d   ubuntu:latest   "sleep 10000"   43 seconds ago   Up 41 seconds             service1.1.rjy91s66col81libdilrd698j
686c0ab006fc   ubuntu:latest   "sleep 10000"   43 seconds ago   Up 41 seconds             service1.2.wjrwsj6h6rcadsknzxym4h9w0

if i attach to the first container i can ping the others :

$> docker exec -ti bd645378cb2d bash
$> apt update
$> apt install iputils-ping dnsutils
$> ping service1 # returns ok 10.0.1.65

when i dig the special hostname tasks.service1 i get all replicas ips. but theses do not match with the one i get with ping.

$> dig tasks.service1 # returns 10.0.1.66 & 10.0.1.67

Why do ips doesn't match ? if i need to connect to service 2 from service 1, should i use tasks.service2 or service2 ?

Answer 1

This is a load-balancer IP. Docker service has it if created with default vip (Virtual IP) --endpoint-mode. You can see it with docker inspect <service_name>:

"Endpoint": {
    "Spec": {
        "Mode": "vip"
    },
    "VirtualIPs": [
        {
            "NetworkID": "i7k7pv9s4v7dgvc57zjmh6pk6",
            "Addr": "10.0.1.2/24"
        }
    ]
}

This is mentioned in the documentation, although it is easy to miss the point:

To use an external load balancer without the routing mesh, set --endpoint-mode to dnsrr instead of the default value of vip. In this case, there is not a single virtual IP.