Ein Vergleich von Idempotenz und Unveränderlichkeit

Viele in den DevOps wenden die Mentalität von Rindern und nicht Haustieren an, indem sie eine unveränderliche Infrastruktur implementieren und bei Bedarf neu bereitstellen (anstatt Änderungen vorzunehmen).

Das Konfigurationsmanagement hat ein ähnliches Prinzip der Idempotenz . Was sind die komparativen Vor- und Nachteile von Unveränderlichkeit gegenüber Impotenz und welche sind effizienter? Können diese synergetisch genutzt werden (z. B. periodisches Löschen und erneutes Bereitstellen von VMs oder Docker-Containern mithilfe des Konfigurationsmanagements?)

Die beiden Begriffe sind sehr unterschiedlich.

Beginnen wir mit immutability, was wörtlich "keine Mutationen" oder "keine Veränderungen" bedeutet. Im Sinne von DevOps bedeutet dies, dass Sie nach dem Erstellen eines Artefakts, sei es ein Container-Image oder ein VM-Image oder ein Paket aus kompiliertem Code, erklären, dass Sie es niemals ändern werden. Wenn Änderungen erforderlich sind, erklären Sie häufig, dass stattdessen eine neue Version von "thing" erstellt wird.

Der Begriff idempotencebedeutet, dass bei mehrmaliger Anwendung von Änderungen der Status nur einmal mutiert (geändert) wird . Erstens wird bereits davon ausgegangen, dass Änderungen vorgenommen werden, was bedeutet, dass Sie nicht sowohl unveränderliche als auch idempotente Aktionen ausführen können (vertraglich werden keine Aktionen ausgeführt).

Bei der Verwendung von Konfigurationsverwaltungstools idempotencewird in einigen Fällen verwendet, wenn dieselbe Änderung mehrmals angewendet wird. Wie beim Hinzufügen der Zeile, localhostdie der /etc/hostsDatei sagt , benötigen Sie nicht wirklich mehrere solcher Zeilen, und wenn bereits eine vorhanden ist, können Sie sicher nicht versuchen, erneut anzuhängen.

Dies idempotentist auch ein Begriff, der verwendet wird, um Aktionen zu beschreiben , die versuchen, Dinge zu ändern, während er immutableverwendet wird, um Substantive (Objekte) zu beschreiben , die gegen Änderungen an ihnen gesetzt werden.

Warum ist ein immutableObjekt nützlich? Denn wenn Sie es kopieren, zum Beispiel von einer Entwicklungsumgebung über QA bis zur Produktion. Sie wissen bereits ziemlich viel (aber nicht alles) darüber, wie es sich verhalten wird. In vielen Fällen sind die Teile, die funktionieren, konsistent, und die Teile, die defekt sind, sind ebenfalls konsistent.

Warum sind idempotentAktionen nützlich? Wenn Sie den Status eines Objekts ändern möchten, ist es in vielen Fällen hilfreich, nur zu überprüfen, ob die Änderung angewendet wurde, und Änderungen nur dann anzuwenden, wenn dies erforderlich ist. Wenn beispielsweise ein Konfigurationselement in einer Datei fehlt oder den falschen Wert hat, ist es hilfreich, es nur einmal hinzuzufügen oder nur einmal zu ändern, während Sie die Aktion mehrmals anwenden. In vielen anderen Fällen, z. B. bei Protokolldateien , möchten Sie keine idempotenten Aktionen ausführen, da Sie häufig jedes Mal, wenn ein Ereignis eintritt, eine weitere Zeile anhängen möchten.

Unveränderliche Infrastruktur ist meines Erachtens ein anderes Muster als Configuration Management. Während sie zusammen verwendet werden können, gehen sie Probleme von Natur aus auf zwei verschiedene Arten an.

Das Konzept der unveränderlichen Artefakte hat eine lange Geschichte. Unix-Systeme verwenden sie seit Jahrzehnten, um Softwarepakete bereitzustellen. Aber sobald sie bereitgestellt wurden, wurden die Konfigurationsdateien geändert, so dass die Dinge veränderlich wurden. Idempotency bietet einige nette Garantien für veränderbare Dateien. Wir können wissen, wann sich Dinge geändert haben, und nur Dinge aktualisieren, die aktualisiert werden müssen. Es löst jedoch nicht alle Probleme veränderlicher Objekte, wir müssen dennoch eine scheinbar unendliche Anzahl von Randfällen berücksichtigen. Da die Dinge veränderlich sind und wir idempotent sind, müssen wir zuerst feststellen, welche Änderungen vorgenommen werden müssen, und sie dann im Allgemeinen in einer ganz bestimmten Reihenfolge ausführen. Bei der Bereitstellung von Softwarepaketen, insbesondere bei Bereitstellungen ohne Ausfallzeit, müssen Änderungen sorgfältig koordiniert werden, um zu verhindern, dass Anforderungen gelöscht werden.

Diese Komplexität kann letztendlich vermieden werden, indem unveränderliche Artefakte bereitgestellt werden, anstatt sie an Ort und Stelle zu mutieren, da wir einfach ein Objekt durch ein anderes ersetzen (sei es eine Binärdatei, ein Container oder eine virtuelle Maschine), es in Betrieb nehmen und das alte aus dem Verkehr ziehen . Dies ist nur ein Beispiel für eine Bereitstellung ohne Ausfallzeit.

Mit den Fortschritten bei den Tools, die es uns ermöglichen, unveränderliche Artefakte in sehr kurzer Zeit auf Tausenden von Systemen bereitzustellen, sehen wir die Verwendung unveränderlicher Tools zur Verwaltung von Systemen als weitaus praktikabler als das Konfigurationsmanagement. Das Werkzeug ist jedoch noch nicht vorhanden und es gibt noch einen Anwendungsfall für beide. Ich habe einen Vortrag zu diesem Thema gehalten, der den linearen Verlauf von vollständig veränderlich zu vollständig unveränderlich erklärt. Es ist ein Spektrum, und jedes Unternehmen wird auswählen, wo es am besten zu ihm passt.