Mit Hilfe von Consul ist es möglich die Bereiche Service Discovery, Health Checking und Key/Value Store miteinander zu kombinieren. Während Service Discovery ermittelt, von welchen Nodes ein Service wie zum Beispiel Web zur Verfügung gestellt wird, prüft Health Checking in welchem Zustand sich die einzelnen Nodes befinden. Davon abhängig entscheidet Service Discovery, ob die betreffende Node beim Routing des Traffic berücksichtigt wird. Anschließend wird der Key/Value Store genutzt, um intakte Nodes bei der dynamischen Konfiguration des Loadbalancer zu berücksichtigen.

Mit dem Befehl consul agent -bootstrap-expect 1 -data-dir /tmp/consul -server oder consul agent -data-dir /tmp/consul wird der Agent als Server bzw. Client gestartet. Damit es nicht zum Ausfall, Datenverlust oder Split Brain kommt, sollten drei bis fünf Server pro Rechenzentrum betrieben werden. Die Kommunikation zwischen den Servern und den Clients erfolgt über das Gossip-Protokoll von Serf, wobei die Server und die Clients der einzelnen Rechenzentren einen LAN Pool bilden und die Server aller Rechenzentren einen WAN Pool.

Die Konfiguration des Agent erfolgt im Verzeichnis /etc/consul.d und die darin enthaltenen Dateien mit der Endung .json werden beim Start in alphabetischer Reihenfolge geladen. Für den Fall, dass mehr als ein Rechenzentrum betrieben wird, sollte die Kommunikation über das Gossip-Protokoll und das RPC-Protokoll mit einem statischen Schlüssel bzw. TLS-Zertifikat verschlüsselt werden. Damit der Agent nach dem Neustart einer Node automatisch gestartet wird, muss ein Init-Skript erstellt und in den betreffenden Runlevel aufgenommen werden.

Eine Interaktion mit den Servern ist über mehrere Schnittstellen möglich. Der Befehl consul join 192.168.56.20 nutzt zum Beispiel das RPC-Protokoll, um eine Node in den Cluster aufzunehmen. Während der Befehl curl localhost:8500/v1/catalog/nodes die HTTP API nutzt, um die Mitglieder eines Cluster aufzulisten, verwendet der Befehl dig @localhost -p 8600 server01.node.consul das DNS Interface, um die IP-Adresse einer bestimmten Node zu ermitteln.

Obwohl Chef und Puppet eine ähnliche Funktionalität bieten, ist Consul in der Lage schneller auf neue oder fehlerhafte Nodes zu reagieren. Denn das Intervall, mit dem die Health Checks durchgeführt werden, beträgt oft nur einige Sekunden und nicht 30 Minuten. Außerdem kann consul exec [options] [-|command...] genutzt werden, um die Nodes nach Name, Service oder Tag zu filtern und dort einen Befehl auszuführen.

Zum Schluss möchte ich noch auf ein paar Projekte verweisen:

• Envconsul wird genutzt, um die Daten von Consul als Umgebungsvariable zur Verfügung zu stellen und beim Start eines Dienstes zu berücksichtigen.
• Consul Template wird genutzt, um die Daten von Consul an eine Template Engine zu übergeben und anschließend einen Neustart des Dienstes durchzuführen.
• Consul Web UI wird verwendet, um den Status der einzelnen Nodes, Services, Key/Value Paare und ACL zu erhalten. Eine Darstellung pro Rechenzentrum ist ebenfalls möglich.

• Das Puppet Modul von Kyle Anderson wird benötigt, um Consul zu installieren und anschließend als Server oder Client inkl. Services zu konfigurieren.