foreman_small

Ein schönes, aber selten gewürdigtes Feature von Puppet sind wohl die sogenannten exported resources.

In einem Standard Setup mit Foreman funktionieren diese Resources jedoch nicht, ich möchte heute zeigen wie das zusammen mit der PuppetDB recht einfach umsetzbar ist.

Aber was tut das?

Mit exportierten Resourcen können Resourcen aus der einzelnen Node Konfiguration herausgehoben, und auf allen Nodes verwendet werden.

Hier ein kleines Beispiel, bzw. eigentlich das Standardbeispiel.

@@sshkey { $::fqdn:
  type         => rsa,
  key          => $::sshrsakey,
  host_aliases => [ $::hostname, $::ipaddress ],
}

Die Resource SSH-Key kümmert sich hierbei darum, den Key auf Basis eines Facts in die Datei /etc/ssh/ssh_known_hosts einzupflegen.

Grundsätzlich würde die Resource aber nur für den gleichen Node gültig sein, dies ändert das Prefix “@@” vor dem Resourcentyp, er macht die Resource exportierbar.

Um die exportierten Resourcen nun auch zu benutzen muss noch folgender Puppetcode ergänzt werden:

Sshkey <<| |>>

Dieser Collector sorgt dafür dass die Resourcen dieses Typs verwendet werden.

Es gibt noch ein paar Tricks mit Tags um unterschiedliche Bereiche dieser Resourcen zu unterscheiden und aufzuteilen, hierzu empfehle ich die Dokumentation zu Tags und Kollektoren zu lesen.

Wie funktioniert die Speicherung?

Die Speicherung dieser exportierten Resourcen funktioniert über die sogenannte “stored configuration”. Dabei werden die exportierten Resourcen in einen zentralen Speicher geschrieben, und immer beim Katalog-Lauf aktualisiert (für den Knoten der die Resourcen exportiert). Dieser Speicher wird dann ebenfalls abgefragt um alle exportierten Resourcen einzusammeln und in anderen Nodes zu verwenden.

Die PuppetDB ist ein zusätzlicher Java Dienst, der für den Puppet Master eine API zur Speicherung von storedconfigs und Reports zur Verfügung stellt.

Dabei nutzt die PuppetDB eine kleine mitgebrachte Datenbank, oder ein echtes RDBMS System. Empfohlen ist eine echte Datenbank zu nutzen, wie z.B. PostgreSQL, da dadurch Performance Engpässe vermieden werden.

Wie binde ich das in Foreman ein?

Grundsätzlich hat die PuppetDB wenig mit Foreman zu tun, man muss nur dafür sorgen dass der Puppet Master entsprechend konfiguriert ist, und sich die beiden Puppet Module nicht in die Haare kriegen.

Wir verwenden hier die Module foreman-puppet und puppetlabs-puppetdb. Natürlich kann, und ggf. auch sollte, man diese Module über Foreman konfigurieren.

class { 'puppet':
  # hier muss ggf. noch ihre Konfiguration
  # aus dem foreman-installer übernomen werden
  server_storeconfigs_backend => 'puppetdb',
}

include puppetdb   # installiert und konfiguriert die PuppetDB
                   # standardmäßig wird dabei eine PostgreSQL
                   # Datenbank, wie auch für Foreman verwendet

# Konfiguriert den Puppet Master (teilweise)
class { 'puppetdb::master::config':
  manage_storeconfigs => false,    # verhindert dass die puppet.conf
                                   # gemanaged wird
  restart_puppet      => false,    # deaktiviert die verwendung des
                                   # puppetmaster Dienstes mit Foreman
                                   # läuft dieser ja im Apache
}

Je nachdem ob Sie die Konfiguration in einem eigenen Modul machen, oder einfach in Foreman, muss der Apache Server ggf. neugestartet werden, sonst fehlt dem Puppet Master die aktualisierte Konfiguration.

Was sollte man noch beachten?

Ein wichtiges Thema ist die Löschung bzw. Deaktivierung von Nodes die nicht mehr existieren – oder auch nur umbenannt werden. Diese verschwinden nämlich nicht automatisch aus der Datenbank.

Es gibt ein Plugin for Foreman, dass die deaktivierung übernimmt, sobald ein Host gelöscht wird.

Alternativ kann man diese Deaktivierung auch von Hand machen:

puppet node deactivate myhost.mycompany.com

 

Ich wünsche viel Spaß beim ausprobieren!

Markus Frosch

Autor: Markus Frosch

Markus arbeitet bei NETWAYS als Principal Consultant und unterstützt Kunden bei der Implementierung von Nagios, Icinga und anderen Open Source Systems Management Tools. Neben seiner beruflichen Tätigkeit ist Markus aktiver Mitarbeiter im Debian Projekt.