Konfigurationsmanagement versus Image Baking: Wo Idempotenz und Drift entscheiden

Worum es geht

Konfigurationsmanagement-Tools wie Puppet, Salt und Ansible beschreiben den Sollzustand eines Systems deklarativ und führen das tatsächliche System bei jedem Lauf wieder an diesen Zustand heran. Die Puppet-Dokumentation benennt diese Eigenschaft ausdrücklich: "A key feature of Puppet is idempotency — the ability to repeatedly apply code to guarantee a desired state on a system, with the assurance that you will get the same result every time." (Eine zentrale Eigenschaft von Puppet ist Idempotenz: Code lässt sich wiederholt anwenden, um einen Sollzustand sicherzustellen, mit der Gewähr, jedes Mal dasselbe Ergebnis zu erhalten.) Das Glossar von Salt definiert eine idempotente Aktion auf dieselbe Weise: Sie "ensures the system is in a well-known state regardless of the system's state before the action is applied" (stellt sicher, dass sich das System in einem wohldefinierten Zustand befindet, unabhängig vom Zustand vor der Anwendung der Aktion), sodass "applying the action multiple times results in no changes to the system" (die mehrfache Anwendung der Aktion keine Änderungen am System bewirkt), sobald es bereits im Sollzustand ist. Die Ansible-Dokumentation hält fest, dass ihre Tasks "achieve a form of idempotence by checking the current state before they begin and doing nothing unless the current state is different from the specified final state." (eine Form von Idempotenz erreichen, indem sie vor dem Start den aktuellen Zustand prüfen und nichts tun, solange dieser dem vorgegebenen Endzustand entspricht.)

Image Baking (Packer und ähnliche Tools) verfolgt einen anderen Ansatz: Software und Konfiguration werden einmalig beim Build installiert, und das Ergebnis wird als unveränderliches Artefakt festgehalten. Eine gestartete Instanz dieses Images führt die Konfigurationslogik nicht erneut aus, sondern ist schlicht der Zustand, der eingebacken wurde.

Warum es wichtig ist

Idempotentes Konfigurationsmanagement kann kontinuierlich laufen (nach Zeitplan oder bei jedem Boot) und Drift korrigieren, etwa eine Datei, die ausserhalb des vorgesehenen Wegs geändert wurde, oder einen deaktivierten Dienst, indem es dieselbe Deklaration erneut anwendet. Image Baking kann Drift nach dem Boot gar nicht korrigieren: Sobald eine Instanz von ihrem Image abweicht (durch eine manuelle Änderung oder einen Ad-hoc-Fix), bringt sie nichts zurück ausser dem Ersatz durch eine frische Instanz aus dem Image. Baking tauscht die Fähigkeit zur Selbstkorrektur gegen einen schnelleren, vorhersehbareren Boot (kein Konfigurationslauf nötig) und ein kleineres Zeitfenster, in dem eine Fehlkonfiguration oder ein fehlgeschlagener idempotenter Schritt einen Host halb konvergiert zurücklassen kann.

So wird es angewendet

• Ins Image einbacken, was sich selten ändert und ab der ersten Sekunde des Boots vorhanden sein muss: das Basis-Betriebssystem, Sicherheitspatches mit Stand des Builds, Agenten, die bereits laufen müssen.
• Beim Boot (oder kontinuierlich) konfigurieren, was pro Umgebung oder pro Instanz variiert: Hostnamen, aus einem Vault bezogene Secrets, Feature Flags, also alles, was den aktuellen Sollzustand abbilden muss und nicht den Stand des letzten Image-Builds.
• Beide Ansätze bewusst kombinieren: ein "Golden Image", das beim ersten Boot dennoch ein Konfigurationsmanagement-Tool für die letzte, umgebungsspezifische Etappe ausführt, mit einer expliziten Dokumentation, welche Ebene welche Einstellung verantwortet.
• Nicht idempotente Schritte (eine Ressource im exec-Stil, ein rohes Shell-Provisioning) in beiden Ansätzen als Risiko behandeln und explizit idempotent machen (zuerst eine Markierung prüfen), statt davon auszugehen, dass ein einmaliger Lauf sicher ist.

Stolpersteine

• "Es hat beim letzten Mal funktioniert" als Beleg für Idempotenz heranziehen: Eine Ressource kann im Test idempotent erscheinen und ein System mit anderem Ausgangszustand dennoch verändern.
• Ein Image bei jedem Deployment neu backen, statt nur dann, wenn sich der eingebackene Inhalt tatsächlich ändert. Dadurch wird aus einer Schnellboot-Strategie eine langsame, ohne dass der Vorteil der Drift-Korrektur erreicht wird, den beide Ansätze bieten sollen.
• Zuständigkeit für dieselbe Einstellung sowohl beim Bake als auch beim Boot vermischen, sodass zwei Systeme bei jedem Konvergenzlauf darum konkurrieren.