Bringing Old Programs On-board

Etcd also has a solution for traditional software that expects a fixed configuration file in /etc (Figure 2). Because Etcd is familiar with templates, you can place an appropriate template on the target host and then apply the matching key-value pairs to generate an nginx.conf file. A second service then comes into play, confd, which automatically generates the appropriate nginx.conf from the values in Etcd and places them in the desired location. Restarting Nginx then implements the configuration. Impressively, the whole process also complies with changes in configuration. If you change the Nginx configuration in Etcd, Confd triggers both configuration files to update and restarts Nginx.

Figure 2: Even if Etcd is running on a host, it does not mean that /etc is completely empty.

Somewhat Useful

Although it might also be possible to operate Etcd without additional components such as Confd, Etcd is strictly speaking intended to be a global configuration tool as part of CoreOS and best fits in this setup (Figure 3).

Figure 3: A clear case: Etcd feels best when used as part of a Docker installation [4].

With the Armada tool, you can start Docker containers at will from CoreOS servers and running Etcd instances. In return, they read their necessary configuration from the Etcd instances on the host. The cluster part of Etcd ensures that all CoreOS instances are always familiar with the whole configuration. Two separate services called Systemd and Fleetd take control of the cluster on the basis of data from Etcd. It could be possible, but also complex, to use Etcd meaningfully without this framework.

One for All: Consul

Although Etcd and Consul have differences, they are also similar in many respects. Consul, by HashiCorp, takes a significantly more comprehensive approach, leaving no doubt that it wants to serve all areas of application.

Consul also implements a key-value store for configuration data. Just as in Etcd, it has RESTful interfaces and provides JSON outputs. However, the Consul API yields significantly more than Etcd: For example, a catalog function records which nodes in the network can register services such as MySQL. Other nodes then query the Consul API to receive a list of all nodes in the cluster network that are operating the respective service (Figure 4).

Figure 4: Everything is as it should be: This Consul cluster comprises three nodes that agree regarding their state.

Other factors include standalone API modules for health checks, ACLs, or users events. Consul refers to endpoints, each of which is almost its own service category. Simply replacing configuration files in /etc is no longer so important in Consul. Instead, Consul aims to be a comprehensive service registry in which configuration management is a by-product.