Puppetserver als SaaS

Die GWDG bietet die Software Puppetserver als Software as a Service (SaaS) im offenen Testbetrieb an für interessierte Administratoren, die ihre Server mit Puppet verwalten möchten.

Was ist Puppet?

Puppet ist ein Werkzeug für Konfigurationsmanagement auf Servern („Nodes“). Dabei werden Konfigurationen (Installieren von Paketen und anderer Software, Einträge in Konfigurationsdateien sowie Starten und Stoppen von Diensten) in Skripten beschrieben und ein Agent auf den zu verwaltenden Nodes kümmert sich um die Umsetzung dieser Vorgaben.

Der Agent und das Skript können dabei Gegebenheiten der einzelnen Systeme dynamisch berücksichtigen (Größe des RAMs, Anzahl der Netzwerkkarten, Hostname, Art des Betriebssystems etc.) und so eine Konfiguration erstellen, die einerseits allgemeingültige Vorgaben umsetzt, andererseits diese individuell an den jeweiligen Node anpasst. Diese Vorgehensweise ist flexibler als eine statische Vorlage und hilft trotzdem dabei, grundsätzliche Vorgaben über mehrere unterschiedliche Systeme hinweg umzusetzen.

Was ist Puppet Server?

Puppet Server (früher Puppet Master) ist eine zentrale Komponente in der Verteilung von Konfigurationen. Puppet Server arbeitet mit dem Puppet Agent auf dem Node zusammen, indem er von diesem ein Profil des Nodes erhält (die „Facts“), damit eine angepasste Konfiguration („Catalog“) aus seinen Vorgaben (Puppet „Code“) für diesen Node erstellt und dem Agent zurück sendet, welcher dann die notwendigen Schritte durchführt, mit denen die aktuelle Konfiguration des Nodes dem Catalog angepasst wird.

Bei dem ersten Durchlauf des Catalogs können dies also viele Schritte sein, während bei folgenden Durchläufen meist keine Änderungen mehr notwendig sind. Nach einem Durchlauf erhält der Puppet Server einen Bericht über Zustand und ggf. durchgeführte Schritte des Agents auf dem Node („Report“). Erfolgen später Änderungen in dem Code, beginnt der Ablauf wieder von vorne, um die Konfiguration aller verwalteten Nodes wieder den neuen Vorgaben durch den Code anzugleichen.

Was bedeutet Software as a Service (SaaS)?

Bei einem SaaS-Angebot kann ein Kunde oder Benutzer eine eigene Instanz einer Software bei einem Anbieter erstellen oder erhalten, ohne jedoch die Systeme oder Infrastruktur dazu selber betreiben zu müssen. Dabei teilt sich die Software möglicherweise die Infrastruktur mit anderen Instanzen (Server und Speichersysteme), die Daten der Instanzen einzelner Benutzer sind aber voneinander getrennt.

Typischerweise kommt hierfür ein Selfservice zum Einsatz.

Anders als zum Beispiel bei der Einrichtung eines Email-Kontos, wo ein Konto zusätzlich zu vielen anderen auf einem Email-Server vorhanden ist, erhält der Benutzer bei einem SaaS-Angebot eine eigene, fertige Instanz der Software, also zum Beispiel einen eigenen Email-Server.

Was bietet Puppetserver als SaaS bei der GWDG?

Mit dem Angebot „Puppetserver“ steht Benutzern eine Installation eines Puppet Servers inklusive PuppetDB (mit PostgreSQL-Backend) und Puppetboard als Web-Frontend zur Verfügung. Dies entspricht im wesentlichen dem von Puppet.com empfohlenen Setup.

Die Verwaltung von Puppet Code erfolgt auf der Basis von Environments. Es erlaubt die Verwaltung von Nodes mit einem Puppet Server und bietet einen einfachen Überblick im Browser durch Puppetboard.

Wie ist der aktuelle Status des Dienstes bei der GWDG?

Puppetserver wird seit etwa einem halben Jahr für einige produktive Dienste bei der GWDG und SUB eingesetzt. Um mehr Erfahrung in der Breite zu sammeln, wird Puppetserver als SaaS nun im offenen Testbetrieb allen interessierten Administratoren oder Puppet-Neugierigen mit einem GWDG-Account angeboten.

