© kuzma, 123RF

Orchestrierungstools wie Chef, Puppet und Saltstack helfen sehr bei der einheitlichen Administration einer Systemlandschaft, aber sie erledigen nicht alles. Foreman ergänzt die Lücken und setzt allem eine einheitliche Oberfläche auf, die dem Admin das Leben ein ganzes Stück einfacher macht.

Der Israeli Ohad Levy stand als Administrator vor einem Zoo an Infrastruktur, die er verwalten musste. Zum Konfigurationsmanagement fiel die Wahl auf Puppet, das zwar viele Aufgaben löst, aber nicht alles vom leeren Blech ohne Betriebssystem bis hin zum Server als funktionalem Teil der Gesamtstruktur abdeckt. Dinge wie ein Installserver für Bare Metal und eine Lösung fürs Verwalten von IP-Adressen lassen sich zwar prinzipiell über Puppet abdecken, müssten aber einzeln konfiguriert werden.

Ein selbst programmiertes Deployment-Tool

Das brachte Ohad dazu, sich die fehlenden Teile dafür selbst zu programmieren. Foreman [1] war geboren. Ausgehend von Puppet bietet der “Vorarbeiter” oder “Polier” einen parametrisierbaren Installserver, der neben den meisten Linux-Derivaten und deren Installationsmechanismen (wie Kickstart oder Preseed) auch die Installation von Free BSD, Solaris oder sogar Junipers ZTP für einige Switch-Serien zulässt.

Ist das verwaltete System installiert und über die Parameter des Template auch der Puppet-Client installiert, implementiert Foreman die hinterlegten Puppet-Klassen. Als weiterer lästiger Arbeitsschritt in der Praxis erweist sich meist auch die Suche nach der Antwort auf die Frage: Welche ist die nächste freie IP-Adresse? Diese kann Foreman beim Anlegen eines neuen Host frei vergeben oder auch einfach die nächste freie IP aus dem Pool des Netzes nehmen – Einträge im DNS vorwärts und rückwärts inklusive.

Außerdem integriert sich Foreman mit diversen Cloud- und Virtualsierungsplattformen wie etwa Open Stack, O-Virt, VMware, Rackspace und Amazons AWS, sodass die beschriebenen Funktionen auch in einer virtualisierten Umgebung funktionieren. Schließlich sammelt Foreman die Ergebnisse der Installationen und Puppet-Runs wieder ein, und so hat der Administrator schnell eine gute Übersicht, ob alle Systeme auf dem aktuellen Stand sind oder ob etwas schiefgelaufen ist. Damit kann er mit ein paar Mausklicks oder einem Kommandozeilen-Aufruf ein System hochziehen, das danach keine Konfigurationsarbeiten mehr benötigt, sondern produktiv wird.

Die Architektur

Foreman ist in Ruby geschrieben und besteht aus einem Serverprozess, der die anderen Komponenten kontrolliert, aus so genannten Smart-Proxys, die mit anderen Dienste (Puppet, DHCP, DNS, TFTP…) kommunizieren, sowie einem Web-UI und einem Kommandozeilen-Werkzeug um die gewünschte Konfiguration vorzunehmen. Zum Speichern der Daten kann Foreman eine PostgreSQL- (der Default) oder eine MySQL-Datenbank verwenden. Abbildung 1 zeigt die Architektur schematisch.

Abbildung 1: Die Architektur von Foreman umfasst Smart-Proxys, mehrere APIs, nutzt Puppet und bindet auf Wunsch Datenbanken und Verzeichnisdienste an.

Die Smart-Proxys für DNS und DHCP (jeweils in der ISC-Version) kommunizieren über die Update-Protokolle der beiden Dienste (dynamische DNS-Updates oder OMAPI) mit den jeweiligen Diensten, um dort Einträge anzulegen, nachdem in Foreman ein neuer Host erzeugt wurde. Dabei können die Dienste auch auf anderen Hosts als dem Foreman-Server laufen. Bei Puppet und dem TFTP-Server landen einfach nur die richtigen Dateien im richtigen Directory.

Ändert der Admin etwas über die Oberfläche, so schiebt der Foreman-Prozess die richtigen Informationen an den (oder die) richtigen Smart-Proxys und diese ändern die Konfiguration. Geht dabei etwas schief, sollte der Admin in die Logdatei des Smart-Proxys schauen, da hier in der Regel die Kommandos zur Änderung sowie der Fehler dazu zu finden sind. Durch diese modulare Architektur lässt sich Foreman leicht um andere Orchestrierungswerkzeuge wie Chef oder Saltstack erweitern.

Die Installation

