Cloud-Versionierung: Infrastruktur-Änderungen und -Konfigurationen zurücknehmen Undoes für Cloud-Schnitzer

Eine ordentliche Versionierung ist im Cloud-Umfeld geschäftskritisch. Ein Ansatz namens Infrastructure from Code (kurz: IfC) revolutioniert die Art und Weise, wie Unternehmen Cloud-Dienste bereitstellen und verbrauchen. Doch gerade in der Cloud gilt: Eine universelle Lösung gibt es nicht. Maßgeschneiderte Lösungen gehen mit ihrer Flexibilität über Standardrezepte hinaus.

Die moderne Cloud-IT setzt auf Automatisierung. Die Orchestrierung einer Cloud-Bereitstellung schafft Bedarf an intelligenter Versionierung. Mit steigender Komplexität wachsen die Anforderungen und so suchen Cloud-Anwenderorganisationen stets nach neuen Tools und Ansätzen, um dem drohenden Chaos den Riegel vorzuschieben.

Bei der Verwaltung komplexer Cloud-Infrastrukturen muss jede Änderung nachvollziehbar sein, damit sie sich im Notfall rückgängig machen lässt. Hierzu ist eine systematische Überwachung von Änderungen an der Infrastruktur und Daten unabdingbar. Die führenden Anbieter – AWS, Google Cloud und Microsoft Azure – bieten dafür spezialisierte Tools für ihre jeweiligen Dienste.

Änderungen in AWS im Blick behalten

Das Herzstück der versionierten Infrastrukturverwaltung bei Amazon Web Services (AWS) stellt CloudFormation dar. Dieser Dienst bildet alle Ressourcen und deren Beziehungen zueinander als deklarative Templates ab und dokumentiert die Änderungen fortlaufend. Dies ermöglicht eine lückenlose Nachverfolgung und proaktive Kontrolle über den gesamten Lebenszyklus der Bereitstellung hinweg.

Rollbacks in CloudFormation sind zwar möglich, allerdings können komplexe Abhängigkeiten die Wiederherstellung früherer Versionen der Infrastruktur erschweren. CloudFormation schafft es nicht immer, alle Änderungen sauber zurückzusetzen. Dadurch sind typischerweise manuelle Eingriffe erforderlich.

Auch Snapshots von EBS-Volumes und AMIs (Amazon Machine Images) lassen sich versionieren. In Kombination mit den Automatisierungstools AWS CodePipeline (zur Automatisierung von Software-Releases) und CodeDeploy (für die anschließende Code-Bereitstellung) wird der gesamte Prozess in CI/CD-Pipelines eingebunden. Google versioniert Cloud Source Repositories. Azure versioniert unter anderem Blob Storage.

Vollständig verwaltete Cloud-Dienste wie Amazon Lambda und Azure/Google Cloud Functions (serverlose Funktionen) unterstützen von sich aus die Versionierung von Code und Konfigurationen. Bei jeder Aktualisierung und Veröffentlichung einer Lambda-Funktion erzeugt AWS eine neue Version, die einen unveränderlichen Snapshot des Funktionscodes und der Konfiguration darstellt.

Drittanbietertools, von Jenkins bis hin zu Spinnaker, können den Prozess der Versionierung erleichtern und multicloud-fähig gestalten.

Fokus auf Deployment in der Google Cloud

Bei der Versionierung der Google Cloud spielte stets der Deployment Manager eine zentrale Rolle. Hier werden Infrastrukturressourcen durch deklarative Konfigurationsdateien beschrieben und jede Veränderung als neue Version gesichert. Diese Methode erlaubte es Teams, mit Hilfe von Rollbacks auf frühere Zustände zurückzugreifen. Googles Motivation, den Deployment Manager weiterzuentwickeln, muss allerdings hinterfragt werden. Google empfiehlt nämlich für die Verwaltung von Cloud-Infrastrukturen Werkzeuge wie Terraform oder Pulumi, die eng in die Google-Cloud-Ökosysteme eingebunden sind.

