Puppentheater Server Management leicht gemacht... the smarter way of information
Seite 2/7 Im Bereich von Systemen zum automatischen Setup und Betrieb von großen Serverlandschaften, fällt ein Tool besonders auf, das in den letzten Jahren durch eine schnell wachsende Gemeinde von Anwendern und fein abgestimmten Releases von sich reden macht: Puppet. Entstanden durch die Unzufriedenheit des heutigen CEO von PuppetLabs mit anderen Konfigurationswerkzeugen und den damit einhergehenden unzureichenden Möglichkeiten, große Rechnerlandschaften zu managen, begann Luke Kanies seit 2005 an Puppet zu arbeiten und gründete später die Firma PuppetLabs. Anfänglich als Freie Software gestartet, existiert immer noch eine Open-Source-Variante, die bezüglich der Konfigurationsmöglichkeiten den vollen Umfang des Enterprise-Paketes beinhaltet, allerdings hinsichtlich weitergehender Werkzeuge und Möglichkeiten einen reduzierten Umfang bietet. Für weitere Informationen hierzu, klicken Sie bitte hier. Puppet liegt zurzeit in der Version 3.2.1 vor und arbeitet auf allen Unix- bzw. Linux-Systemen. Seit der Version 2.7 wird Windows -wenn auch in reduziertem Umfang unterstützt. Im Rahmen der Artikelserie über Tools zum Thema Continuous Integration & Delivery kommt man an Puppet und seinen Derivaten (Chef, cfengine usw.) nicht vorbei. Abweichend von den anderen Newslettern werden wir im Rahmen dieses Artikels nicht so sehr ins technische Detail gehen, sondern mehr das System an sich, seinen Einsatzrahmen und die zugrundeliegende Philosophie beleuchten. Hinter den Kulissen Puppet bezeichnet sich selbst als Open Source Next Generation Server Automation Tool. Hinter diesem langen Namen verbirgt sich ein in Ruby geschriebenes Werkzeug, das mittels einer Client-Server-Architektur und einer deklarativen Sprache zur Formulierung von Zuständen bzw. Konfigurationen von Servern und Subsystemen (sog. Manifests ) in der Lage ist, die entsprechenden Maschinen zu administrieren. Dies geschieht über den sogenannten Puppet Master auf dem alle auszuliefernden Konfigurationen definiert werden. Anschließend muss auf allen Rechnern, die über das System administriert werden sollen, der Client Puppet Agent installiert werden. Im Default-Verhalten greift anschließend der Client alle 30 Minuten auf den Master zu, holt sich die neueste Definition ab und protokolliert alle Aktivitäten auf dem Server.
Seite 3/7 Wie arbeitet Puppet? Wie oben schon beschrieben, benutzt Puppet ein deklaratives, modellbasiertes System zur Automatisierung der Vorgänge. 1. Definieren Der gewünschte Zustand der Konfiguration wird mittels der deklarativen Sprache von Puppet festgelegt und auf dem Puppet Master gespeichert. 2. Simulieren Puppet bietet die Möglichkeit, anstehende Änderungen im Bedarfsfall vor der Installation zu simulieren und zu testen, ob der gewünschte Zustand erreicht wird. 3. Durchführen Der auf dem Puppet Master hinterlegte Zustand wird automatisch deployed und korrigiert alle Konfigurationen im angedachten Sinne. 4. Berichten Abschließend werden die Unterschiede zwischen der auf dem Server vorgefundenen und der angestrebten Definition protokolliert.
Seite 4/7 Wie wird das Konzept umgesetzt? Schauen wir uns die Umsetzung der oben genannten Philosophie anhand eines aktuellen Beispiels aus der Praxis genauer an. Um eine applikation zu deployen, wird eine Datenbank, ein Applikation und ein benötigt. Dies kann auf einem einzelnen Rechner durchgeführt werden. Typischerweise wird dies allerdings auf mehreren Rechnern -einer für jede Komponente- erfolgen. Diese Rechner (sog. s ) und die auf ihnen installierten Komponenten (sog. Resources ) stehen in enger Beziehung zueinander und sind einem Lebenszyklus mitsamt Anpassungen, Änderungen und Austausch unterworfen. Die Beziehungen zwischen den Komponenten und die darin enthaltenen Konfigurationen werden jetzt über Puppet abgebildet und auf dem Master gespeichert. Die Deklaration einer Beziehung erfolgt über ein sogenanntes Manifest. Der Kern einer Deklaration besteht darin, die Resources zu definieren, wobei sie anschließend wieder logisch in Classes gruppiert werden können. Eine Ressource beschreibt vielleicht ein einzelnes File oder Package, wohingegen eine Klasse beispielsweise alles Notwendige zur Beschreibung eines kompletten Service oder einer Applikation (inklusive den KonfigFiles, den Daemons und den Wartungs-Tasks) beinhaltet. Kleinere Klassen können anschließend mit größeren kombiniert werden, um komplette Systeme wie Server oder Applikation Server zu beschreiben. Manifeste können Logik enthalten, um die Konfiguration mehrerer Knoten auf einmal abzubilden. Vor der Konfiguration eines Knotens (also dem eigentlichen Deployment) kompiliert Puppet das Manifest in einen Katalog, der nur für EINEN Knoten gültig ist und keine zweideutige Logik mehr enthält. In der Standard Agent- Master-Architektur fragen die Knoten die Kataloge des Puppet Master Servers ab, der anschließend für den entsprechenden Knoten kompiliert wird. Wird Puppet als Standalone-Variante auf einem Server/Knoten betrieben, werden die Kataloge lokal kompiliert und sofort eingespielt.
Seite 5/7 Die Statisten - wiederverwertbare Module Puppet geht davon aus, dass jede Infrastruktur bezüglich ihrer Verwendung in Module geclustert und an geeigneter Stelle wiederverwertet werden kann. Der entsprechende Wunschzustand bzw. das vordefinierte Modul einer Infrastrukturkomponente oder auch der gesamten Infrastruktur kann entweder über Puppet Forge publiziert oder nur einfach intern verwendet können. Sollte in Puppet Forge nicht das geeignete Modul vorhanden bzw. eine spezielle Anforderung vorliegen, so modelliert man in der Puppet eigenen Konfigurationssprache sein individuelles Modul. Dieses Modul kann anschließend über physische, virtuelle oder auch cloud-basierte Umgebungen verwendet werden. Des Weiteren können Module kombiniert und zu werden. größeren Konfigurationen, die Im vereinfachten Sinne sind Module komplette Applikations-Stacks (sog. wiederverwendbare Puppet- s ) repräsentieren, orchest- Code-Fragmente, die auch mit anderen riert werden. Anwendern geteilt werden Module App Puppet Forge: Das hauseigene Repository in dem die Community selbstgeschriebene Module hinterlegt und der übrigen Gemeinde zugänglich machen kann. Link zu Puppet Forge derzeitige Anzahl verfügbarer Module: ubunutu (207 modules) debian (166 modules) rhel (132 modules) CentOS (110 modules) centos (74 modules) monitoring (70 modules) networking (64 modules) security (60 modules) applications (55 modules) redhat (53 modules) Kombiniere Anwendungsmodule Servers Servers Application Servers App App
Seite 6/7 Die Aufführung - den festgelegten Status ausführen Nach der Installation der vordefinierten Konfigurationsmodule kommuniziert der Puppet Agent jedes einzelnen Knotens in regelmäßigen Abständen mit dem Puppet Master, um automatisch die Konsistenz der Konfiguration zwischen Master und Agenten zu gewährleisten. Der Agent eines Knotens sendet einen Statusreport (sog. Facts ) zum Puppet Master. Der Puppet Master kompiliert unter Zuhilfenahme der Facts einen Katalog (einen Konfigurationsplan), wie der Knoten konfiguriert werden sollte und sendet diesen an den Agenten zurück. Nachdem die Änderungen des Katalogs auf dem Knoten durchgeführt (oder im No-op mode nur simuliert) wurden, sendet der Agent einen kompletten Änderungsbericht zum Puppet Master zurück. Der generierte Bericht ist zur weiteren Verarbeitung über andere IT-Systeme über API vollständig erreichbar. Was sagen die Kritiker? Vor- und Nachteile von Puppet Vorteile Puppet rollt automatisch alle zentral auf dem Master bereitgestellten Konfigurations-Updates auf die Clients aus. Puppet sorgt für schlanke und wenig komplexe Konfigurationsdateien. So müssen z.b. die SSH-Keys und die Kerberos-Keytab nicht mehr explizit für jeden Rechner eingetragen werden. Auch die Unterscheidung zwischen 32 und 64-Bit entfällt. Puppet bietet die Möglichkeit der automatischen Überwachung von Diensten und gegebenenfalls deren Neustart nach Absturz. Puppet sorgt dafür, dass eine Installation nur einmalig gestartet werden muss. Alles weitere geschieht automatisch. Nachteile Die Möglichkeit manueller clientseitiger Anpassungen von Konfigurationen entfällt bzw. ist nur sehr schwer umsetzbar, da der Puppet Master die Änderungen immer wieder überschreibt. Somit gibt es nicht mehr die Möglichkeit, das Übliche gerade mal schnell zu testen. Dies kann aber auch als Vorteil gewertet werden.
Seite 7/7 Fazit Mit der zunehmenden Menge virtualisierter bzw. automatisiert installierter Systeme kann Puppet zu einem treuen Weggefährten bei der Verwaltung komplexer Prozesse im Configuration- und Change Management werden. Im Kontext unseres Fokus der Continuous Software Integration und Delivery in Enterprise-Umgebungen ist Puppet als eine neue Art der zentralisierten Konfigurationsverwaltung eine ernst zu nehmende Größe. Dies begründet sich hauptsächlich in der Möglichkeit, Anpassungen bezüglich Infrastruktur und Konfiguration in abgeschlossenen Testsystemen zu validieren und anschließend über Staging- und Produktionsumgebungen zu installieren. Dies fördert nicht nur die Transparenz zwischen Entwicklung und Betrieb, sondern kann durch die Einbindung in Virtualisierungslösungen in Enterprise-Umgebungen auch die Chancen von Puppet optimal nutzen. Als Produkt in unserer Newsletter-Reihe betrachtet, kann Puppet nicht den hier geforderten vollen Funktionsumfang der Testreihe bereitstellen, muss aber als Keyplayer im Kontext der Infrastruktur- und Konfigurationsverwaltungen, auch und gerade wegen seiner Position im Markt, berücksichtigt werden. Abschließend kann man sagen, dass Puppet definitiv ein mächtiges Tool im Werkzeugkasten jedes Build- und Deployment-Verantwortlichen sein sollte und aus dem Management großer heterogener Serverumgebungen nicht mehr wegzudenken ist. Impressum Datum: Juni 2013 Autor: Andreas Fränkle Kontakt: marketing@avato-consulting.com www.avato-consulting.com 2013 avato consulting