Puppet ist ein Konfigurationsmanagement Tool um die immer größer werdende IT-Landschaft automatisieren zu können. Dafür gibt es in Puppet sogenannte Module um den Endstatus zu definieren. Mittels des Puppet Agents, welcher auf dem Zielsystem installiert werden muss wird nun ein OS-spezifischer Katalog vom Puppetserver kompiliert, der dem Agent sagt, was er genau zu tun hat.
Als Vorbereitung habe ich zwei Ubuntu 22.04 Maschinen mit jeweils 4 CPUs und 8 GB RAM aufgesetzt. Als kleine Ergänzung hierzu habe ich vorher versucht den Puppetserver mit nur 2 CPUs laufen zu lassen, was leider zu Problemen geführt hat. Daher empfehle ich trotz Mindestanforderung von 2 CPUs trotzdem 4 CPUs zu verwenden um eventuelle Fehler vorzubeugen. Sollten die Ressourcen allerdings knapp sein, kann natürlich trotzdem versucht werden die Mindestanforderungen von 2 CPUs zu benutzen. Beide Maschinen sind zusätzlich komplett geupdatet und auf dem neusten Stand gebracht mittels:
1apt update &&
2apt upgrade -y &&
3apt dist-upgrade -y
Hier einmal für einen Überblick die Namen und die IP-Adressen, damit im weiteren Artikel nur noch die Namen Verwendung finden können.
1192.168.176.58 => puppetmaster.fritz.box
2192.168.176.59 => puppetagent.fritz.box
Um einen aktuellen Puppetserver zu installieren sollte man zuerst die Paketquellen von Puppet einbinden, damit man hier immer auf dem aktuellen Stand ist. Dafür stellt Puppet Labs (das Unternehmen hinter Puppet) ein Paket bereit, welches für Debian oder RedHat basierte Systeme die Quellen selber einbindet, wenn man das Paket installiert. Das Paket bekommt man durch folgenden Befehl und kann es mit dem Nachfolgenden direkt installieren:
1wget https://apt.puppet.com/puppet7-release-focal.deb
2dpkg -i puppet7-release-focal.deb
Nun müssen die Paketquellen aktualisiert werden.
1apt update
Zu guter Letzt muss nun der puppetserver installiert werden. Dafür reicht folgendes Kommando:
1apt-get install puppetserver -y
Der Server kann in der RAM nutzung angepasst werden um ihn für mehr Last vorzubereiten. Dafür wird die Datei unter /etc/default/puppetserver editiert und die Zeile abgeändert.
1JAVA_ARGS="-Xms2g -Xmx2g -Djruby.logger.class=com.puppetlabs.jruby_utils.jruby.Slf4jLogger"`
Das -Xms steht für die initiale RAM allokierung (wie viel RAM bekommt die JVM) Das -Xmx steht für die maximale RAM allokierung (wie viel RAM darf die JVM benutzen)
Das 2g steht für 2 Gigabyte. Hier sind allerdings auch z.B. 512m gültig.
Nun kann der Puppet Server gestartet werden. Das kann mittels systemctl gemacht werden.
1systemctl start puppetserver
Der Puppetserver sollte ohne Probleme hochfahren und kann nun anfragen von unseren Clients beantworten.
Um eine bessere Struktur zu haben, passen wir unseren Server noch etwas an. Puppet Labs empfiehlt hier die sogenannte Control Repository Struktur. Diese Struktur kann man von Github einfach clonen und hat anschließend die Vorteile von einem Vorkonfigurierten Environment. Ein environment ist in Puppet übrigens eine "Umgebung" in der man mehrere Server setzen kann um neue Module oder aber Konfigurationen zu testen.
Dafür bewegen wir uns erstmal in das Verzeichnis wo unsere Environments liegen und machen ein Backup davon, indem wir das Verzeichnis production nach production_BACKUP verschieben.
1cd /etc/puppetlabs/code/environments/
2mv production production_BACKUP
Nun können wir das control Repository von github klonen und einmal umbennen nach production um unsere Standard Umgebung zu behalten.
1git clone https://github.com/puppetlabs/control-repo.git
2mv control-repo/ production
Diese Repo bietet nun ein beispiel dafür wie man eine Puppet Umgebung definieren kann. Wir nehmen die Standard Umgebung und machen allerdings ein paar Änderungen um noch besser Spezialfälle zu handeln.
Zuerst richten wir unter manifests/site.pp unsere Standardumgebung besser ein. Hier schreiben wir einfach nur den Standard für unsere Server rein:
1node default {
2 # This is where you can declare classes for all nodes.
3 # Example:
4 # class { 'my_class': }
5 lookup('classes', {merge => unique}).include
6}
Der Standart für Server ist, das wir in Hiera nachgucken welche Klassen für den spezifischen Server gesetzt wurden.
Nun kümmern wir uns um die Hiera Definition, genauer in welcher Reihenfolge die Definitionen in Hiera gemerged werden.
Dafür öffnen wir die hiera.yaml
Wir benötigen hier eine Möglichkeit nach einzelnen Servern, alle Server und nach dem OS zu sortieren um ggf. OS-spezifische Repositories einzubinden.
Dafür ändern wir die hiera.yaml Datei so ab, dass der hierachy Teil so aussieht:
1hierarchy:
2 - name: "Node Data"
3 data_hash: yaml_data
4 glob: "nodes/**/%{trusted.certname}.yaml"
5 - name: "OS Version"
6 data_hash: yaml_data
7 glob: "os/%{facts.osfamily}-%{facts.operatingsystemrelease}/**/*.yaml"
8 - name: "OS"
9 data_hash: yaml_data
10 glob: "os/%{facts.osfamily}/**/*.yaml"
11 - name: "common"
12 data_hash: yaml_data
13 glob: "common/**/*.yaml"
Jetzt kann man die Agenten auf den Servern verteilen und anfangen
#max-active-instances: 1
Hier kann man die Instanzen setzen. Wenn man diese auf 1 packt. Damit hat man die Möglichkeit auch mit nur zwei CPUn zu rechnen