Auf [1] sind aktuell Pakete für Centos/RHEL 6 und 7, Debian 7, Ubuntu 12.04 und 14.04 sowie Fedora 19 zu finden. Die Anleitung unter »get started« führt den Admin schnell zum Erfolg, vorausgesetzt die Namensauflösung klappt: Der Fully Qualified Domain Name muss auf dem System konsistent gesetzt sein. »hostname« und »hostname -f« müssen Namen ergeben, die per DNS oder »/etc/hosts« zum richtigen Ergebnis vorwärts wie rückwärts führen.

Der Autor war in seiner Testumgebung hier zuerst etwas schlampig und hat die Ursache des Problems erst nach Tests mit drei verschiedenen Linux-Distributionen gefunden. Die Ursache ist, dass Foreman selbst eine CA für Zertifikate vorhält, mit der die Kommunikation zwischen dem Foreman-Prozess und dem Smart-Proxy abgesichert ist. Stimmt hier beim Zugriff nicht alles, verweigern die zwei aus Vertrauensgründen die Zusammenarbeit.

Nachdem das »foreman-installer« -Paket heruntergeladen und installiert ist, kann der Admin entweder über Kommandozeilenoptionen die zu installierenden Komponenten auswählen oder einen interaktiven Installer verwenden, bei dem er die Komponenten in einer Ascii-Oberfläche auswählt.

Fallstricke

Eine weitere Falle, in die die Tester des Linux-Magazins liefen, betraf die Datenbank während der Installation. Es ist gar nicht notwendig, diese selbst zu installieren oder eine eigene Instanz zu starten, das erledigt per Default der Foreman-Installer ganz von selbst. Die Tester wählten eine All-in-one-Installation, bei der neben Foreman auch Puppet, ein DHCP-, ein DNS-, ein TFTP-Server und der Smart-Proxy auf der Platte landen.

Um dies zu erreichen, muss der Admin nach der Installation einmal den Puppet-Agent auf dem Foreman-Server laufen lassen, damit der Server sich selbst und vor allem sein Netzwerk kennt. Danach bietet die Startseite einen Wizard, der das Einrichten des angeschlossenen Netzwerks und damit auch DNS und DHCP erlaubt. Hierzu werden dann nochmals »foreman-install« -Kommandozeilen ausgegeben, die die Installation um die fehlenden Komponenten erweitern.

Bei Foreman spielt eine Reihe von Komponenten zusammen, um einen Host zu installieren. Im ersten Schritt konfiguriert der Admin eine Installationsquelle, das kann ein NFS-Share, aber auch einfach eine URL sein. Die URL ist parametrisierbar, um Platzhalter für Versionsnummern zu hinterlegen – so lassen sich mit einer Quelldefinition etwa sowohl Debian 6 als auch 7 installieren.

Für die gängigsten Distributionen/Betriebssysteme sind schon Vorlagen vorhanden, die das Einrichten erleichtern. Außerdem muss der Admin CPU-Architekturen (sofern sie nicht schon gesetzt sind) angeben, etwa x86_64.

Einen Gast konfigurieren

Im nächsten Schritt konfiguriert der Admin ein Betriebssystem. Gemeint ist damit eine konkrete Instanz mit eigenen Parametern, etwa ein Ubuntu 14.04. Dem Betriebssystem weist er die Quelle – die heißt bei Foreman Image – zu. Weiter gehören zum Betriebssystem eine Architektur und eine Partitionstabelle. Auch für Letztere hält Foreman Vorgaben für die gängigen Betriebssysteme vor, jedoch sollte sich der Admin mit der jeweiligen spezifischen Weise, wie diese etwa in Kickstart oder Preseed definiert werden, auskennen, da es sich um parametrisierte Textdateien handelt. Schließlich lassen sich dem Betriebssystem noch Parameter wie ein HTTP-Proxy zuordnen, die dann in den Templates bereitstehen.

Nachdem der Admin das Betriebssystem angelegt hat, muss er Templates zuordnen. Diese teilt Foreman in drei Kategorien: PXE (wobei es davon mehrere Varianten gibt), Provision und Finish. Die PXE-Templates sorgen dafür, dass der richtige Kernel für die Installation mittels DHCP und TFTP auf dem zu installierenden Rechner landet. Unter Provision finden sich die Installationsanleitungen, also zum Beispiel eine »ks.cfg« oder eine Preseed-Datei. Schließlich kann Foreman bei Finish ein Skript bereitstellen, das am Ende der Installation Aufgaben ausführt, die nicht in den Rahmen der normalen Installationsroutinen passen.

Templates

Damit sich das Betriebssystem auf einen Host anwenden lässt, muss eben dieses Betriebssystem die geeigneten Templates erhalten. Die bei Foreman mitgelieferten Templates sind schon recht gut einsetzbar, das Preseed installiert etwa sowohl Ubuntu als auch Debian in mehreren Varianten. Ist diese Zuordnung erfolgt, kann der Admin endlich einen neuen Host anlegen. Dabei durchläuft er mehrere Reiter im Host-Dialog (Abbildung 2). Auf der ersten Seite sind der Hostname, die Hostgruppe, die Puppet-Umgebung sowie der Puppet-Server und die Puppet-CA angegeben. Soll Puppet den Host nicht verwalten, bleiben diese einfach leer.