Google Cloud Storage bietet nach wie vor eine integrierte Versionierung und Cloud Build will CI/CD-Prozesse mit einbeziehen. Azure DevOps, GitHub Actions und Google Cloud Build bieten tiefgreifende CI/CD-Integrationen, wodurch sich Infrastruktur- und Anwendungsänderungen synchronisiert und versioniert umsetzen lassen.

Microsoft setzt auf automatisierte Richtlinienkontrolle

Microsoft Azure setzt auf IaC (Infrastruktur as Code) auf dem Unterbau von Azure Resource Manager (ARM) Templates. Diese Infrastrukturvorlagen erlauben eine exakte Definition und Verwaltung der gesamten Infrastruktur. Azure Blueprints sorgten zusätzlich dafür, dass jede Version der Infrastruktur den vorgegebenen Governance-Standards genügte; diesen Dienst hat Microsoft eingestellt.

Die empfohlenen Alternativen sind Azure Policy und ARM Templates. Die Fähigkeit zur automatisierten Richtlinienkontrolle rund um Governance und Compliance unterscheidet Azure von den anderen Anbietern. Für die Umsetzung von CI/CD-Pipelines bietet Microsoft die Dienste Azure DevOps und GitHub Actions, die jede Änderung an Code von der Entwicklung bis zur Produktion begleiten und versioniert bereitstellen.

Versionierung in der Multicloud

Die Versionierung einer Multicloud-Umgebung erfordert besondere Sorgfalt und ruft spezialisierte Werkzeuge auf den Plan. Die Herausforderungen liegen dabei nicht nur in der Konsistenz und Nachvollziehbarkeit von Infrastrukturänderungen, sondern auch in der effizienten Orchestrierung über verschiedene Cloud-Anbieter hinweg. Externe Tools spielen hier eine Schlüsselrolle, um die Infrastruktur, den Lebenszyklus der Daten und auch APIs gezielt zu steuern. Dienste wie GitHub, GitLab oder Bitbucket bieten sowohl klassische Versionskontrolle für Code als auch tiefgehende Integrationen mit AWS, Azure und Google Cloud (GitHub ist seit dem Jahre 2018 Teil des Microsoft-Konzerns, wurde jedoch bisher nicht in Azure eingegliedert).

Wie versioniert man denn eine Multicloud-Bereitstellung? Das hängt davon ab, wen man fragt. Beim Einsatz von Anwendungen Dritter überwiegt eine Herangehensweise, die unter der Bezeichnung Infrastructure as Code bekannt ist. Unternehmen, die ihre Cloud-Anwendungen selbst entwickeln, setzen allerdings verstärkt auf einen Ansatz namens Infrastructure from Code. Auf den ersten Blick sind die Unterschiede subtiler Natur. Die Folgen einer Fehlentscheidung können gravierend sein.

Infrastructure as Code: deklarative, imperative und hybride Lösungen

Die Landschaft der IaC-Tools unterteilt sich im Grunde genommen in drei Kategorien: in deklarative, imperative und hybride Lösungen – also jene, die ihre deklarative Arbeitsweise in kundenspezifischem Code orchestrieren können. Deklarative IaC-Tools stellen die Infrastruktur anhand einer Beschreibung ihres angestrebten Zustands her. Diese Tools ermitteln eigenständig die erforderlichen Schritte mit Blick auf das Endergebnis. In diese Kategorie fallen unter anderem Terraform von HashiCorp und Puppet von Puppet, Inc. Imperative IaC-Tools befolgen den gegensätzlichen Ansatz: Sie führen eine Reihe von Aktionen aus, aus denen sich ein bestimmter Zustand der Infrastruktur im Endeffekt ableitet. In diese Kategorie fallen unter anderem die Ansible Automation Platform von Red Hat und Chef von der Progress Software Corporation (ursprünglich von Opscode). Die hybride Herangehensweise verfolgt unter anderem Pulumi.

Terraform ermöglicht eine konsistente Bereitstellung von Cloud-Ressourcen über verschiedene Anbieter hinweg. Es ist ein deklaratives Infrastructure-as-Code-Tool. Es stellt den gewünschten Endzustand der Infrastruktur her, ohne eine explizite Anleitung zu benötigen, welche Schritte jetzt durchzuführen sind, um dorthin zu gelangen. Terraform ermittelt selbstständig die erforderlichen Aktionen, um die aktuelle Infrastruktur in den gewünschten Zielzustand zu überführen.