Wie wird Puppetserver verwendet?

Voraussetzungen

Die zu verwaltenden Server („Nodes“) sollten Puppet Agent installiert haben und sich im GÖNET befinden.

Für die Verwaltung des Puppet Codes empfiehlt sich ein Versionskontrollsystem, zum Beispiel der GitLab-Service der GWDG. Hier sollte ein Projekt für die zu verwaltende Konfiguration (zum Beispiel für einen Dienst bestehend aus mehreren Servern) erstellt werden. Der GitLab-Service bietet darüber hinaus noch weitere Funktionen, wie z.B. ein Wiki für Dokumentation und ein Ticketsystem für Issue- und Milestone-Verwaltung, die die Arbeit mit Puppet Code sinnvoll ergänzen.

Instanz erstellen

Als nächstes sollte über den Selfservice auf www.gwdg.de eine Instanz erstellt werden, mit der dann die Nodes auch tatsächlich verwaltet werden können. Ist die Instanz erstellt, erhält der Benutzer eine Email mit den Zugangsinformationen für das Puppetboard (Visualisierung der PuppetDB), dem Puppetserver-Port (für Anfragen des Puppet Agents) und den SSH-Zugang (für die Bereitstellung des Puppet Codes und Zertifikatsverwaltung der Nodes).

SSH-Zugang, Environments und Puppet Code

Damit der Puppet Server eine Konfiguration für Nodes erstellen kann, wird Puppet Code benötigt, der eine Konfiguration beschreibt. Dieser wird per SSH (z.B. mit git clone aus einem Git-Repository) auf den Puppet Server herunter geladen oder per SFTP hochgeladen. Zunächst sollten aber der SSH-Zugang getestet und SSH-Schlüssel auf den Host übertragen bzw. in der ~/.ssh/authorized_keys hinterlegt werden und das erstmalige Passwort des Benutzers geändert werden.

Ist man per SSH mit dem Puppet Server verbunden, finden sich unter ~/code/environments/ die vorhandenen Environments, bei einer neuen Instanz nur das leere Environment production. Hier wird nun ein neues Environment angelegt und der vorhandenen Puppet Code z.B. per git clone aus einem Git-Repository abgelegt.

Puppet Agents mit Puppet Server verbinden

Die Puppet Agents auf den zu verwaltenden Nodes authentifizieren sich mit einem Zertifikat, welches von dem Puppet Server signiert wurde. Ein Key und ein Certificate Signing Request wird von jedem Agent bei seiner Installation erstellt. Damit der richtige Puppet Server kontaktiert wird, muss dieser in der Konfiguration des Agents auf dem Node in /etc/puppet/puppet.conf in dem Abschnitt [agent] oder [main] hinterlegt werden. Hier wird auch das Environment konfiguriert, welches der Agent anfragen soll. Die Optionen dafür sind: environment, masterport und server. Ein Beispiel:

[agent]
environment = bio_webserver_gwdg
server = puppetserver.gwdg.de
masterport = 10264

Nun kann der Agent mit puppet agent -t das erste Mal mit dem Server Kontakt aufnehmen. Dabei wird der Certificate Signing Request übermittelt. Eine Konfiguration wird dabei noch nicht erstellt und umgesetzt. Dies erfolgt erst ab dem zweiten Kontakt und nur, wenn der Certificate Signing Request vom Puppet Server bestätigt wurde. Dies ist dann der nächste Schritt.

Auf dem Puppet Server werden nun mit sudo /opt/puppetlabs/bin/puppet cert list die noch ausstehenden Certificate Signing Requests aufgelistet. Hier sollte der eine, neue Node erscheinen. Mit sudo /opt/puppetlabs/bin/puppet cert sign <my_node> wird der Request signiert. Auf dem Node wird mit puppet agent -t nun der Puppet Server erneut kontaktiert, der Agent sollte den Empfang des Zertifikats bestätigen. Ab diesem Zeitpunkt wird der Agent gemäß Standardkonfiguration jede halbe Stunde den Server kontaktieren, seine Facts übermitteln, einen Catalog erhalten, ggf. Schritte durchführen und den Report an den Puppet Server übermitteln.

Puppetboard