Abbildung 2: Im Host-Dialog von Foreman erstellt der Admin neue Maschinen.

Im Netzwerkdialog stellt der Admin die DNS-Domain und das Subnetz ein, in dem der Host liegt, damit Foreman weiß, welche DHCP/TFTP-Server er zur Bereitstellung nutzen soll. Gleichzeitig werden auch DNS-Einträge angelegt. In diesem Dialog muss der Admin die MAC-Adresse des Host eingeben. Die IP-Adresse kann er entweder selber vergeben oder sich aus dem Bereich der frei vergebbaren die nächste freie vorschlagen lassen. Schließlich wählt der Admin noch im Betriebssystemreiter die Betriebssystem-Instanz, die Architektur, das Installationsmedium und die Partitionstabelle aus. Auch das Rootpasswort für den neuen Host gibt er hier ein.

Jetzt kann es losgehen. Foreman lässt den TFTP- und DHCP-Server die Konfiguration so lange bereitstellen, bis der Admin auf »Cancel build« klickt oder das Finish-Skript erfolgreich abgerufen wurde. Die mitgelieferten Templates für auf Debian und Red Hat basierende Systeme sind recht ausgereift, sie installieren gleich einen Puppet-Client mit und richten diesen ein, wenn dem Host ein Puppet-Master (der Foreman-Server oder ein von Foreman verwalteter Puppet-Server) zugewiesen ist.

Virtualisierungsmanager

Was Foreman mit echtem Blech leistet, funktioniert auch auf virtuellem. Dabei unterstützt die Software Amazons EC2, Rackspace, VMware V-Center, Google Compute Engine, Open Stack, O-Virt und Libvirt. Der Funktionsumfang unterscheidet sich je nach Provider, es lassen sich in der Regel nicht alle Eigenschaften der Virtualisierunsplattform verwalten, etwa die virtuellen Netze.

Um eine neue VM anzulegen, wählt der Admin beim neuen Host bei »Deploy on« statt »Bare Metal« einen der Hypervisoren, die unter »Compute Ressources« angelegt wurden. Je nach Hypervisor kann Foreman die neue VM dann aus einem existierenden Image installieren oder eine Installation wie bei einem physischen Host anstoßen. Im Netzwerkreiter steht dabei nur die IP des primären Interface, mit der Foreman den Host auch ins IPAM einträgt.

Im neu entstandenen Reiter »Virtual Machine« kann der Admin weitere VM-spezifische Parameter wie zusätzliche Interfaces (und in welchem Netz sie sich befinden) oder die Größe der Festplatte auswählen. Die Auswahl, ob eine PXE- oder Image-basierte Installation ansteht, trifft der Admin im Reiter »Operating System« . Dabei muss er für Images erst einige Schritte ausführen, um die Zuordnung bereitzustellen, damit das Image im Auswahldialog erscheint.

In der »Compute« -Ressource gibt der Admin ein neues Image an, es muss bereits vorher existieren. Der Dialog ordnet ein Betriebssystem und eine Architektur einem Image zu. Dabei lassen sich mehrere Images einem Betriebssystem zuweisen. Nun kann der Admin im »New Host« -Dialog ein Betriebssystem auswählen: Foreman bietet ihm jetzt alle passenden Images an.

Foreman als Puppenspieler

Die Puppet-Integration in Foreman stellt dem Admin ein mächtiges Werkzeug bereit, um auch eine große Anzahl von Hosts nach der Installation zu verwalten. Sie unterstützt Umgebungen (Environments), die eine abgeschlossene Sammlung an Puppet-Modulen und -Parametern enthalten. Eine weitere Strukturierungseinheit sind Hostgruppen, die Hosts zusammenfassen.

Auch auf dieser Ebene kann der Admin Parameter setzen, die sich an alle Hosts der Gruppe vererben. Um mehrere zusammengehörende Puppet-Module zusammenzufassen und sich so das einzelne Hinzufügen zu sparen, kann er noch Config-Groups anlegen.

Viele Puppet-Module parametrisieren die Konfigurationsdateien der Dienste, die sie verwalten, etwa die Liste der NTP-Server in einem Netzwerk. Diese Werte können Puppet-Module setzen, müssen aber nicht. Über Smart-Variables kann der Admin die Werte überschreiben. Dabei ist es möglich, auf Dinge wie Hostnamen oder IP-Adressen zu matchen oder darauf, ob ein Host virtuell oder physisch ist. Auch hier darf der Admin gültige Werte vorschreiben, um zu verhindern, dass ein anderer Anwender etwa einen nicht erreichbaren Host eingibt.

