Zend Server via Puppet konfigurieren
Kommentare

Puppet File-Struktur
Puppet ist eine Client-/Serverlösung. In unserem Beispiel betreiben wir Client und Server auf der gleichen Maschine. Erst am Schluss können wir als Probe aufs Exempel einen zweiten

Puppet File-Struktur

Puppet ist eine Client-/Serverlösung. In unserem Beispiel betreiben wir Client und Server auf der gleichen Maschine. Erst am Schluss können wir als Probe aufs Exempel einen zweiten Rechner mit der gleichen Konfiguration automatisch konfigurieren lassen. Default-mäßig sucht der Puppet-Server unter /etc/puppet nach seinen Manifesten. Dort legen wir jetzt zwei Verzeichnisse an:

/etc/puppet/manifests /etc/puppet/modules

In dem „modules“ Verzeichnis werden jetzt die einzelnen Konfigurationsmodule erstellt. Diese haben immer die gleiche Substruktur:

module_name/files module_name/manifests module_name/templates

In dem Verzeichnis „manifests“ legen wir lediglich die Datei site.pp ab. Unsere Startsituation sieht dann folgendermaßen aus:

/etc/puppet/manifests/site.pp /etc/modules

Das erste Modul (Zend Repository)

Listings gesucht?

Aus Platzgründen finden Sie die Listings zum Artikel bequem in einem ZIP-File zum Download zusammengefasst (.zip, 29kb).

Jetzt wollen wir als erstes Modul das Zend Repository einrichten. Dazu legen wir unter dem Verzeichnis /etc/puppet/modules ein neues Verzeichnis mit dem Namen zend_server_repo an. In diesem Verzeichnis legen wir die Standardmodulverzeichnisse /files, /manifests und /templates an. Im Verzeichnis /zend_server_repo/manifests starten wir dann mit der Datei init.pp unser erstes Manifest. Es hat den Inhalt aus Listing 1.

In diesem ersten Manifest werden zwei neue YUM Repositories angelegt. Jedes Repository benachrichtigt den unten erstellten clean-yum-cache-Befehl, der den YUM-Cache löscht, sobald sich etwas an den Repositories ändert. Hier werden vorbereitete Makros, so genannte Types von Puppet verwendet. Es gibt zu allen gängigen Administrationsaufgaben bereits fertige Types. Eine detaillierte Übersicht aller verfügbaren Types und deren Parameter findet man unter hier. Wem die bestehenden Types nicht reichen, der kann sich seine eigenen schreiben. Eine detaillierte Anleitung dazu gibt es unter diesem Link. Jetzt möchten wir unser neu erstelltes Modul natürlich gleich testen. Dafür muss nur noch die Datei site.pp in dem Verzeichnis /etc/puppet/manifests gefüllt werden (Listing 2).

site.pp ist der Einstiegspunkt von Puppet, das index.html. Hier werden Standardeinstellungen vorgenommen, die für die ganze Puppet-Umgebung gelten. In diesem Beispiel wird eine Basisklasse definiert. In dieser Basisklasse werden die Module definiert, die alle unter Puppet-Kontrolle stehenden Systeme erhalten sollen. Im Weiteren wird ein Default Node definiert, der die Basisklasse erhält. Außerdem können hier generelle Parameter, z. B. der zu verwendende Paketmanager pro Distribution gesetzt werden. Detaillierte Informationen und ein Best-Practice-Beispiel findet man hier.

Puppet übernimmt

Jetzt können wir unsere erste Konfiguration automatisch auf dem System durch Puppet applizieren lassen. Dazu müssen wir nur noch den Puppet Master als Daemon starten: service puppetmaster start. Um sicherzustellen, dass Puppet Master beim Systemstart immer läuft, tragen wir ihn in die Daemon-Tabelle ein: chkconfig puppetmaster on. Jetzt können wir den Puppet-Client im Testmodus starten und beobachten, was passiert. Dazu muss der Puppet-Server explizit angegeben werden, da der Puppet-Client Default-mäßig nach einem Puppet Master namens „puppet“ im Netz sucht. In unserem Beispiel arbeiten wir mit einem lokalen Puppet Master. Daher der folgende Aufruf:

Puppetd -t --server=localhost.localdomain

Achtung: immer den Full Qualified Domain Name FQDN verwenden, da Puppet die ganze Kommunikation aus Sicherheitsgründen via SSL verschlüsselt und auf gültige Zertifikate achtet. Wenn der Puppet Master und Puppet Client auf derselben Maschine laufen, ist dieses Zertifikat bereits ausgehandelt. Verbindet sich ein Puppet Client via Port 8140 auf einen anderen Puppet Master, so wird als Erstes ein SSL-Zertifikat angefordert, das auf dem Puppet Master mittels puppetca -sign FQDN signiert werden muss. So ist sichergestellt, dass keine unberechtigten Systeme sich sensible Konfigurationsdaten holen können (Kasten: Hinweis für Debian-/SUSE-Anwender).

Hinweis für Debian-/SUSE-Anwender

Die Installation und Konfiguration des Repository weicht von der hier beschriebenen Konfiguration für CentOS ab. Wie Zend Server CE installiert werden kann, entnehmen Sie dem entsprechenden Artikel in diesem Magazin. Die restliche Konfiguration sollte auf allen Systemen funktionieren, mit der Ausnahme, dass Servicenamen und/oder Paketnamen abweichen können. Diese Anleitung ist für CentOS/RHEL geschrieben und sollte unter der Fedora auch funktionieren.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -