Infrastructure-as-Code einführen und umsetzen

Viele IT-Abteilungen kämpfen seit langer Zeit mit den klassischen Herausforderungen des Change- und Release-Managements: Welche Konfigurationen sind notwendig, um einen Applikationsserver für Anwendung X bereitzustellen? Wer hat die Änderung an der Datenbank Y gemacht und warum war sie notwendig? Welche Systeme müssen angepasst werden, um die neue Version der Middleware erfolgreich auszurollen? Diese und ähnliche Probleme rühren sehr häufig daher, dass Konfigurationen von Infrastrukturkomponenten wie Servern, Datenbanken oder Netzwerk-Switches keiner einheitlichen Konvention unterliegen. Ein Windows-Server wird oft mit grafischen Werkzeugen, Gruppenrichtlinien oder Registry-Einstellungen konfiguriert, bei einer Linux-Maschine sind es Kommandozeilenbefehle und Textdateien und Datenbanken kommen mit SQL daher, während Netzwerkgeräte proprietäre Shell-Sprachen erfordern. Kein Wunder, dass ein komplexer Change schwer zu formulieren, zu dokumentieren und später nachzuvollziehen ist. Oft ist der Zustand vor dem Change ebenso wenig bekannt wie der gewünschte Stand nach dem Change.

In der Software-Entwicklung sind Antworten auf diese Fragen viel früher überlebensnotwendig geworden, darum gibt es für diese Herausforderungen schon seit langem bewährte Methoden und vorgefertigte Lösungen. Erleichtert wird die Pflege einer "lebenden" Software auch dadurch, dass das Ausgangsmaterial, der Quellcode also, in der Regel in Form von flachen Textdateien vorliegt. Diese lassen sich sehr einfach versionieren, miteinander vergleichen, indizieren, durchsuchen und – falls einmal nötig – global transformieren. Um das Chaos in der Systemadministration wirksam zu bekämpfen und die Unterstützung von Release- und Deployment-Prozessen aus "Dev" effizienter zu gestalten, liegt es nahe, die bewährten Methoden der Quellcode-Verwaltung und -Pflege auch in "Ops" zu integrieren.

Der komplette Artikel ist nur für Abonnenten des ADMIN Archiv-Abos verfügbar.