In der Definition eines Host sieht der Admin die jeweils von oben herunter vererbten Variablen und kann so schon im Vorfeld klären, was bei dem einzelnen Host ankommt.

Puppet-Runs auf den Clients erzeugen auf dem Puppet-Master diverse Informationen: Zum einen ein Inventory des Clients, zum anderen auch, ob die Konfigurationsänderungen erfolgreich waren. Diese Informationen zeigt Foreman dem Admin gleich auf der Startseite in einem Dashboard (Abbildung 3) an. Die Inventory-Informationen finden sich beim einzelnen Host oder unter »Facts« . Bei Dingen wie dem Speicher oder der CPU-Auslastung gelingt das auch mit der Hilfe von Graphen.

Abbildung 3: Das Dashboard von Foreman ist übersichtlich und erleichtert die Arbeit.

Die Kommandozeile

Das Web-UI von Foreman erweist sich als gelungen und übersichtlich. Auch die Version für mobile Endgeräte ist sehr gut bedienbar. Möchte der Admin aber viele Aktionen auslösen (etwa 20 ähnliche VMs instanzieren), dann sind die vielen Klicks mühsam und die Wahrscheinlichkeit, einen Fehler zu begehen, steigt. Manche Admins möchten auch einfach lieber tippen als klicken.

Dazu liefert Foreman das Kommandozeilentool »hammer« mit, das dem Admin nahezu alle Funktionen des UI liefert. Im Test klappte das aber nicht: Beim Ausrollen von VMs auf einem Host mit Libvirt hatte »hammer« zwar alle Optionen erhalten, das Ergebnis war aber nicht das gewünschte. Das UI operierte jedoch mit den gleichen Daten problemlos.

Im Vergleich zum UI muss der Admin sich die Kommandozeile für etwa einen neuen Host immer erst einmal zusammensuchen. Für alle Komponenten (OS, Architektur, Netz etc.) gibt es »list« -Kommandos, mit denen entweder die Namen oder die IDs der jeweils relevanten Komponente angezeigt werden können. Der resultierende Aufruf ist auch etwas länglich:

hammer -u Username -p Password host create --architecture x86_64 --domain Testdomain --environment puppet_production --hostgroup Testhost --managed --name Name_des_neuen_Hosts --ptable debian_all --subnet Webservernetz --mac 1:2:3:4:5:6

Trotzdem gelingt mit Hammer das Provisionieren einer Reihe von Hosts schneller als im UI, vor allem wenn der Admin den einmal zusammengepuzzelten Aufruf in einer Schleife über beispielsweise alle MAC-Adressen des neuen Server-Rack durchführt. Weil Hammer lediglich ein Frontend für das offengelegte API ist, lassen sich auch komplexere Orchestrierungsschritte programmieren und von Foreman über das API abarbeiten.

Fazit

Foreman kam dem Autor zunächst als UI für Puppet in die Finger, stellte sich aber als angenehme Überraschung heraus, die viel mehr kann. Die Tatsache, dass Foreman die Basis von Red Hat Satellite 6 ist und auch in großen Installationen wie etwa bei Ebay [2] Verwendung findet, bestätigt den positiven Eindruck. Beim ersten Einsatz sind einige Arbeitsabläufe etwas gewöhnungsbedürftig, hat der Admin sie aber verstanden, geht die Arbeit leicht von der Hand.

Im IRC-Kanal »#theforeman« auf http://irc.freenode.net erhält man bei Problemen fast immer schnelle und kompetente Antwort, was bei Startschwierigkeiten gut weiterhilft. Plugins für Saltstack und Chef erlauben es auch Anwendern anderer Orchestrierungslösungen, Foreman zu nutzen. Die rege Community des Projekts bringt auch Perlen wie das Discovery-Plugin zustande, bei dem per PXE-Boot ein Minisystem auf leeren Servern bootet, um diese erst einmal in das Inventory von Foreman einzupflegen. Nach dem Lauf kennt der Admin die MAC-Adressen und Hardware-Gegebenheiten und kann das neue Rack im Serverraum verplanen, ohne jemals einen Fuß ins Rechenzentrum gesetzt zu haben.

Das Lesen der Dokumentation ist allerdings zu empfehlen, da bei einigen Dingen manuelle Konfigurationen notwendig sind, beispielsweise am DHCP-Server, um Vendor-Spaces für Juniper oder Sun anzulegen. Auch das Studium der Logdateien ist öfter notwendig, etwa wenn vom Web-UI nur eine Fehlermeldung der Form “Geht nicht!” zurückkommt. In der Summe ist Foreman ein lobenswertes Werkzeug, das den Alltag im Rechenzentrum sehr vereinfachen kann.