Configuration Management sorgt dafür, dass Server, VMs und Services dauerhaft im gewünschten Zustand bleiben. Es adressiert ein sehr konkretes Betriebsrisiko: Systeme, die „eigentlich gleich“ sein sollten, driften auseinander – und genau dann wird Betrieb teuer (Fehleranalyse, Security, Recovery, Audit).

In diesem Artikel geht es um Automatisierung nach dem Desired-State-Prinzip: Konfiguration wird als Code beschrieben, versioniert und reproduzierbar ausgerollt. So entsteht ein belastbares Fundament für Themen wie Infrastructure as Code, Wartung & Patch Management und sichere Delivery-Prozesse.

Das Problem: Configuration Drift und „Snowflake Server“

Drift entsteht fast immer schleichend:

Hotfixes werden ad hoc auf einzelnen Hosts eingespielt.

Konfigurationen werden per Hand angepasst („nur kurz für heute“).

Pakete/Abhängigkeiten unterscheiden sich je nach Installationstag.

Rollen/Ownership sind unklar – mehrere Teams ändern am gleichen System.

Nach Wochen oder Monaten sind Hosts nicht mehr reproduzierbar. Typische Folgen:

„Funktioniert nur auf Host X“: Fehler sind nicht deterministisch.

Security-Gaps: Patches und Hardening sind inkonsistent.

Lange Wiederherstellung: Bei Ausfällen lässt sich der Zustand nicht sauber rekonstruieren.

Audit-Probleme: Nachweisbarkeit (Wer hat wann was geändert?) fehlt.

Config-Management dreht das Prinzip um: Nicht Menschen „pflegen“ Server, sondern Code definiert den Zustand – und Abweichungen werden sichtbar und korrigierbar.

Config Management vs. IaC: was gehört wohin?

In der Praxis ergänzen sich beide Ansätze:

Infrastructure as Code (IaC) provisioniert Ressourcen: Netzwerke, VMs, Load Balancer, Datenbanken, Kubernetes-Cluster.

Configuration Management konfiguriert das Betriebssystem und die Software darauf: Packages, Dienste, Konfigurationsdateien, Benutzer, Policies.

Ein pragmatisches Setup ist häufig: IaC erstellt Server/VMs, Config Management übernimmt Baseline + Applikationskonfiguration. In containerisierten Setups verschiebt sich vieles in Images/Helm-Charts, aber Baselines (Hardening, Accounts, Agenten, Monitoring) bleiben relevant.

Vorteile von automatisiertem Configuration Management

Konsistenz und Wiederholbarkeit

Konfiguration ist eine Quelle der Wahrheit (Git). Jede Änderung ist nachvollziehbar, reviewbar und bei Bedarf rücksetzbar.

Geschwindigkeit und Skalierung

Neue Hosts sind schneller produktionsbereit. Rollouts werden standardisiert, nicht jedes Mal neu „ausgedacht“.

Sicherheit und Compliance

Security-Baselines (z. B. SSH-Hardening, Logging, Endpoint Protection) lassen sich automatisiert durchsetzen. Das zahlt direkt auf Security & Compliance Beratung ein.

Disaster Recovery und Betriebssicherheit

Wenn der Zustand beschrieben ist, wird Wiederherstellung planbar: „Neu provisionieren und konfigurieren“ ist ein Prozess, kein Heldentum.

Tooling: Ansible, Puppet, Chef (und wann welches passt)

Es gibt nicht „das eine“ richtige Tool – relevant sind Team-Skills, Infrastrukturgröße, Governance und Integrationsanforderungen.

Ansible (push, agentless)

https://docs.ansible.com/

Vorteile: niedrige Einstiegshürde, SSH-basiert, gutes Ökosystem.

Typische Nutzung: Baselines, Applikationsrollout, Orchestrierung.

Puppet (desired state, agent-basiert)

https://www.puppet.com/docs

Vorteile: starke Modellierung, Reporting, Skalierung, Compliance-/Audit-Funktionen.

