Puppet erhebt den Anspruch, die nächste Generation an Konfigurationswerkzeugen zu repräsentieren. Es bietet eine Sprache, um Konfigurationen unabhängig vom verwendeten Betriebssystem zu beschreiben.

© elgris, fotolia.com

Mit anderen Konfigurationswerkzeugen war der Hauptentwickler von Puppet, Luke Kanies, unzufrieden [1]. Die meisten erlaubten es ihm nicht, die Unterschiede mehrerer Paketformate und Betriebssysteme zu kaschieren. Sein in Ruby [2] komplett neu entwickeltes Puppet sollte folglich verwandte Konzepte abstrahieren und sie transparent für den Systemverwalter im Hintergrund passend für die entsprechende Plattform implementieren. Davon erhofften sich Kanies und die Puppet-Entwickler bessere Portabilität und größeren Austausch von Anwender-Modulen.

Die Bühne zimmern

Puppet eignet sich sowohl für einzelne Rechner als auch für große Rechnerverbünde. Wer nur einen Rechner verwaltet, ruft Puppet dort von der Kommandozeile aus auf. Administratoren größerer Rechnerparks betreiben Puppet im Client-Server-Modus. Der einfach einzurichtende Austausch nutzt ein eigenes, SSL-gesichertes Protokoll. Ein zentraler Host verteilt die Konfigurationen und nimmt die Berichte seiner Clients entgegen.

Diverse Distributionen bieten die Software als Paket an, aktuell und stabil ist die Version 0.24.5. Da es unter dem hier benutzten Gentoo als instabil gekennzeichnet ist, schalteten die Tester es gemeinsam mit dem abhängigen Facter-Paket mit

( echo "dev-ruby/facter ~x86"; echo "app-admin/puppet ~x86" ) >> /etc/portage/package.keywords

frei und installierten es mit »emerge puppet«. Die meisten anderen Distributionen wie Fedora, Open Suse oder Debian nennen das Paket einfach »puppet«. Es gibt auch ein Ruby-Gem.

Der Konfigurationsmanager möchte konfiguriert sein. In »/etc/puppet/puppet.conf« trägt der Systemverwalter Verzeichnispfade ein, die nicht fehlen dürfen (siehe Listing 1). Im »vardir« legt Puppet Backupdateien an, Logdateien landen im »logdir« und das »rundir« enthält die PID-Information des laufenden Puppet-Masterprozesses und des Puppet-Clients.

01 [main]
02   confdir     = /etc/puppet
03   vardir      = /var/lib/puppet
04   logdir      = /var/log/puppet
05   rundir      = /var/run/puppet
06   modulepath  = $confdir/modules
07   manifestdir = $confdir/manifests

Der erste Akt

Will der Admin Konfig-Spezifikationen in Modulen gruppieren, müssen die Direktive »modulepath« und das zugehörige Verzeichnis vorhanden sein. Die Pfade entsprechen der Konfiguration unter Gentoo und können auf anderen Systemen leicht abweichen. Weitere Konfigurationsvariablen und ihre Standardwerte finden Anwender im Wiki [3].

Manifeste nennt Puppet seine Steuerdateien für die Konfigurationen eines Dienstes oder eines Pakets. Das Tool verwendet dazu die Endung ».pp«. Kürzere Manifeste sammelt der Admin typischerweise im »manifestdir«, komplexere legt er als Module im »modulepath« ab.

Als zentrales Manifest dient standardmäßig die Datei »site.pp«. Wer Puppet von der Kommandozeile aus aufruft, gibt den Dateinamen explizit im Kommando »puppet site.pp« an. Listing 2 enthält ein unvermeidliches "Hello World", das nichts konfiguriert. Abbildung 1 zeigt, dass Puppet in der Ausgabe den Funktionsnamen (»notice«), den Node »default« als Kontext (»Scope(Node[default])«) und schließlich den angegebenen Text »Hello world!« ausgibt.

Abbildung 1: Manuell aufgerufen arbeitet Puppet das Standard-Manifest »site.pp« aus Listing 1 ab und meldet sich mit einem Gruß.

Das Listing gibt schon Aufschluss über den Aufbau von Manifesten: Es deklariert in Zeile 1 einen »node«, das Puppet-Synonym für einen einzelnen Rechner. Hier stehen Hostnamen, für die die Inhalte in geschweiften Klammern gelten. Puppet ermittelt beim Start automatisch den Namen des Rechners, um so den passenden Node zu bestimmen und die darin festgelegte Konfiguration umzusetzen. Die Einstellungen des Node mit dem Bezeichner »default« greifen dann, wenn Puppet keinen anderen passenden Node findet. Es ist nun am Administrator, Spezifikationen niederzulegen.

Das Beispiel in Listing 3 konfiguriert einen OpenSSH-Server. Da die Spezifikation autark von der restlichen Systemkonfiguration ist, bietet es sich an, sie in ein eigenständiges Modul auszulagern. Das umfasst mindestens ein Manifest für einen Dienst, darf aber auch Konfigurationsdateien oder -templates mitbringen. Komplexere Module stellen in Ruby geschriebene Plugins bereit und erweitern Puppet damit.

01 node default {
02   notice('Hello world!')
03 }

01 class openssh {
02 
03   package {openssh:
04     ensure => 'installed'
05   }
06 
07   user {sshd:
08     home => '/var/empty',
09     shell => '/sbin/nologin',
10     require => Package['openssh'];
11   }
12 
13   file {'/etc/ssh':
14     ensure => directory,
15     mode => 0755,
16     owner => root, group => root,
17     require => Package['openssh'];
18 
19         '/etc/ssh/sshd_config':
20     source =>'puppet:///openssh/sshd_config',
21     mode => 0600,
22     owner => root, group => root,
23     notify => Service[sshd],
24     require => File['/etc/ssh'];
25   }
26 
27   service {sshd:
28     ensure => running,
29     require => [Package['openssh'],
30                 File['/etc/ssh/sshd_config'],
31                 User[sshd]],
32     subscribe => User[sshd]
33   }

Sie können diesen Artikel als PDF für 99 Cent kaufen. Klicken Sie dazu einfach auf eine der beiden Bezahloptionen Paypal oder ClickandBuy.

Puppet erhebt den Anspruch, die nächste Generation an Konfigurationswerkzeugen zu repräsentieren. Es bietet eine Sprache, um Konfigurationen unabhängig vom verwendeten Betriebssystem zu beschreiben.