Klassen definieren

Auch Klassen unterstützen Vererbung, die sich allerdings etwas flexibler handhaben lässt als die Vererbung von Node-Typen. Damit ist es zum Beispiel möglich, eine von der Apache-Klasse abgeleitete Klasse zu definieren, die den Server stoppt und aus den Start-Diensten entfernt. Die abgeleitete Klasse übernimmt die Vorgaben der ursprünglichen Klasse, überschreibt aber nach Bedarf einzelne Attribute, um das Verhalten zu ändern. Ein Beispiel ist im folgenden Listing zu sehen. Der erste Abschnitt definiert die abgeleitete Klasse, die den Apache-Dienst stoppt und dauerhaft abschaltet. Der zweite Abschnitt ist dann eine Node-Definition, die diese Klasse verwendet:

class apache::disabled inherits apache
{Service[‘apache2’]
         { ensure =>
stopped, enable => false }
}

node ‘node5.cloud.net’ {include apache::disabled
}

 Alternativ zu Klassen bietet Puppet noch Defined Types an, die bei Anwendungen helfen, für die Klassen zu beschränkt sind. Klassen sind sogenannte Singletons, können also nur in einer einzigen Ausführung existieren. Wer aber zum Beispiel virtuelle Hosts definieren möchte, braucht Ressource-Definitionen, die je nach VHost unterschiedliche Werte enthalten. Dies lässt sich mit Defined Types umsetzen.

 Statt ein Modul wie das hier vorgeführte Apache-Modul selbst zu entwickeln, sollten Sie einen Blick auf Puppet Forge [1] werfen, wo es eine Vielzahl fertiger Module für gängige Server-Komponenten wie Apache, Postfix, Firewalls und so weiter gibt. Sie lassen sich auf der Kommandozeile leicht mit puppet module install aufrufen. Allerdings empfiehlt es sich hierbei, den Modul-Pfad mit “--modulepath” anzugeben, weil dieser davon abhängt, mit welcher Benutzer-ID das Programm aufgerufen wird. So können Sie die Third-Party-Module in “/usr/share/puppet/modules” speichern und Ihre eigenen in “/etc/puppet/modules”.

Bild 4: Das Puppet-Dashboard bietet eine webbasierte Ansicht der verwalteten Rechner und Konfigurations-Jobs

Testen und kontrollieren

Um komplexe Konfigurationen in den Griff zu bekommen, bieten sich Tests an, die Sie leicht in virtualisierten Umgebungen durchführen können. Wer eine dynamische Infrastruktur verwaltet, in der es viele Änderungen an der Server-Konfiguration gibt, sollte außerdem die Puppet-Dateien mit einem Versionskontrollsystem wie Git oder Mercurial verwalten. Darüber hinaus enthält die Puppet-Konfiguration in Ubuntu von Haus aus Hooks für die Software Etckeeper, die vor und nach der Ausführung von Puppet ablaufen und die Dateien im Verzeichnis /etc mit einem Versionskontrollsystem managen. Dies geschieht automatisch, wenn etckeeper installiert ist.

 Die Meldungen von Puppet sind auf Mastern und Clients normalerweise im Syslog des Systems zu finden. Wenn Sie das ändern möchten, passen Sie die Logging Facility mit der Einstellung “syslogfacility” in puppet.conf an und richten Sie den Syslog- oder Rsyslog-Daemon entsprechend ein. Alternativ übergeben Sie dem Puppet Master oder Agent beim Start die Option “--logdest=Logdatei”. Hier können Sie auch die oben beschriebenen Schalter “--verbose” und “--debug” zur Fehlersuche platzieren. Bei Ubuntu fügen Sie diese Einstellungen in die Upstart-Datei /etc/ init.d/puppet beziehungsweise /etc/init.d/puppetmaster ein, wie es das folgende Listing zeigt:

LOG_DEST=/var/log/puppet/agent.log
DAEMON_OPTS=”--logdest=${LOG_DEST} --verbose
--debug”

 Über das konventionelle Logging hinaus gibt es noch die Möglichkeit, mit einem webbasierten Dashboard den Überblick über alle Puppet-Agenten zu behalten. Es ist im Sourcecode unter [2] zu finden und relativ einfach zu installieren, wenn man der Anleitung folgt. Dann zeigt es im Browser übersichtlich die verwalteten Nodes sowie erfolgreiche und fehlgeschlagene Versuche der Konfiguration an (Bild 4).