Nach meinen ersten Posts bzgl. Icinga2 kamen mehrere Nachfragen, über meine puppet Konfiguration. Dem möchte ich mal kurz ein paar Zeilen widmen.

Puppet ist ein Konfigurationsmanagementsystem. Ähnlich wie Chef (das ehemalige puppet Entwickler initiiert haben) oder dem neuesten Hype: Ansible.
Puppet setzt auf eine Client-Server Struktur, wobei man ihn auch masterless betreiben kann. Das kommt vor allem dann zu tragen, wenn man seinen eigenen Puppetmaster sich selber provisionieren lässt.
Bei Puppet wird der SOLL-Zustand des Zielsystemes beschrieben, wie so ein puppet-Run dort hin kommt wird interne gelöst. Die abarbeitung der entsprechenden Module ist willkürlich. Man muss also in seinen eigenen puppet Modulen etwas Intelligenz für die Auflösung der Abhängigkeiten einarbeiten.

Ansible funktioniert da anders.
Dort beschreibt man den kompletten Weg mit allen seinen Einzelheiten.
Ich habe Ansible Playbooks gesehen, bei dem selbst der Ersteller nicht mehr auf Anhieb sah, was das alles macht. ;)

Bis ich meine – für mich funktionierende – Konfiguration hatte, habe ich mit Sicherheit 3-4 Mal von vorn begonnen.
Wenn man sich an neuen Sachen heran tastet ist es logisch, dass man Fehler macht. Man sollte nur aus diesen lernen!

Warum will man eigentlich ein Konfigurationsmanagementsystem nutzen?
Wenn man ein großes Setup bedienen muss, will man nicht alle Konfigurationsschritte per Hand durchführen.
Ich möchte eine Node an puppet hängen und dann passiert die Magie, es werden alle benötigten Services installiert, einheitlich konfiguriert und gestartet.
Es werden SSH-Keys ausgerollt und (ganz wichtig) syncron gehalten.
Verzeichnissstrukturen, Partitionstabellen, Cronjobs … je nach Umfang der Module hat man nach ca. 5 Minuten seinen gewollten Systemzustand.

In einem meiner größten vergangenen Projekte konnte ich dadurch eine Test-, Stage- und Produktivumgebung mit einem Volumen von ~150 Nodes in wenigen Stunden provisionieren.