Puppet ist sehr mächtig und so gut wie grenzenlos erweiterbar. Im Zusammenhang mit Icinga tritt dann früher oder später die Frage auf ob sich diese beiden „Welten“ auch miteinander vereinen lassen. Die Antwort darauf ist kurz: „Ja!“.
Der Teufel steckt hier natürlich im Detail. Über die sog. Hauptresourcen bietet Puppet in der Standardinstallation bereits vielfältige Möglichkeiten zur Verwaltung von Monitoringlösungen an. So lassen sich schon mit „file“, „package“, „service“ u.a. sehr viele Anwendungszwecke abdecken. Für das Konfigurationsmanagement von Icinga geht das mit zusätzlichen Resourcen wie z.B. „nagios_host“ oder „nagios_service“ aber noch durchaus eleganter, die Zauberformel heißt hier: Exported Resources.
Mit Exported Resources ist es unter Puppet möglich gesammelte Daten von bestimmten Nodes auf anderen Nodes auszugeben, also dort zu exportieren. Das bedeutet das definierte Daten von bestimmten Hosts, wie z.B. die IP-Adresse, durch den Puppetmaster in einer zentralen Datenbank (PuppetDB) gespeichert werden und auf anderen Hosts gesammelt weiterverarbeitet werden können.
Hier ein Beispiel eines Puppetcodes wie das Einsammeln von Daten zum Erstellen der Icinga-Hostkonfiguration aussehen könnte:
@@nagios_host { "$fqdn":
ensure => "present",
alias => "$hostname",
address => "$ipaddress",
max_check_attempts => "3",
use => "generic-host",
}
Wenn einem Node diese exportierte Resource zugewiesen ist, werden die darin enthaltenen Variablen beim Puppetlauf durch hostspezifische Inhalte (sog. Facts) ersetzt und in der zentralen Datenbank des Puppetmasters abgespeichert. In diesem Fall sind das also Full Qualified Domain Name ($fqdn), Hostname ($hostname) und die primäre IP-Adresse ($ipaddress).
Der folgende Puppetcode sorgt dann dafür das die zuvor gesammelten Daten in einer gemeinsamen Konfigurationsdatei auf dem Icingamaster ausgegeben werden:
Nagios_host <<| |>>
Der Eintrag in der Konfigurationsdatei auf dem Icingamaster würde unter Verwendung des vorhergehenden Codes dann für einen Host nach dem Export beispielhaft so aussehen:
define host {
host_name puppetclient01.localdomain
address 192.168.56.11
use generic-host
max_check_attempts 3
alias puppetclient01
}
Natürlich können neben Hosts im Zusammenhang mit Icinga noch weitere Resourcen für Services, Kontakte, Kontaktgruppen, uvm. verwendet werden. Auch bieten die einzelnen Resourcen viele andere Parameter für das Feintuning an. Mit Puppet-Bordmitteln ist es außerdem möglich Berechtigungen und Abhängigkeiten zu steuern, sodass z.B. der Eintrag zum Laden der neuen Konfigurationsdatei in die „icinga.cfg“ automatisch erfolgt und auch der Icinga-Dienst im Anschluss von alleine neu geladen wird.
0 Kommentare