Imperative Tools zur Verwaltung von Cloud-Infrastrukturen geben explizit vor, welche Schritte in welcher Reihenfolge durchgeführt werden müssen, um eine bestimmte Umgebung aufzubauen oder zu verändern. Diese Tools sind besonders nützlich, wenn feingranulare Kontrolle und schrittweise Ausführung gewünscht sind. Ein Beispiel für diesen Ansatz stellen eigenentwickelte Shell-Skripte dar. Imperative Tools wie Shell-Skripte sind dann sinnvoll, wenn Unternehmen feingranular steuern müssen, was und wann in einer Cloud-Umgebung geschehen soll.

Die Versionierung mit Infrastructure-as-Code-Tools wie Terraform oder Ansible verwaltet die Änderungen der Infrastruktur leicht nachvollziehbar, jedoch getrennt vom Code der Anwendung.

Das hybride Versionierungswerkzeug Pulumi funktioniert primär deklarativ, weil es auf den gewünschten Endzustand abzielt, bietet aber gleichzeitig auch die imperative Flexibilität herkömmlicher Skript- und Programmiersprachen wie Python, TypeScript, C# oder Go, um Infrastruktur zu definieren. Diese Herangehensweise ermöglicht den Einsatz von Sprachkonstrukten wie Schleifen, Bedingungen und anderen Kontrollstrukturen. So lassen sich komplexe Cloud-Umgebungen flexibel definieren und dynamisch pflegen. Pulumi ermöglicht eine enge Verzahnung von Code mit der Cloud-Infrastruktur, was insbesondere in agilen Multicloud-Setups große Vorteile bringt – und nicht zuletzt die Umsetzung von Infrastructure-from-Code ermöglicht.

Git-basierte Plattformen wie GitHub, GitLab oder Bitbucket können den Versionsstand von Infrastruktur-Code sichern. Allerdings ist die Nutzung solcher Repositories nicht zwingend erforderlich; es gibt auch andere Möglichkeiten, Versionen zu verwalten – zum Beispiel in Cloud-nativen Versionierungssystemen der einschlägigen Anbieter oder auf Plattformen wie der Terraform Cloud oder Pulumi Cloud.

GitOps ist eine Weiterentwicklung von IaC, bei der Git als Single Source of Truth für Infrastruktur- und Anwendungskonfigurationen zum Zuge kommt. Änderungen an der Infrastruktur werden durch Pull Requests in einem Git-Repository initiiert und über CI/CD-Pipelines unter Einbezug von Werkzeugen wie ArgoCD oder Flux umgesetzt. ArgoCD und Flux sind zwei weit verbreitete Tools, die Pull-Requests als Trigger für Infrastrukturänderungen nutzen. Ein Ansatz namens Policy-as-Code erweitert diese Konzepte um Governance und versionierte Automatisierung auf höherer Ebene.

Konfigurationsmanagement-Werkzeuge wie Red Hat Ansible oder Chef versionieren in YAML- bzw. Rezeptdateien. Im Gegensatz zu Terraform und Pulumi gibt es bei Ansible kein durchgehendes State-Tracking – jede Änderung wird direkt auf die Cloud-Systeme übertragen. Rollbacks gestalten sich schwieriger, da Konfigurationsänderungen inkrementell sind. Ein Rollback erfordert das explizite Ausführen umgekehrter Tasks oder das erneute Ausrollen einer früheren Konfiguration aus Git. Jedoch gibt es in Ansible Ansätze wie idempotente Playbooks, die es erlauben, Änderungen in einem definierten Zustand zu halten. Rollbacks sind zwar nicht vollständig automatisiert, aber durch erneutes Anwenden des korrekten Playbooks möglich.

Infrastructure from Code: Infrastruktur als Anwendungscode

Beim IfC-Ansatz (Engl. Infrastructure from Code) wird die Infrastruktur auf Grundlage der Anforderungen des angestrebten Zustands der Anwendung direkt im Code definiert. Beim Einsatz von IfC-Tools wie Pulumi oder AWS CDK ist die Anwendung eng mit der Infrastruktur verknüpft.

Infrastruktur-Anforderungen sind nicht mehr in separaten Konfigurationsdateien erfasst, sondern werden mit Hilfe vom Anwendungscode umgesetzt. Die dazugehörigen Tools analysieren den Code und leiten daraus die benötigten Ressourcen und Konfigurationen ab. Der Ansatz ist noch nicht weit verbreitet, aber gewinnt immer stärker an Tragweite.

Monitoring komplexer IT-Infrastrukturen

Netzwerktransparenz ist das A und O

Fallstricke der Cloud-Versionierung

Die Verwaltung von Versionen in der Cloud bringt eine Reihe von Herausforderungen mit sich, die Unternehmen sorgfältig berücksichtigen müssen. Eine zentrale Schwierigkeit liegt in der Kostenkontrolle, denn das Speichern mehrerer Datenversionen kann schnell teuer werden. Ohne klare Richtlinien zur Aufbewahrung und regelmäßige Bereinigung unnötiger Versionen laufen Unternehmen Gefahr, dass Speicherkosten unkontrolliert ansteigen.

Ein weiterer Aspekt ist die Komplexität der Verwaltung. In verteilten Systemen kann es schwierig sein, den Überblick über alle gespeicherten Versionen zu behalten und sicherzustellen, dass Rollbacks oder Wiederherstellungen reibungslos ablaufen. Dies erfordert robuste Automatisierungs- und Überwachungsmechanismen, um Fehler zu vermeiden.

Auch die Daten- und Compliance-Risiken dürfen nicht unterschätzt werden. Veraltete oder unnötige Versionen können unerwartete Sicherheitslücken oder rechtliche Probleme verursachen. Besonders in regulierten Branchen müssen Unternehmen sicherstellen, dass sensible Daten nicht versehentlich in alten Versionen verfügbar bleiben und so gegen Datenschutzvorgaben verstoßen. Hier sind strenge Governance-Richtlinien erforderlich, um den gesamten Lebenszyklus der Versionen zu überwachen und Compliance-Anforderungen lückenlos zu erfüllen.

Cloud-Versionierung verlangt eine sorgfältige Balance zwischen Flexibilität und Kontrolle.

Zusammenfassung

Infrastrukturbereitstellung im Cloud-Maßstab ist eine gewichtige Verantwortung. Jeder Fehler schlägt sich früher oder später in Heller und Pfennig nieder, in Betriebsausfällen der Anwendung oder sogar in Sicherheitspannen. Darum ist die Versionierung von Cloud-Infrastrukturen erfolgskritisch für jede Cloud-Bereitstellung.

Jeder der führenden Hyperscaler befolgt einen eigenen Ansatz. AWS punktet mit tiefen DevOps-Integrationen. Google Cloud liefert starke Automatisierung für datengetriebene Anwendungen. Microsoft Azure besticht mit umfangreichen Governance- und Compliance-Funktionen. Die Versionierung von Multicloud-Infrastrukturen ruft ausgefuchste Lösungen von Drittanbietern auf den Plan. Cloud-Nutzer haben die Qual der Wahl sowohl im Hinblick auf die Herangehensweise als auch hinsichtlich der Toolchains.

IaC wahrt die Trennung zwischen Anwendung und Infrastruktur, während IfC diese beiden Elemente des Cloud-Stacks verschmelzen lässt. GitOps etabliert Git als zentrale Plattform für die Verwaltung und Kontrolle von Infrastrukturversionen, während Werkzeuge des Konfigurationsmanagements auf Task-basierte Versionierung setzen. Unabhängig vom gewählten Ansatz spielt Git fast immer eine zentrale Rolle, wenn es darum geht, Änderungen transparent und nachvollziehbar zu gestalten, um saubere Rollbacks zu ermöglichen. Alternativen umfassen Lösungen wie Terraform Cloud oder Pulumi Cloud.

* Das Autorenduo Anna Kobylinska und Filipe Martins arbeitet für https://www.mckinley-denali.com/corporate/ McKinley Denali, Inc., USA.

(ID:50254998)