Lesezeit: 4 Minuten
Infrastructure as Code (IaC)
Moderne Softwaresysteme zeichnen sich durch ihre Fähigkeit zur Skalierung und ihre Robustheit aus und werden zunehmend für Cloud- und Multi-Cloud-Infrastrukturen entwickelt. Diese Art von Software basiert auf einer Vielzahl von unterschiedlichen Infrastrukturressourcen, deren effizientes Management eine immer größere Herausforderung darstellt.
Infrastructure as Code hat eine Technologie etabliert, mit der die Konfiguration und Verwaltung von Cloud-Infrastrukturen auf dieselbe Weise wie der Anwendungscode verwaltet werden können. Das bedeutet, dass die Konfiguration wie Quellcode in einem Quellcode-Verwaltungssystem (normalerweise in einem Git-Repository) gespeichert wird und als Quelle für weitere Automatisierungsprozesse auf Basis von CI/CD-Pipelines oder GitOps-Bereitstellungen dient. Diese innovative Methode ermöglicht eine effiziente und skalierbare Verwaltung der Infrastruktur und sorgt für eine nahtlose Integration in den Entwicklungsprozess.
Alle Cloud-Anbieter stellen in der ein oder anderen Form Tools für IaC bereit - hier ein paar populäre Beispiele:
- AWS CloudFormation
- Azure Resource Manager
- GCP Deployment Manager
Aufgrund der komplizierten Syntax und ihrer begrenzten Leistungsfähigkeit werden sie jedoch fast nicht verwendet. Das ist einer der Gründe, warum sich Terraform so schnell als Standard für diesen Einsatzzweck entwickelt hat.
Terraform adressiert zwei wesentliche Schwächen nativer Cloud-Tools:
- Komplexität - Die Verwendung der HCL-Sprache in Terraform ist sehr einfach und intuitiv
- Portabilität – Terraform bietet eine Abstraktionsebene, die den Umgang mit Multi-Cloud Szenarien erheblich vereinfacht
Als Terraform eingeführt wurde, gab es kaum Alternativen und im Laufe der Zeit haben sich darüber hinaus auch unsere Anforderungen geändert.
Zwei neue IaC-Tools sind angetreten, um die neuen Herausforderungen anzunehmen und Schwächen von Terraform zu beheben:
- Pulumi
- Crossplane
Pulumi ist eine Open Source Plattform, die gängige Programmiersprachen (TypeScript, Go, .NET, Python, and Java) und Markup Sprachen (YAML, CUE) verwendet, um die Einschränkungen der HCL-Syntax in Terraform zu umgehen. Allerdings geht damit einher, dass der Code komplexer wird und nicht so leicht lesbar und verständlich ist.
Auch Crossplane ist Open Source, jedoch unterscheidet es sich dadurch, dass es ein Projekt der CNCF ist und auf der Kubernetes Control Plane basiert.
Bereitstellung von Infrastruktur mithilfe der Kubernetes-API
Soll die Cloud-Infrastruktur mit einem einfachen Yaml-Dateimanifest bereitgestellt werden, wie in Kubernetes?
Nachstehend ein Beispiel für die EKS-Cluster-Bereitstellung in AWS mithilfe des Claim-Konstrukts in Crossplane:
Angenommen, man bevorzugt Azure AKS statt EKS. Was muss geändert werden, um diese Plattform zu unterstützen?
Es ist in der Tat sehr einfach: Durch die Auswahl eines anderen Clusternamens können wir die EKS-Zusammensetzung durch AKS ersetzen.
Auf die gleiche einfache Art und Weise kann man fast jede Ressource in der Multi-Cloud mithilfe einer ähnlichen, sehr einfachen Yaml-Datei bereitstellen.
Wie funktioniert Crossplane?
Schauen wir uns das CNCF-Inkubationsprojekt Crossplane genauer an.
Crossplane nutzt die Leistung der Kubernetes-API, um eine umfassende Infrastruktur in der Cloud bereitzustellen. Das Tool automatisiert die Synchronisierung mehrerer Umgebungen und ermöglicht die Überwachung des aktuellen Zustands der Infrastruktur. Darüber hinaus erkennt und behebt es automatisch Abweichungen in der Konfiguration.
Crossplane basiert auf vier wesentlichen Konzepten, die es zu einer leistungsstarken Lösung machen:
- Packages - Crossplane ermöglicht die Erweiterung seiner Funktionalität durch den Bau und die Integration neuer Packages.
- Providers - Es ermöglicht die Bereitstellung von Infrastrukturressourcen von externen Anbietern.
- Managed Resources - Crossplane verwendet Kubernetes Custom Resources, um die Eigenschaften der Infrastruktur darzustellen und zu verwalten.
- Composite Resources - Es unterstützt die Erstellung individueller Ressourcen basierend auf den Custom Resource Definitions (CRDs) von Kubernetes.
Diese Konzepte tragen dazu bei, dass Crossplane eine flexible und umfassende Lösung für die Bereitstellung und Verwaltung von Cloud-Infrastrukturen ist. Durch die Integration neuer Packages können zusätzliche Funktionen hinzugefügt werden, während die Nutzung der Kubernetes-API eine nahtlose Integration mit der bestehenden Infrastruktur ermöglicht. Mit Crossplane können Unternehmen die Komplexität der Infrastrukturverwaltung reduzieren und gleichzeitig die Flexibilität und Skalierbarkeit verbessern.
Um auf die Kubernetes-API zugreifen zu können, benötigen wir einen Kubernetes-Cluster. Dies kann entweder ein verwalteter Kubernetes-Cluster in der Cloud oder eine lokale Installation von Kubernetes mit einem Tool wie Rancher oder Orbstack sein. Wichtig ist eine Control Plane, die die Funktionalität der Kubernetes-API unterstützt.
Eine übersichtliche Aufzählung der notwendigen Schritte sieht wie folgt aus:
- Crossplane im Kubernetes-Cluster installieren (z. B. mit Helm-Chart)
- Installation des Providers für die entsprechende Cloud-Plattform sowie die Konfiguration der Zugangsdaten für diese Plattform
- Erstellen einer Custom Resource Definition (CRD), um eine neue Kubernetes-Ressource für die Cloud-Infrastruktur zu definieren
- Erstellen einer Komposition für den erforderlichen Cloud-Anbieter
Details sind in folgendem GitHub Projekt nachzulesen.
Sobald all dies vorhanden ist, ist es möglich, Cloud-Ressourcen mithilfe einer einfachen Yaml-Datei zu erstellen. Durch eine solche Struktur können wir die Komplexität der Cloud-Infrastruktur vollständig verbergen und nur die minimalen Informationen zur Verfügung stellen, die für die Bereitstellung der benötigten Ressourcen erforderlich sind. Dadurch beschränken sich die Ops-Tätigkeiten auf eine möglichst einfache Definition der Infrastruktur, die vom gesamten Entwicklerteam leicht verstanden und übernommen werden kann.
Die Rolle von Operations (Betrieb)
Tauchen wir etwas tiefer in die Ops-Rolle ein.
Normalerweise ist es die Aufgabe des Betriebs, die Infrastruktur zu definieren, da umfangreiche spezifische Kenntnisse über die verschiedenen Cloud-Angebote erforderlich sind. Im Rahmen der Ops-Arbeit erstellen die Software-Ingenieure dann die Crossplane-Artefakte, mit denen sie die Eigenschaften der Ressourcen beschreiben, die für die Bereitstellung der Software auf der definierten Cloud-Infrastruktur erforderlich sind.
Im Falle der ManageKubernetes CRD handelt es sich dabei um folgende Eigenschaften:
- Cluster-ID
- Kubernetes-Version
- Bereitstellungsregion
- Knotengröße
- Anzahl der Knoten
Die CRD Definition ist eine Standard-Kubernetes Erweiterung, welche die Erweiterung von Kubernetes-APIs ermöglicht.
Eine besondere Herausforderung für die Ops-Rolle sind jedoch die Crossplane Compositions. Diese Templates ermöglichen es, mehrere verwaltete Ressourcen in einem einzigen Objekt zu bündeln. Dadurch entstehen größere und komplexere, aber auch wiederverwendbare Ressourcen. Diese stellen eine komfortable Lösung dar, um mit den verschiedenen Cloud-Anbietern in einem Multi-Cloud-Szenario umzugehen und gleichzeitig die Komplexität zu reduzieren.
Fazit
Es ist erstrebenswert, die Infrastruktur in der gleichen Weise zu verwalten wie die Softwareentwicklung, indem man den Infrastrukturcode parallel zum Anwendungscode verwaltet. Obwohl es ein Standardtool namens Terraform gibt, das von den meisten Unternehmen verwendet wird, weist es einige Schwächen auf und stößt bei speziellen Anforderungen in Multi-Cloud- und Kubernetes-Umgebungen an seine Grenzen. In der heutigen Zeit benötigen wir vermehrt Tools, die ähnlich wie die Kubernetes-API funktionieren. Wir möchten gerne definieren, was wir benötigen, und die Umsetzung der Infrastruktur Kubernetes überlassen. Das Tool sollte kontinuierlich den gewünschten Zustand der eingesetzten Infrastruktur überwachen und uns bei der Erkennung von Änderungen und Reparaturen unterstützen. Die gute Nachricht ist, dass es mit Crossplane ein solches Tool gibt, das von der CNCF entwickelt wird. Wir hoffen, dass dieser kurze Einblick dazu ermutigt, das Crossplane-Projekt als möglichen Ersatz für Terraform genauer in Betracht zu ziehen.
