Docker uses DNS for service discovery, so containers can find one another with standard networking. Applications use server names in their client connection configuration, and when the application makes a DNS query to find the target, Docker responds with the container's IP address. It's the same in Docker Swarm when your target server name could actually be the name of a Docker service running with dozens of replicas across the cluster.

There are two ways for Docker to respond to manage DNS for a service with multiple replicas. The default is to use VIP: a virtual IP address. Docker uses a single IP address for the service, and relies on the networking stack in the host operating system to route a request on the VIP to an actual container. VIP takes care of load-balancing and health. Requests are shared among all the healthy containers in the service. This feature has long been established in Linux, and is new to Windows with Server 2019.

The alternative to VIP is DNSRR: DNS round-robin, which you specify in the endpoint_mode setting in the service configuration. DNSRR returns a list of the IP addresses of all the healthy containers in the service, and the order of the list is rotated to provide load-balancing. DNSRR was the only option for Windows containers before Server 2019, and you will see it in lots of examples, but VIP is a better option. Clients have a tendency to cache DNS query responses. With DNSRR, you can update a service and find clients have cached the IP address of an old container that has been replaced, so their connection fails. That doesn't happen with VIP, where there's a single IP address in the DNS response, and clients can safely cache it because it will always route to a healthy container.

Docker Swarm takes care of load-balancing network traffic between service replicas, but it also load-balances external traffic coming into the swarm. In the new NerdDinner architecture, there is only one component that is publicly accessible—the Traefik reverse proxy. We know a port can only be used by a single process on a machine, so that should mean we can only scale the proxy service to a maximum of one container for each node in the cluster. But Docker Swarm lets us over provision or under provision the service, using the same port on the machine for zero or many replicas.

A swarm service attached to an overlay network behaves differently to standard containers when you publish ports. Every node in the swarm listens on the published port, and when traffic is received, it gets directed to a healthy container. That container could be running on the node that received the request, or on a different node.

In this example, the client makes an HTTP GET request on standard port 80 for a service running in Docker Swarm:

1. The client request reaches a node that is not running any of the service replicas. The node has no containers listening on port 80, so it cannot handle the request directly.
2. The receiving node forwards on the request to another node in the swarm that does have a container listening on port 80—this is all invisible to the original client.
3. The new node forwards the request on to the running container, which processes it and sends the response.

This is called ingress networking, and it's an extremely powerful feature. It means you can run a low-scale service on a large cluster, or a high-scale service on a small cluster, and they will work in the same way. If the service is running with fewer replicas than there are nodes in the cluster, that isn't an issue, because Docker will transparently send the request to another node. If the service is running with more replicas than there are nodes, that isn't an issue, because every node can handle the request and Docker load-balances traffic between containers on the nodes.

Load-balancing and service discovery is all based on healthy containers, and it's a Docker Swarm feature that doesn't need any special setup from my side. A service running on an overlay network in swarm mode defaults to VIP service discovery and ingress networking for published ports. When I run NerdDinner in Docker Swarm, I don't need any changes to my deployment to gain high availability and scale in a production environment, and I can focus on my own application's configuration.