Puppet wird verwendet, um mehrere routinemäßige Sysadmin-Konfigurationsaufgaben zu automatisieren.
Puppet in einem Konfigurationsmanagementsystem der Enterprise-Klasse.
Damit können Sie den Zustand Ihrer IT-Infrastruktur definieren. Einmal definiert, erzwingt Puppet fortlaufend automatisch den korrekten Status.
1. Puppenarchitektur
Puppet hat normalerweise eine Serverkomponente und mehrere Agenten. Sie müssen einen Server in Ihrem Netzwerk als Puppet-Master festlegen, und auf jedem Knoten in Ihrem Netzwerk wird ein Puppet-Agent installiert.
Die gebräuchlichste Art, eine Puppet-Konfiguration auf einen Client anzuwenden, ist die Verwendung des Puppet-Master-Daemons (puppetmasterd) und des Puppet-Client-Daemons (puppetd). Sie können die Manifeste auch manuell mit dem Puppet-Tool anwenden.
Die Konfiguration wird auf dem Puppet-Master definiert, kompiliert und dann automatisch an die Puppet-Clients übertragen, wenn sie sich verbinden.
Puppet unterstützt eine Vielzahl unterschiedlicher Plattformen und Betriebssysteme und führt automatisch die entsprechenden Befehle aus, um Ihr Manifest in jeder Umgebung anzuwenden.
Ein Manifest ist nichts anderes als Details zu Dateien, Paketen und Konfigurationsvorgängen, die in einer Sprache geschrieben sind, die Puppet verstehen kann.
Jeder Puppet-Knoten kontaktiert den Puppet-Master standardmäßig alle 30 Minuten, um zu bestätigen, dass seine Konfiguration auf dem neuesten Stand ist. Wenn die Konfiguration anders ist oder eine neue Konfiguration verfügbar ist, wird sie neu kompiliert und dann auf den Puppet-Knoten angewendet.
In diesem Tutorial erklären wir, wie Sie einige grundlegende Manifeste erstellen und mit dem Puppet-Tool auf die Clients anwenden.
Der größte Teil der Systemkonfiguration kann mit dem Puppet-Befehlszeilentool angezeigt werden. Alle Konfigurationskomponenten sind in Ressourcen organisiert. Die Ressourcen sind in Sammlungen gruppiert. Ressourcen bestehen aus Typ, Titel und einer Reihe von Attributen.
2. Beispiel einer Puppet-Ressourcendatei
Im Folgenden finden Sie ein einfaches Beispiel zum Anzeigen einer Puppet-Ressource. In diesem Fall ist die angezeigte Puppet-Ressource eine Datei (/etc/nsswitch).
# puppet resource file /etc/nsswitch.conf
file { '/etc/nsswitch.conf':
ensure => 'file',
content => '{md5}0d6009cdfd12646d251e86303bc0c48c',
ctime => 'Sun May 18 13:20:02 -0400 2014',
group => '0',
mode => '644',
mtime => 'Tue May 04 15:22:21 -0400 2010',
owner => '0',
selrange => 's0',
selrole => 'object_r',
seltype => 'etc_t',
seluser => 'system_u',
type => 'file',
}
Puppet wird standardmäßig mit einer Reihe von Ressourcentypen geliefert, darunter unter anderem Typen zum Verwalten von Dateien, Diensten, Paketen, Cron-Jobs und Dateisystemen.
Im obigen Beispiel ist file der Ressourcentyp und /etc/nsswitch.conf der Titel der zu verwaltenden Ressource.
Alles andere sind Attribute des Ressourcentyps und Werte, die in den Attributen vorhanden sind. Sie können Puppet auch erweitern, um Ihre eigenen Ressourcentypen hinzuzufügen.
Verwenden Sie den folgenden Befehl, um alle verfügbaren Ressourcentypen anzuzeigen:
# puppet resource --types augeas computer cron exec file filebucket group host nagios_hostdepend .. ..
3. Beispiel einer Puppet-Manifestdatei
Sehen wir uns an, wie Sie eine einfache Manifestdatei erstellen und den Puppet-Befehl ausführen, um die Konfiguration auf den Server anzuwenden.
Das folgende Beispiel erstellt eine einfache Manifestdatei site.pp im Verzeichnis /etc/puppet/manifests, die eine Testdatei unter /var/tmp erstellt.
Wie wir unten sehen, haben wir zunächst keine Testdatei.
# ls -ld /var/tmp/testfile ls: cannot access /var/tmp/testfile: No such file or directory
Das Folgende ist die Ressourcendeklaration in der Manifestdatei (site.pp):
# cat site.pp
file { "/var/tmp/testfile":
ensure => "present",
owner => "root",
group => "root",
mode => "664",
content => "This is a test file created using puppet.
Puppet is really cool",
}
Zu Demozwecken führen wir den Puppet Master und den Agenten auf demselben Knoten aus.
Wenn Sie den Befehl puppet apply zum ersten Mal mit der Option –noop ausführen, führt dies einen Probelauf durch, ohne die Konfiguration tatsächlich anzuwenden.
# puppet apply site.pp --noop Notice: Compiled catalog for pemaster.mydomain.com in environment production in 0.06 seconds Notice: /Stage[main]/Main/File[/var/tmp/testfile]/ensure: current_value absent, should be present (noop) Notice: Class[Main]: Would have triggered 'refresh' from 1 events Notice: Stage[main]: Would have triggered 'refresh' from 1 events Notice: Finished catalog run in 0.03 seconds
Oben können Sie sehen, was die neue Konfiguration bewirken wird, ohne tatsächlich Änderungen am Knoten vorzunehmen.
Führen Sie nun den Befehl ohne die Option –noop aus, um die Konfiguration wie unten gezeigt wirklich anzuwenden.
# puppet apply site.pp Notice: Compiled catalog for pemaster.mydomain.com in environment production in 0.07 seconds Notice: /Stage[main]/Main/File[/var/tmp/testfile]/ensure: created Notice: Finished catalog run in 0.05 seconds
Sobald es erfolgreich ausgeführt wurde, sehen Sie, dass die neue temporäre Datei unter /var/tmp/testfile mit den in site.pp definierten Inhalten erstellt wird.
# ls -ld /var/tmp/testfile -rw-rw-r--. 1 root root 69 Jun 26 14:25 /var/tmp/testfile # cat /var/tmp/testfile This is a test file created using puppet. Puppet is really cool
4. Steuern Sie einen Dienst auf einem Remote-Knoten mit Puppet
Hier ist ein Beispiel, um den Dienst auf den Agent-Knoten vom angehaltenen Zustand in den laufenden Zustand zu ändern.
Wenn dieses Konfigurationsmanifest auf dem Master-Server an einem bestimmten Ort im Puppet-Konfigurationsverzeichnis gespeichert wird, kontaktiert der Agent, der auf allen Knoten ausgeführt wird, den Master-Knoten, ruft die Konfiguration ab und wendet sie auf alle Client-Knoten an, sodass der Dienst auf diese Weise gestartet wird auf allen Agentenknoten, nachdem die Puppet-Konfiguration erfolgreich ausgeführt wurde.
# puppet resource service multipathd
service { 'multipathd':
ensure => 'stopped',
enable => 'false',
}
In diesem Beispiel steuern wir den Dienst multipathd. Sie können Puppet verwenden, um alle Dienste zu steuern, die auf dem System ausgeführt werden. Zum Beispiel httpd, mysqld usw.
# puppet resource service multipathd > site.pp
Stellen Sie sicher, dass die site.pp die folgenden Werte hat. Wenn nicht, bearbeiten Sie es entsprechend.
# vi site.pp
service { 'multipathd':
ensure => 'running',
enable => 'true',
}
Führen Sie zuerst einen Probelauf durch, um sicherzustellen, dass es wie erwartet funktioniert.
# puppet apply site.pp --noop Notice: Compiled catalog for pemaster.mydomain.com in environment production in 0.07 seconds Notice: /Stage[main]/Main/Service[multipathd]/ensure: current_value stopped, should be running (noop) Notice: Class[Main]: Would have triggered 'refresh' from 1 events Notice: Stage[main]: Would have triggered 'refresh' from 1 events Notice: Finished catalog run in 0.06 seconds
Wenden Sie schließlich die Konfigurationsdatei an, die den Dienst (in diesem Beispiel multipathd) startet, falls er nicht bereits läuft.
# puppet apply site.pp
Notice: Compiled catalog for pemaster.mydomain.com in environment production in 0.07 seconds
Notice: /Stage[main]/Main/Service[multipathd]/ensure: ensure changed 'stopped' to 'running'
Notice: Finished catalog run in 0.28 seconds
# puppet resource service multipathd
service { 'multipathd':
ensure => 'running',
enable => 'true',
}
# chkconfig --list | grep multipath
multipathd 0:off 1:off 2:on 3:on 4:on 5:on 6:off
5. Installieren Sie ein Paket auf einem Remote-Knoten mit Puppet
Sie können die Paketinstallation auf allen Agentenknoten remote mit Puppet durchführen.
Das Folgende ist eine Beispielmanifestdatei für die Paketinstallation.
# cat site.pp
package { 'httpd':
ensure => 'present',
}
In diesem Beispiel wird das Apache-Paket httpd installiert, wenn es auf der Remote-Site nicht vorhanden ist. Wie Sie unten sehen, wurde das Paket installiert.
# puppet apply site.pp Notice: Compiled catalog for pemaster.mydomain.net in environment production in 0.70 seconds Notice: /Stage[main]/Main/Package[httpd]/ensure: created Notice: Finished catalog run in 79.97 seconds
Überprüfen Sie mit dem Befehl rpm, ob das Paket ordnungsgemäß installiert ist.
# rpm -qa | grep -i httpd httpd-2.2.15-39.el6.centos.x86_64 httpd-tools-2.2.15-39.el6.centos.x86_64
6. Zwei Arten von Puppet-Sammlungen
Ressourcen können die Eigenschaften einzelner Konfigurationselemente auf Knoten konfigurieren. Die meisten Dienste und Anwendungen bestehen jedoch aus mehreren Ressourcen.
Beispielsweise besteht ein Webserver aus dem Softwarepaket, Benutzern zum Ausführen der Software und einer Vielzahl von Konfigurations-, Protokollierungs- und anderen Dateien.
Mit Ressourcensammlungen können Sie die Ressourcen sammeln, sie einer Sammlung zuweisen und die Sammlung auf die Agentenknoten anwenden lassen.
Es gibt zwei Arten der Ressourcensammlung:
- Klassen
- Definitionen
7. Beispiel für eine Puppet-Klassensammlung
Eine Klasse ist eine Sammlung von Ressourcen, die ein einzelnes Konfigurationselement auf Ihrem Knoten darstellt, während eine Definition eine Sammlung von Konfigurationselementen ist, die mehrere Darstellungen auf Ihrem Knoten haben.
Im vorherigen Beispiel werden die Dienste nach der Paketinstallation standardmäßig nicht gestartet. Wir können ein einfaches Manifest mit Klasse erstellen, um das Paket zu installieren und den Dienst nach der Installation zu starten.
Im folgenden Beispiel haben wir die Beziehung zwischen zwei Ressourcen mithilfe des Attributs require angegeben.
# cat site.pp
class apache {
package { 'httpd':
ensure => 'present',
}
service {'httpd':
ensure => 'running',
require => Package["httpd"],
}
}
include apache
Dadurch wird sichergestellt, dass die Bedingung erfüllt ist, bevor die Ressourcenänderungen angewendet werden. In diesem Fall erfordert der Dienst httpd, dass zuerst das httpd-Paket installiert wird, bevor er versuchen kann, die Dienste aufzurufen.
# puppet apply site.pp Notice: Compiled catalog for pemaster.mydomain.net in environment production in 0.93 seconds Notice: /Stage[main]/Apache/Package[httpd]/ensure: created Notice: /Stage[main]/Apache/Service[httpd]/ensure: ensure changed 'stopped' to 'running' Notice: Finished catalog run in 32.82 seconds # chkconfig --list | grep http httpd 0:off 1:off 2:on 3:on 4:on 5:on 6:off # rpm -qa | grep -i http httpd-2.2.15-39.el6.centos.x86_64 httpd-tools-2.2.15-39.el6.centos.x86_64
8. Beispiel einer Puppet-Definitionssammlung
Eine Definition ist eine Art Puppet-Ressourcensammlung.
Definitionen sollten für Konfigurationselemente verwendet werden, die mehrere Instanzen auf einem Knoten haben.
Beispielsweise können auf dem httpd-Server mehrere virtuelle Hosts definiert sein. Sie können eine Definition erstellen, um virtuelle Hosts zu konfigurieren, und entsprechende Argumente übergeben, um jeden zu konfigurieren. Solange jeder Satz von Argumenten unterschiedlich war, konfigurierte Puppet den neuen virtuellen Host jedes Mal, wenn die Definition ausgewertet wurde.
Das Folgende ist ein Beispiel für ein einfaches Manifest mit einer Klasse und einer Definition.
# cat site1.pp
class testdefine {
define testdefine ($data) {
file {"$title":
ensure => file,
content => $data,
}
}
testdefine {'/var/tmp/puppetfile1':
data => "The name of the file is puppetfile1 and it is created by puppet\n",
}
testdefine {'/var/tmp/puppetfile2':
data => "The name of the file is puppetfile2 and it is created by puppet\n",
}
testdefine {'/var/tmp/puppetfile3':
data => "The name of the file is puppetfile3 and it is created by puppet\n",
}
}
include testdefine
Führen Sie die obige Puppet-Klasse und das Definitionsmanifest wie unten gezeigt aus.
# puppet apply site1.pp
Notice: Compiled catalog for pemaster.mydomain.net in environment production in 0.24 seconds
Notice: /Stage[main]/Testdefine/Testdefine::Testdefine[/var/tmp/puppetfile2]/File[/var/tmp/puppetfile2]/ensure: defined content as '{md5}9079bd9c7650ae7d503c7df1a68bb9f0'
Notice: /Stage[main]/Testdefine/Testdefine::Testdefine[/var/tmp/puppetfile3]/File[/var/tmp/puppetfile3]/ensure: defined content as '{md5}75d495f0d3180b1f2dd052ac208d81fe'
Notice: /Stage[main]/Testdefine/Testdefine::Testdefine[/var/tmp/puppetfile1]/File[/var/tmp/puppetfile1]/ensure: defined content as '{md5}1fa93f1f2b82f8358866d58b2cb2f0b4'
Notice: Finished catalog run in 0.19 seconds
# ls -l /var/tmp/puppetfile*
-rw-r--r--. 1 root root 64 Jun 26 19:11 /var/tmp/puppetfile1
-rw-r--r--. 1 root root 64 Jun 26 19:11 /var/tmp/puppetfile2
-rw-r--r--. 1 root root 64 Jun 26 19:11 /var/tmp/puppetfile3
# cat /var/tmp/puppetfile*
The name of the file is puppetfile1 and it is created by puppet
The name of the file is puppetfile2 and it is created by puppet
The name of the file is puppetfile3 and it is created by puppet
9. Beispiel für eine Puppet-Knoten-Konfigurationsdatei
Bisher haben wir die Definition von Ressourcen und Sammlungen von Ressourcen in Form von Klassen und Definitionen gesehen.
Der nächste Schritt besteht nun darin, diese Ressourcen und Sammlungen Clients zuzuweisen.
Hier ist ein Beispiel, wie die Knoten in node.pp definiert sind.
Puppet verwendet diese Datei, um zu bestimmen, welche Klasse (enthält Ressourcen) zu welchem Server gehen soll, z. B. auf Client 1 möchten Sie die Klasse httpd ausführen, die Ressourcen wie httpd-Paket, httpd-Dienst enthält, und auf Client 2 möchten Sie die Klasse ausführen ngnix, das Ressourcen wie das ngnix-Paket, den ngnix-Dienst und andere ngnix-Konfigurationsdateien enthält.
Die folgende Beispieldatei nodes.pp erklärt dies:
node 'puppetclient1.mydomain.net' {
include httpd_class
}
node 'puppetclient2.mydomain.net' {
include ngnix_class
}
node default {
package { "perl":
ensure => present }
}
Innerhalb Ihrer Knotendefinition können Sie Ressourcen, Klassen und Definitionen hinzufügen.
Klassen werden mit der include-Funktion hinzugefügt.
In puppetclient1.mydomain.net haben wir httpd_class und in puppetclient2.mydomain.net haben wir ngnix_class aufgenommen.
Sie können auch mehrere Klassen mit einer einzigen Include-Funktion einschließen. Wenn keine Knotendefinition gefunden wird, werden die definierten Standardwerte verwendet. In diesem Fall werden, wenn es andere Knoten gibt, nur Perl-Pakete installiert, wenn es nicht vorhanden ist.
10. Puppet-Manifestdateien importieren
Die Ressourcen, Klassen und Definitionen werden in Manifestdateien gespeichert.
Eine spezielle Manifestdatei, die als Site-Manifest bezeichnet wird, bildet den Kern unserer Konfiguration.
Beim Starten des Puppet-Master-Daemons muss die Site-Manifestdatei vorhanden sein, die sich standardmäßig in /etc/puppet/manifests/site.pp befindet.
In den obigen Beispielen haben wir site.pp nur verwendet, um zu erklären, wie die Manifeste angewendet werden.
In einer realen Puppet-Umgebung wird Ihre site.pp nur den untenstehenden Inhalt haben und aus dieser Datei werden die anderen Dateien zur Ausführung importiert.
# cat site.pp import "templates.pp" import "nodes.pp" import "classes/*" import "groups/*" import "users/*" import "os/*"
Das Folgende ist die Verzeichnisstruktur des Puppet-Manifests:
- /manifests/classes/ – Verzeichnis, das alle Klassen enthält
- /manifests/site.pp – die primäre Manifestdatei
- /manifests/templates.pp – Enthält Vorlagenknoten
- /manifests/nodes.pp – Enthält Knotendefinitionen
- /manifests/definitions/ – Enthält alle Definitionen
- /manifests/groups/ – Enthält Manifeste zum Konfigurieren von Gruppen
- /manifests/os/ – Enthält Klassen zum Konfigurieren von Knoten mit bestimmten Betriebssystemen
- /manifests/users/ – Enthält Manifeste zur Konfiguration von Benutzern
- /manifest/files/ – Enthält Dateiservermodule für verteilbare Puppet-Dateien