Hat mindestens ein Agent schon seine Facts und Reports abgeliefert, werden für den Node und seine Facts Einträge in der PuppetDB erzeugt. Diese sind dann im Puppetboard sichtbar und können über die URL in der Einrichtungsemail angezeigt werden. Das Puppetboard ist eine Nur-lesen Schnittstelle, bietet aber eine gute Übersicht über die vorhandenen Nodes und deren Facts und Reports.

Was bedeutet "offener Testbetrieb" für den praktischen Einsatz?

Warum ein Testbetrieb?

Ein Dienst und seine Software werden zunächst durch die Betreuer getestet oder evaluiert, bevor sie in das Angebot der GWDG aufgenommen werden. Um aber aussagekräftige Erfahrungen mit einem Dienst für einen langfristigen Betrieb zu sammeln, muss dieser oft erst unter realen Bedingungen beobachtet werden, also während er von Benutzern für tatsächliche Aufgaben verwendet wird.

Hierfür ist der Testbetrieb da. Ein Start im Testbetrieb bedeutet, dass der erste Eindruck des Dienstes gut war und ein Betriebskonzept geschaffen wurde, welches für den längerfristigen Einsatz geeignet sein soll, aber noch Erfahrungen unter realen Bedingungen fehlen. Dafür und für Rückmeldungen von Benutzern wird der Dienst im Testbetrieb, ggfs. mit Einschränkungen und Besonderheiten, die im Normalbetrieb nicht vorkommen, gestartet.

Wie lange dauert der Testbetrieb? Was kommt danach?

Die GWDG wird den Dienst Puppetserver bis auf weiteres im offenen Testbetrieb anbieten, sofern keine schwerwiegenden Gründe dagegen sprechen. Als schwerwiegende Gründe würden vor allem unerwartet aufgetretene Fehler in der Software gelten, die die Sicherheit der verwalteten Daten gefährden, oder eine übermäßige Instabilität des Dienstes.

Die Aufnahme in das reguläre Angebot der GWDG hängt ab von der Annahme und Nutzung des Dienstes sowie den Erfahrung damit im Betrieb.

Die Entscheidung wird wesentlich davon abhängen, wie der Dienst angenommen wurde bzw. die Rückmeldungen dazu ausfielen, wie hoch der betriebliche Aufwand war und in welchem Verhältnis dieser zu dem erwarteten Nutzen steht.

Was passiert mit meinen Daten, wenn der Dienst eingestellt werden sollte? Was ist das Risiko?

Sollte die Entscheidung getroffen werden, den Dienst nicht über den Testbetrieb hinaus zu betreiben, wird darüber rechtzeitig informiert. Zusätzlich erhalten Benutzer Unterstützung beim Exportieren ihrer Daten aus dem Dienst.

Sollte sich für Projekte oder Einrichtungen der Dienst als so nützlich erwiesen haben, dass darauf nicht verzichtet werden soll, kann die GWDG Unterstützung beim Betrieb einer eigenen, selbst verwalteten Instanz für diesen Benutzerkreis anbieten. Da sich die zugrundeliegende Software und Konfiguration in einem öffentlichen Repository der GWDG befinden, ist der Betrieb einer eigenen Instanz vergleichsweise einfach.

Die unterschiedlichen Szenarien werden von uns berücksichtigt und damit das Risiko für den Einsatz des Dienstes bereits in der Testphase gering gehalten.

Welche Unterschiede gibt es im Testbetrieb im Vergleich zu einem Normalbetrieb?

Da, wie oben beschrieben, die Langzeiterfahrung mit dem Dienst noch fehlt, besteht noch keine letztendliche Gewissheit über die dauerhafte Tauglichkeit des Dienstes für einen breiten Einsatz. Bestünden hier aber bereits Zweifel, würde der Dienst nicht allen Benutzern in einem offenen Testbetrieb angeboten werden.

Aufgrund der noch unvollständigen Betriebserfahrungen und aufgrund weiterer Anpassungen des Dienstes im Testbetrieb kann es leider zu häufigeren kürzeren Unterbrechungen im Betrieb kommen, als dies bei anderen Diensten im Normalbetrieb der Fall ist. Dies soll aber soweit wie möglich vermieden werden. Angestrebt wird der gleiche, zuverlässige Betrieb wie bei anderen Diensten im Normalbetrieb auch.