Life Cycle Management mit Foreman und Puppet

Im Open-Source-Bereich gibt es für routinemäßige Verwaltungsjobs zwei Projekte, die sich perfekt ergänzen: Puppet und Foreman. Puppet ist ein Open Source Configuration Management Toolset und Framework geschrieben in Ruby für die Verwaltung und Konfiguration von Servern. Mit Puppet kann man relativ unabhängig vom darunterliegenden Betriebssystem zusätzliche Software installieren und konfigurieren. Unterstützte Betriebssysteme sind die gängigen Linux-Distributionen, Unix und mittlerweile auch Windows.

In einer typischen Puppet-Umgebung gibt es einen Master (Server) und einen oder mehrere Agents (Clients). Die Kommunikation zwischen Master und Agent erfolgt ist mit selbst signierten SSL-Zertifikaten gesichert. Auf dem Master ist ein sogenanntes Manifest hinterlegt, das die Rolle und den Sollzustand des Clients beschreibt. Ein Sollzustand wäre etwa "Webserver mit PHP und lokalen Benutzern mit SSH-Keys". Das Manifest kann in einer Domain Specific Language (DSL) verfasst sein.

Zusätzlich findet sich auf dem Client noch Facter. Diese Software sammelt Informationen über das System und leitet sie in einem Puppet-Lauf an den Puppet-Master weiter. Aufgrund der gesammelten Facts kann der Master aus dem im Vorfeld definierten Manifest einen dynamischen Katalog erzeugen. Der Katalog wird wiederum auf dem Agent ausgeführt, der anhand der Facter-Informationen die richtigen Befehle absetzt. Facter ermitttelt eine Menge Tatsachen über Betriebssystem, Hardware, Software, Netzwerk und so weiter. Wer noch mehr Informationen braucht, kann eigene Custom Facts definieren. Will man beispielsweise Apache2 als Webserver installieren, sieht ein Auszug aus dem Manifest so aus:

package { "apache2" :
        ensure => "installed",
}

Im Fall von Debian würde Puppet für das Paket den Provider »apt« wählen und ein »apt-get install apache2« ausführen. Für Red Hat würde die Paketverwaltung Yum in Aktion treten.

Allerdings müsste ein »yum install apache2« zu einer Fehlermeldung führen, weil das Paket bei RHEL nicht »apache« sondern »httpd« heißt. Um sein Manifest betriebssystemübergreifend zu gestalten sind erneut die Facts notwendig. Facts lassen sich im Manifest als Variablen für Entscheidungen nutzen (Listing 1).

Mit der Puppet-DSL sind ähnlich wie in Programmiersprachen Vererbungen, Klassen, Module, Arrays, Variablen, Parameter, Templates und Scopes verfügbar. Es gibt also jede Menge Möglichkeiten seine Manifeste robust, flexibel und modular zu schreiben. Geht man noch einen Schritt weiter, sorgt man zusätzlich dafür, dass die Konfiguration für Apache inklusive möglicher VirtualHosts mit ausgerollt und der Webserver beim Booten und nach Änderungen an der Apache-Konfiguration neugestartet wird.

Beide Klassen »apache::service« und »apache::config« benötigen die Klasse »apache::install« bevor sie sich ausführen lassen. Die Klasse »apache::install« installiert lediglich das Paket »httpd« oder »apache2« . Eine logische, zusammengehörende Sammlung von Klassen wird Modul genannt (Listing 2).

Hat man sein Manifest an seine Bedürfnisse angepasst, ist es ein Leichtes, neue oder zusätzliche Server oder auch den gleichen Server nach einer Neuinstallation wieder in den definierten Zielzustand zu versetzen. Puppet hat außerdem eine große Community, und man kann sich mit schon vorhanden Modulen aus Puppet-Forge oder Github bedienen.

Zusammengefasst ist Puppet ein Tool, mit dem man seinen Server bis in kleinste Detail konfigurieren kann. Die eigentliche Betriebssysteminstallation nimmt Puppet einem jedoch nicht ab, und genau hier setzt Foreman an.

Foreman ist ein Life-Cycle-Management-Tool, mit dem man vom Anlegen eines Hosts und der Installation des Betriebssystems, über das Verwalten mit Puppet, bis zum Löschen einen kompletten Lebenszyklus abdecken kann.

