Problematische Services mit dem Open Source Tool Puppet verwalten

Puppet ist ein Open Source Configuration Management Tool und eignet sich sowohl für einzelne Rechner als auch für große Rechnerverbünde. Das Tool existiert seit 2005 und wird von der Firma Puppet Labs entwickelt, die zu diesem Zweck gegründet wurde. 

Wird ein Service über Puppet in Betrieb genommen, so besteht der Ablauf üblicherweise aus drei Schritten:

  1. Installation der notwendigen Pakete
  2. Konfiguration durch Templates oder file-Ressourcen
  3. (Neu-)Starten des Dienstes

Ändert sich an den verteilten Konfigurationsdaten etwas, so soll Puppet den Dienst neu laden oder neu starten lassen um die Änderungen zu übernehmen.

Soweit so gut, aber was tun wenn das init-Script unvollständig ist und nicht angepasst werden kann oder der Dienst nicht z.B. per PID File oder besser per Controlsocket eine Statusabfrage ermöglicht? In diesen Fällen hat der Puppet Agent keine Möglichkeit zu erkennen ob der Service läuft, was je nach Implementierung dazu führen kann, daß bei jedem Run der Dienst versucht wird zu starten obwohl er läuft (und er damit im schlimmsten Fall mehrfach läuft) oder ohne Grund restarted.
Beide Fälle sind unschön, lassen sich aber vermeiden, selbst wenn man keine Möglichkeit hat der Applikation eine Statusabfrage beizubringen.

Wie erkennt Puppet ob ein Service gestartet ist?

Vorweg aber die Frage – wie erkennt Puppet bei „sauberen“ init-Scripten ob der gewählte Service gestartet ist? In dem der Return Code bei der status Direktive ausgewertet wird. RC=0 wird dabei als „OK“ interpretiert, alle anderen möglichen Return Codes als „nicht OK“.

Läuft der Service nicht, wird laut LSB ein RC=3 vorgeschrieben.

Fehlt die status Direktive, so kann dieser Workflow prinzip-bedingt nicht funktionieren. Hier kommt die Kreativität des Einzelnen ins Spiel, denn jede Applikation ist anders gestrickt und muß daher auch individuell behandelt werden.

Recycling lebt vom Mitmachen!

Für solche schwierigen Fälle bietet Puppet die Möglichkeit das Verhalten des Agents zu überschreiben und eine eigene Methode zur Erkennung zu konfigurieren. Hier kommen die Monitoring Plugins ins Spiel, denn glücklicherweise sind die Return Codes von Nagios Plugins mit LSB konformen init-Scripten kompatibel.
RC=0 bedeutet in beiden Welten „OK“, RC=3 ist im Nagios Universum als „UNKNOWN“ definiert, was für diesen speziellen Fall aber getrost ignoriert werden kann, da Puppet alle Return Codes ungleich null als Fehler interpretiert, egal ob RC=2 oder RC=3.

Sollte das nagios-plugins Paket noch nicht für den Node definiert sein, empfehle ich folgende Definition:

Mit diesem Manifest Snippet wird package['nagios-plugins'] nur dann in den Katalog aufgenommen, wenn an keiner anderen Stelle (z.B. in anderen Modulen) bereits eine solche Definition vorhanden ist. Auf diese Weise ist sicher gestellt, daß sich keine Mehrfachnennungen im Katalog befinden, was bekanntlich zu einem Fehler führen würde.

Schlußendlich muß die Definition des Dienstes noch angepasst werden, der relevante Anteil ist hierbei hasstatus => false und die individuell anzupassende Zeile status.

Mehr zu Puppet finden Sie auf der Seite der Entwickler Puppet Labs: http://puppetlabs.com/puppet/what-is-puppet
Wenn Sie Hilfe mit Puppet brauchen wenden Sie sich gerne an jemanden von teamix: http://www.teamix.de/kontakt/kontakt.html

Sebastian Laubscher

Sebastian arbeitet seit Sommer 2013 für teamix als Senior Consultant und Trainer. Seine Kompetenzen liegen in den Bereichen Netzwerktechnik und Unix-/Linux Administration, speziell im Bereich der Automatisierung mit Puppet. Vor der Zeit bei teamix war er für einen großen deutschen ISP tätig.

 
Kommentare

Noch keine Kommentare vorhanden.

Hinterlassen Sie einen Kommentar

Time limit is exhausted. Please reload CAPTCHA.