Typische Nutzung: große heterogene Flotten, zentrale Steuerung, langlaufende Baselines.

Chef (infrastruktur-nah, flexibel)

https://www.chef.io/products/chef-infra

Vorteile: hohe Ausdrucksstärke, umfangreiches Cookbook-Ökosystem.

Typische Nutzung: Teams mit starkem Engineering-Fokus, komplexe Automatisierung.

Weitere Optionen (je nach Kontext): Salt (https://docs.saltproject.io/), CFEngine (https://cfengine.com/). Entscheidend ist weniger der Name als ein sauberer Prozess: Versionierung, Tests, Rollout und Betrieb.

Best Practices, die in der Praxis den Unterschied machen

Idempotenz und „konvergent“ statt „skriptig“

Ein gutes CM-System führt bei wiederholter Ausführung immer zum gleichen Ergebnis. Das heißt:

Keine „einmaligen“ Shell-Skripte ohne State,

Zustandsprüfungen vor Änderungen,

klare Service- und File-Ressourcen (statt „sudo sed …“).

Inventarisierung, Rollen und Modularisierung

Struktur vermeidet Chaos:

Rollen/Profiles (z. B. baseline, webserver, dbclient),

environments/stages (dev/staging/prod),

Variablen sauber trennen (Defaults vs. environment-specific),

klare Ownership pro Rolle/Service.

Secrets und Konfigurationswerte sicher handhaben

Konfiguration enthält oft Secrets (Tokens, DB-Passwörter). Grundregeln:

Secrets nie in Git im Klartext,

Vault/Secret-Manager nutzen (z. B. HashiCorp Vault, Cloud KMS),

Least Privilege: Zielsysteme bekommen nur, was sie brauchen,

Rotation/Expiry als Standard, nicht als Projekt.

Testing: erst lokal, dann im Rollout

Für Ansible haben sich Molecule und CI-Tests etabliert:

Molecule: https://molecule.readthedocs.io/

Sinnvolle Teststufen:

Syntax/Lint (ansible-lint, puppet-lint),

Unit-/Role-Tests (Molecule),

Smoke-Tests nach Deployment,

Compliance Checks (z. B. CIS Baselines je nach Umfeld).

Rollout-Strategien: klein starten, sicher ausweiten

Canary/Batch Rollouts (z. B. 5% → 25% → 100%),

Wartungsfenster für disruptive Änderungen,

automatische Rückfallmechanismen (Rollback/Disable),

klare Change-Kommunikation (was ändert sich, wann, wie prüfen?).

Zusammenspiel mit Patch Management und Observability

Config Management ersetzt Patch Management nicht – es macht es steuerbar:

Baseline regelt, welche Repos aktiv sind, welche Policies gelten,

Patch-Rollouts werden in Wellen automatisiert,

Abweichungen (fehlende Patches, falsche Kernel) werden sichtbar.

Damit Fehler nicht „still“ bleiben, gehört Monitoring dazu:

Monitoring & Observability

SLA, SLO & Incident Response

Checkliste: wann Config Management „reif“ ist

Konfigurationen liegen versioniert in Git und werden per PR reviewed

Baseline (Hardening, Logging, Monitoring-Agent) ist standardisiert

Secrets sind sauber gelöst (Vault/Secret Manager), kein Klartext in Repos

Tests laufen in CI (Lint + Molecule/Integration nach Bedarf)

Rollouts sind gestaffelt und nachvollziehbar (Change-Log, Audit-Trail)

Ownership pro Rolle/Service ist geklärt

Fazit

Automatisiertes Configuration Management reduziert Drift, verbessert Sicherheit und macht Betrieb skalierbar. Auch kleinere Umgebungen profitieren von Standards und Automatisierung. Wer Desired State konsequent als Code behandelt, gewinnt Planbarkeit – und schafft die Basis, damit IaC, CI/CD und Incident-Prozesse nicht nur „eingeführt“, sondern im Alltag zuverlässig funktionieren.

Automatisiertes Config-Management: Drift vermeiden