Die Installation erfolgt entweder durch einen Installer, direkt aus den Quellen des Git-Repository, oder man nutzt die vorgebauten Pakete.

Foreman interagiert sehr eng mit Puppet, aber auch mit anderen vermutlich schon vorhandenen Infrastrukturelementen (Abbildung 1), ist sehr dynamisch und kann je nach Anforderungen mit mehr oder weniger Features genutzt werden. Für einen Teil seiner Features nutzt Fore-man einen sogenannten Smart-Proxy. Ein Smart-Proxy ist ein Server, der sich zum Beispiel um das Eintragen der DNS-Records oder das Bereitstellen der PXE-Installation kümmert. Smart-Proxies können in beliebiger Anzahl auf dem gleichen Server wie auch Foreman selbst installiert werden.Das geschieht wie bei Foreman selbst über die vorgebauten Pakete für die unterstützten Distributionen oder direkt aus dem Quellcode. Die Kommunikation zwischen Foreman und einem Smart-Proxy erfolgt über eine Restful-API. Hat man zum Beispiel ein subnetzübergreifendes Netzwerk ohne DHCP-Relay, ist es notwendig mehrere Smart-Proxies zu verwenden, die sich um die automatische Installation im jeweiligen Netzsegment kümmern.

Abbildung 1: Das Zusammenspiel der Komponenten in einer Umgebung, die Foreman nutzt.

Zu den Smart-Proxy-Features gehören:

• DHCP: Übernimmt die automatische Vergabe von IP-Adressen aus definierten Subnetzen oder IP-Adressbereichen.
• DNS: Stellt die Namensauflösung für Forward- und Reverse-Hosteinträge bereit. Es werden nur ISC kompatible Produkte wie Bind und Microsoft DNS-Server unterstützt. Das Update auf eine dynamische Zone erfolgt über »nsupdate« und wird mit einem vorher erstellten und konfigurierten Schlüssel auf dem Nameserver authentifiziert.
• TFTP und PXE: Die automatischen Installationen setzen einen konfigurierten DHCP-Server voraus und können ein Betriebssystem auf einem PXE-bootfähigen Server installieren. Die Installation erfolgt über das auf dem TFTP-Server zur Verfügung stehende Image und wird anschließend über Kickstart (Fedora, RHEL) oder Preseed (Debian, Ubuntu) mit den vordefinierten Installationsantworten bespielt. Neben Kickstart und Preseed können weitere Techniken genutzt werden wie etwa Jumpstart .
• PuppetCA: Mit diesem Feature übernimmt Foreman das Signieren der Puppet-SSL Zertifikate zwischen Master und Agent. Nachdem das Betriebssystem installiert wurde, ist ein Puppet-Run ohne manuelles Eingreifen im Anschluss möglich, der die Konfiguration aus dem Puppet-Manifest ausrollt.

Ohne Smart-Proxy

• BENC: Puppet bietet einen sogenannten External Node Classifier an. Er führt ein Skript aus, dass die Klassenzuweisung aus einer anderen Datenquelle ausliest und ausgibt. Über die Weboberfläche von Foreman kann man so einen Host anlegen und ihm Puppet-Klassen zuweisen.
• CMDB: Foreman lässt sich auch als Configuration Management Database nutzen, eine gesonderte Inventarpflege kann dann entfallen. Das Inventar bilden in allererster Linie die Facter-Informationen. Fehlende oder zusätzliche Informationen lassen sich wie schon erwähnt in Custom Facts leicht abbilden.
• Compute Ressources: Foreman ist in der Lage, nicht nur physische, sondern auch virtuelle Maschinen aus Private und oder Public Clouds zu provisionieren. Anstelle eines Bare-Metal Servers wird etwa direkt eine AWS-EC2-Instanz in der Amazon Cloud deployed. Unterstützt werden außerdem VMware oder Openstack.
• Reporting: Der Report eines Puppet-Agent wird in der Regel an seinen Puppet-Master gesendet. Zusätzlich kann der Report zur Einsicht und für Statistiken an Foreman gehen.
• Auditing: Über das Audit Feature lassen sich Änderungen durch Kollegen oder Kunden einsehen.
• LDAP: Die Foreman-Benutzerauthentifizierung kann ein vorhandenes LDAP oder Active-Directory ansprechen und somit eine zentrale Authentifizierungsstelle nutzen.

