Читать книгу Handbuch Infrastructure as Code - Kief Morris - Страница 41

Beim Konfigurationsdrift handelt es sich um eine Variation, die mit der Zeit zwischen Systemen auftritt, die ursprünglich identisch waren. In Abbildung 2-1 ist das zu sehen. Der Drift kann durch manuelle Änderungen entstehen oder wenn Sie Automations-Tools nutzen, um kurzfristig Änderungen an nur ein paar der Instanzen vorzunehmen. Ein Konfigurationsdrift erschwert das konsistente Warten der Automation.

Abbildung 2-1: Bei einem Konfigurationsdrift kommt es bei Instanzen des gleichen Elements mit der Zeit zu Unterschieden.

Schauen Sie sich als Beispiel dafür, wie die Infrastruktur mit der Zeit auseinanderdriften kann, die Reise unseres Beispielteams bei ShopSpinner an.¹

ShopSpinner betreibt für jeden Store eine eigene Instanz ihrer Anwendung, und jede Instanz ist so konfiguriert, dass sie ein spezifisches Branding und einen eigenen Produktkatalog enthält. Früher ließ das ShopSpinner-Team Skripte laufen, um einen neuen Anwendungsserver für jeden neuen Store zu erstellen. Das Team betreute die Infrastruktur manuell oder durch das Schreiben von Skripten, die angepasst wurden, wenn eine Änderung erforderlich war.

Bei einem der Kunden – Water Works¹ – gibt es viel mehr Traffic in der Auftragsverwaltungs-Anwendung als bei den anderen, daher hat das Team die Konfiguration für den Server von Water Works angepasst. Es hat diese Änderungen aber nicht bei den anderen Kunden vorgenommen, weil es zu beschäftigt war und ihm dies auch nicht notwendig erschien.

Später wollte das ShopSpinner-Team Servermaker einsetzen, um die Konfiguration seiner Anwendungsserver zu automatisieren.² Es hat das Produkt zunächst mit dem Server für Palace Pens³ ausprobiert, weil bei diesem Kunden immer nur wenig Last vorherrscht, und es dann für die anderen Kunden ausgerollt. Leider hat der Code nicht die Performance-Optimierungen für Water Works enthalten, daher gingen diese Verbesserungen wieder verloren. Der Server von Water Works wurde immer langsamer, bis dem Team der Fehler auffiel und es ihn beseitigte.

Das ShopSpinner-Team hat darauf reagiert, indem es den Servermaker-Code parametrisiert hat. Es kann jetzt die Ressourcen-Level für jeden Kunden anders setzen. So ist es dazu in der Lage, bei jedem Kunden den gleichen Code anzuwenden, ihn aber trotzdem überall zu optimieren. In Kapitel 7 sind ein paar Patterns und Antipatterns für das Parametrisieren von Infrastruktur-Code für unterschiedliche Instanzen beschrieben.