In Chapter 1, Welcome to Docker Swarm we created a simple yet well functioning local Docker Swarm cluster using the nodes:// mechanism. This system is not very practical, except for learning the Swarm fundamentals.
In fact, it is just a flat model that does not contemplate any true master-slave architecture, not to mention the high-level services, such as nodes discovery and auto-configuration, resilience, leader elections, and failover (high availability). In practice, it's not suitable for a production environment.
Apart from nodes://, Swarm v1 officially supports four discovery services; however, one of them, Token, is a trivial non-production one. Basically, with Swarm v1 you need to integrate a discovery service manually, while with Swarm Mode (from Docker 1.12), a discovery service, Etcd, is already integrated. In this chapter we're going to cover:
- Discovery services
- A test-grade discovery service: Token
- Raft theory and Etcd
- Zookeeper and Consul
Before exploring these services in depth, lets us discuss what is a discovery service?
Imagine you're running a Swarm cluster on a static configuration, similar to the one in Chapter 1, Welcome to Docker Swarm, networking is flat and every container is assigned a specific task, for example a MySQL database. It's easy to locate the MySQL container because you assigned it a defined IP address or you run some DNS server. It's easy to notify whether this single container is working or not and it's a known fact that it won't change its port (tcp/3336). Moreover, it's not necessary that our MySQL container announces its availability as a database container with its IP and port: We, of course, already know that.
This is the pet model, mocked-up manually by a system administrator. However, since we're more advanced operators, we want to drive a cattle instead.
So, imagine you're running a Swarm made of hundreds of nodes, hosting several applications running a certain number of services (web servers, databases, key-value stores, caches, and queues). These applications run on a massive number of containers that may dynamically change their IP address, either because you restart them, you create new ones, you spin up replicas, or some high availability mechanism starts new ones for you.
How can you find the MySQL services acting of your Acme app? How do you ensure that your load balancer knows the address of your 100 Nginx frontends so that their functionalities don't break? How do you notify if a service has moved away with a different configuration?
You use a discovery service.
A so called discovery service is a mechanism with many features. There are different services you can choose from, with more or less similar qualities, with their pros and their cons, but basically all discovery services target distributed systems, hence they must be distributed on all cluster nodes, be scalable, and fault-tolerant. The main goal of a discovery service is to help services to find and talk to one another. In order to do that, they need to save (register) information related to where each service is located, by announcing themselves, and they usually do that by acting as a key-value store. Discovery services existed way before of the rise of Docker, but the problem has become a lot more difficult with the advent of containers and container orchestration.
Summarizing again, through a discovery service:
- You can locate single services in the infrastructure
- You can notify a service configuration change
- Services register their availability
- And more
Typically, a discovery service is made as a key-value store. Docker Swarm v1, officially, supports the following discovery services. However, you can integrate your own using libkv abstraction interface, you can integrate your own one as shown in the following site:
https://github.com/docker/docker/tree/master/pkg/discovery.
- Token
- Consul 0.5.1+
- Etcd 2.0+
- ZooKeeper 3.4.5+
However, the Etcd library has been integrated into the Swarm mode as its built-in discovery service.