By default, requests to Services are load balanced based on the public port.

Task

The command below will create a new service called lbapp1 with two containers running. The service is exposed via port 81.

docker service create --name lbapp1 --replicas 2 -p 81:80 katacoda/docker-http-server

When requests are made to a node in our cluster on port 81, it will distribute the load across the two containers.

curl docker:81

The HTTP response indicates which container processed the request. Running the command on the second host has the same results, with it processing the request across both hosts.

curl docker:81

In the next step, we will explore how to use this to deploy a realistic application.

Docker Swarm Mode includes a Routing Mesh that enables multi-host networking. It allows containers on two different hosts to communicate as if they are on the same host. It does this by creating a Virtual Extensible LAN (VXLAN), designed for cloud-based networking.

The routing works in two different ways. Firstly, based on the public port exposed on the service. Any requests to the port will be distributed. Secondly, the service is given a Virtual IP address that is routable only inside the Docker Network. When requests are made to the IP address, they are distributed to the underlying containers. This Virtual IP is registered with the Embedded DNS server in Docker. When a DNS lookup is made based on the service name, the Virtual IP is returned.

In this step, you will create a load balanced http that is attached to an overlay network and look up it is Virtual IP.

Task

docker network create -d overlay eg1

This network will be a "swarm-scoped network". This means that only containers launched as a service can attach itself to the network.

docker service create --name http --network eg1 --replicas 2 katacoda/docker-http-server

By calling the service http, Docker adds an entry to it is embedded DNS server. Other containers on the network can use the friendly name to discovery the IP address. Along with ports, it is this IP address which can be used inside the network to reach the load balanced.

Use Dig to find the internal Virtual IP. Note: Interactive Services are not currently supported in Docker 1.12, this is a workaround.

docker service create --network eg1 benhall/dig dig http

docker logs $(docker ps -aq --filter="ancestor=benhall/dig:latest" | head -n1)

Pinging the name should also discover the IP address.

docker service create --network eg1 alpine ping -c5 http

docker logs $(docker ps -aq --filter="ancestor=alpine:latest" | head -n1)

This should match the Virtual IP given to the Service. You can discover this by inspecting the service.

docker service inspect http --format="{{.Endpoint.VirtualIPs}}"

Each container will still be given a unique IP addresses.

docker inspect --format="{{.NetworkSettings.Networks.eg1.IPAddress}}" $(docker ps -aq --filter="ancestor=katacoda/docker-http-server:latest" | head -n1)

This Virtual IP ensures that the load balancing works as expected within the cluster. While the IP address ensures it works outside the cluster.

Both the Virtual IP and Port Load Balancing and Service Discovery can be used in a multi-host scenario with applications communicating to different services on different hosts.

In this step, we will deploy a replicated Node.js application that communicates with Redis to store data.

Task

To start there needs to be an overlay network that the application and data store can connect to.

docker network create -d overlay app1-network

When deploying Redis, the network can be attached. The application expects to be able to connect to a Redis instance, named Redis. To enable the application to discover the Virtual IP via the Embedded DNS we call the service Redis.

docker service create --name redis --network app1-network redis:alpine

When deploying the application, a public port can be exposed allowing it to load balance the requests between the two containers.

docker service create --name app1-web --network app1-network --replicas 4 -p 80:3000 katacoda/redis-node-docker-example

Each host should have a Node.js container instance with one host storing Redis. docker ps

Calling the HTTP server will store the request in Redis and return the results. This is load balanced, with two containers talking across the overlay network to the Redis container.

curl docker

The application is now distributed across multiple hosts.