Puppentheater – Server Management leicht

news
Puppentheater – Server Management
leicht gemacht
... the smarter way of information
news
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.
Software-Integration
news
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.
Software-Integration
news
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
Webapplikation zu deployen, wird
eine Datenbank, ein Applikationserver und ein Webserver 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. „Nodes“) und die auf ihnen
installierten Komponenten (sog.
„Resources“) stehen in enger Bezie-
hung 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 Ressour-
ce 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 „Database
Server“ oder „Web 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.
Software-Integration
news
Seite 5/7
Die Statisten - wiederverwertbare Module
Module
Puppet geht davon aus, dass jede
Infrastruktur bezüglich ihrer Verwendung in Module geclustert und
an geeigneter Stelle wiederverwertet werden kann. Der entsprech­
ende Wunschzustand bzw. das
vordefinierte Modul einer Infrastrukturkomponente oder auch der
gesamten Infrastruktur kann entweder über Puppet Forge publiziert
oder nur einfach intern verwendet
werden.
Im vereinfachten Sinne sind Module wiederverwendbare Puppet-­
Code-Fragmente, die auch mit anderen Anwendern geteilt werden
Database
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
größeren Konfigurationen, die
komplette Applikations-Stacks (sog.
“Nodes“) repräsentieren, orchestriert werden.
Webserver
Appserver
Security
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
Web Servers
Web
server
Security
Node
Web
server
Node
Security
Database Servers
Web
server
Application Servers
Web
server
Security
Database
Database
App
server
Node
Node
Web
server
Security
Web
server
Security
Database
Database
App
server
Node
Node
Security
Software-Integration
news
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.
Software-Integration
news
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:
[email protected]
www.avato-consulting.com
© 2013 avato consulting
Software-Integration