Zeit sparen

Die Einrichtung und Integration in die bestehende Infrastruktur benötigt Überblick über alle Komponenten und oft auch etwas Zeit. Hat man jedoch alle Komponenten und Features installiert, können Foreman und Puppet einem sehr viel Zeit sparen.

Wird beispielsweise ein neuer Debian Applikationsserver benötigt, loggt sich ein Administrator mit seinen Active Directory Login-Daten in Foreman ein und legt einen neuen Host über das Formular an. Dort wählt er seinen Hostnamen, das Betriebssystem und die Puppet-Module aus. Die nächste freie IP-Adresse wird anhand der Zuordnung zur Domain bereits vorgeschlagen. Die Puppet-Module wären exemplarisch »ssh, apache2, php, haproxy« .

Sobald der Sysadmin das Formular bestätigt, wird auf dem PXE/TFTP-Server ein Eintrag erzeugt, der den Server mit der verwendeten MAC-Adresse und einem Debian Linux installiert. Auch der DHCP Server hat einen Static-Lease für den Server bereits eingerichet und wird dem Server, sobald er danach fragt, die IP-Adresse zuweisen. Der Server bootet, wird per Preseed installiert und abschließend bei seinem Puppetmaster für den bevorstehenden ersten Puppet-Run vorbereitet.

Zusätzlich könnte hier der Sysadmin das Finish-Skript so erweitert haben, dass es den Server auch gleich noch in das Monitoring einpflegt. Nach einem Reboot weiß Foreman, dass der Server sich vollständig installiert hat und ändert seinen PXE-Boot-Eintrag ab, sodass der Server nun nicht mehr das Installationsimage, sondern von Festplatte startet.

Danach läuft auch der Dienst »puppetd« , der sogleich einen Puppet-Lauf ausführen wird. Der Puppet-Agent fragt bei seinem Puppet-Master nach seinem Manifest und führt es aus. Der Report über die erfolgreiche Installation der Puppet-Klassen wird ebenfalls wieder an Foreman zurückgeliefert, sodass der Sysadmin den Status des Servers über die Weboberfläche verfolgen kann.

Etwaige Fehler wären hier sofort zu sehen. Die Puppet-Module haben den Server angewiesen Apache2 mit PHP zu installieren, alle Vhosts wurden ebenfalls eingerichtet, zusätzlich wurden ihre Informationen über das »haproxy« -Modul an den Loadbalancer mitgeteilt und auch gleich mitkonfiguriert. Der Server ist also gleich produktiv.

Der Administrator vergewissert sich mit einem SSH-Login auf dem Server, ob alles seine Richtigkeit hat. Der SSH-Login erfolgt über den SSH-Key und den Hostname des Servers, da Foreman für die DNS-Einträge gesorgt hat und Puppet den SSH-Key des Admins ebenfalls hinterlegt hat. Alles in allem hat das den Systemadministrator nicht mehr als 5 bis 10 Minuten Zeit gekostet, inklusive der Installation.

Das Beispiel macht klar, welchen Mehrwert man von einer solchen Lösung hat. Nicht nur der Zeitvorteil, sondern auch die Vollständigkeit des Setups sind überzeugend. Bei einem manuellen Setup passieren Fehler, auch wenn es nur der DNS-Reverse Eintrag ist, den man vergisst, der dann aber früher oder später Probleme machen könnte.

Foreman wird aktiv weiterentwickelt und eben auf die Version 1.1 aktualisiert. In dieser Version sind unter anderem die langersehnten Features wie "parameterized Classes", "Support für Puppet 3", "Locations und Organizations" und viele andere Verbesserungen implementiert.

Der Autor

Sebastian Saemann arbeitet für die Netways Managed Service GmbH, die unter anderem Partner von Puppetlabs ist, als Senior Systems Engineer und Teamleiter im Bereich Managed Hosting. Er ist verantwortlich für die Planung und Umsetzung interner und externer Projekte. Seit mehreren Jahren beschäftigt er sich mit dem Thema Automatisierung im Rechenzentrum insbesondere mit Puppet und Foreman. Darüber hinaus hält er als Trainer Puppet-Schulungen.