Container- und Microservice-Verwaltung mit Nomad
Immer in Bewegung
Mit Nomad hat HashiCorp ein Werkzeug im Angebot, das dem Prinzip folgt, genau eine Sache richtig gut zu machen. Es soll Microservices und Container verwalten. Dabei möchte es unkompliziert bleiben.
Nomad gehört zu den Orchestratoren und seine Aufgabe ist es, Anwendungen zu verwalten und zu überwachen. Es folgt einem Client-Server-Prinzip. Die Server verwalten eine beliebige Anzahl von Clients, auf denen die Anwendungen laufen. Nomad kümmert sich zusammen mit Consul (ebenfalls von HashiCorp) unter anderem um die folgenden Aufgaben:
– Anwendungen starten;
– Programme am Laufen halten oder sicherstellen, dass sie regelmäßig ausgeführt werden;
– Überwachen und Skalieren verteilter Anwendungen;
– Softwareverteilung (Deployment) und
– Service Discovery (über Consul).
Nomad soll einen einfachen Weg bereitstellen, Anwendungen im Cluster auszurollen und deren laufenden Betrieb zu garantieren. Damit gesellt es sich zu anderen Tools wie Kubernetes, Mesos mit Marathon, Docker Swarm und AWS ECS. Ein direkter Vergleich ist in der Nomad-Dokumentation verfügbar ([a], siehe „Alle Links“ am Ende des Artikels).
Wie die meisten HashiCorp-Tools ist Nomad ein Leichtgewicht und schnell aufgesetzt. Die einzige Voraussetzung für den Betrieb ist das hauseigene Service-Discovery-Tool Consul, das das Aufsetzen eines Nomad-Clusters vereinfacht.
Vielseitiger Antrieb
Mit seinen bisher sieben Treibern zum Ausführen verschiedener Anwendungstypen ist Nomad geradezu ein Alleskönner. Wo sich einige der Konkurrenten auf einen bestimmten Anwendungstyp beschränken, lässt sich mit Nomad fast jede Arbeitslast verwalten. Derzeit stehen folgende Treiber bereit:
– Docker
– rkt
– Java
– LXC
– QEMU
– Raw Fork/Exec: ausführbare Programme (Binaries)
– Isolated Fork/Exec: ausführbare Programme (Binaries) in isolierter Umgebung (Chroot)
Nomad verwaltet einen Cluster von Instanzen (Bare Metal oder virtuell) als Clients (Nodes) und abstrahiert, auf welchen Instanzen eine Software läuft. Man übergibt einfach einen Job über das Kommandozeilentool oder die API und Nomad findet einen geeigneten Platz im Cluster, um diesen Job auszuführen. Jobs können dabei lang laufende Anwendungen wie Daemons oder periodische Prozesse (Cronjobs) sein.
Die Infrastruktur wird unsichtbar
Außerdem lassen sich Jobs über Constraints an bestimmte Knoten koppeln. Diese müssen dann zum Beispiel ein spezielles Betriebssystem verwenden oder der Kernel muss eine bestimmte Version besitzen. Eine detaillierte Beschreibung des Scheduling-Prozesses findet man ebenfalls in der Nomad- Dokumentation [b]. Zudem funktioniert Nomad über mehrere Rechenzentren und Regionen hinweg.
Um Nomad auszuführen, wird zunächst Consul als Backend benötigt. Consul lässt sich als ausführbare Datei für (fast) jedes Betriebssystem herunterladen [c]. Dasselbe gilt für Nomad: Man lädt einfach die Binärdatei von der Homepage [d] herunter. Diese Programme sind jeweils als Server, Client und Kommandozeilen-Verwaltungstool einsetzbar.
Wenn man schnell starten will oder einfach nur einen Testlauf durchführen möchte, bietet sich bei beiden Tools der Entwicklungsmodus an, um sie auf einem einzelnen Knoten verwenden zu können. So stellt man ein laufendes Nomad-System mit nur zwei Befehlen bereit:
consul agent -dev nomad agent -dev
Nomad findet den Consul-Dienst automatisch, wenn dieser auf dem Standard-Port läuft. Mit dem Befehl nomad init wird eine example.nomad-Datei generiert, die für einen Docker-Container mit Redis konfiguriert ist. Wenn auf dem Hostsystem, auf dem Nomad läuft, Docker installiert ist, lässt sich der Job mit dem Befehl nomad run example.nomad an Nomad übergeben und ein Docker-Container mit Redis startet.
Schnelles, ereignisarmes Setup
Für den Produktivbetrieb sollte man einen Cluster aufsetzen: mindestens drei Knoten, stets eine ungerade Anzahl. Hierzu findet man eine Anleitung auf der Homepage von Consul [e]. Auch Nomad sollte mit mindestens drei Serverknoten sowie zwei Clients aufgesetzt werden. Auf den Clients landen später die orchestrierten Jobs, während die Server die Verteilung und Verwaltung überwachen.
Auf den Knoten (Server und Client) sollte jeweils auch Consul laufen, um Installation und Konfiguration zu vereinfachen. Nomad verwendet das Consul-Backend, wenn beide Systeme auf den gleichen Maschinen installiert sind, und erkennt automatisch den restlichen Cluster. Ein händisches nomad join ist nicht mehr nötig. Agents lassen sich mit direktem Angeben aller Parameter starten:
nomad agent -server -data-dir=/var/nomad ⤦ --bootstrap-expect=3 -bind=... nomad agent -client -data-dir=/var/nomad ⤦ -servers=... -bind=...
Bequemer ist allerdings die Definition in einer Konfigurationsdatei: