Puppet ist ein Open-Source-Werkzeug für Konfigurationsmanagement: Administratoren beschreiben den gewünschten Zustand von Servern in deklarativen Manifests, und Puppet bringt die Systeme automatisch in diesen Zustand. Zusammen mit Ansible und Chef gehört es zu den Klassikern der Infrastructure as Code.

So funktioniert Puppet

In der klassischen Architektur läuft ein Puppet-Master (Server), von dem die Puppet-Agents (verwaltete Systeme) regelmäßig ihre Konfiguration abholen. Der Agent sammelt Fakten über das System (Facter), der Master kompiliert daraus ein Katalog, und der Agent setzt ihn um.

Deklarative Syntax

# Manifest: Webserver-Paket + Dienst + Konfigurationsdatei
package { 'nginx':
  ensure => installed,
}

service { 'nginx':
  ensure => running,
  enable => true,
  require => Package['nginx'],
}

file { '/etc/nginx/nginx.conf':
  ensure  => file,
  owner   => 'root',
  group   => 'root',
  mode    => '0644',
  source  => 'puppet:///modules/webserver/nginx.conf',
}

Man beschreibt das Ziel (Paket installiert, Dienst läuft), nicht den Weg dorthin. Puppet gleicht den Ist-Zustand mit dem Soll-Zustand ab und korrigiert Abweichungen.

Puppet vs. Ansible

  • Architektur: Puppet ist pull-basiert (Agent holt Konfiguration), Ansible ist push-basiert (Steuerrechner verbindet sich per SSH).
  • Sprache: Puppet nutzt eine eigene deklarative DSL, Ansible YAML-Playbooks.
  • Einsatz: Puppet eignet sich für große, heterogene Farmen mit zentralem Master; Ansible für schnelle Ad-hoc-Aufgaben ohne Agent.

Puppet im DevOps-Alltag

Puppet-Module werden wie Code versioniert und über eine CI/CD-Pipeline getestet und ausgerollt. Damit ist es ein zentraler Baustein der Automatisierung: Hunderte Container und VMs entstehen reproduzierbar aus Code statt aus Handarbeit. Ergänzt durch Monitoring und Observability entsteht eine selbstheilende Infrastruktur.