GitOps an der Edge
In den letzten Jahren haben wir beobachtet, dass immer mehr Unternehmen GitOps einsetzen, ein DevOps-Paradigma, das Git als Repository nutzt.
GitOps gibt es bereits seit einigen Jahren, aber aufgrund von Containern und der Komplexität, die mit der konsistenten Bereitstellung und Verwaltung von Container-Laufzeitumgebungen einhergeht, hat es in letzter Zeit an Bedeutung gewonnen.
Was ist das Problem, das GitOps zu lösen versucht? Nun, es automatisiert den Softwarebetrieb, damit Unternehmen ihre Softwareentwicklung verbessern können. Es ermöglicht Anwendungsteams, häufigere Releases durchzuführen und cloudnative Anwendungen effektiver zu betreiben.
In diesem Blog wird untersucht, ob GitOps auf Edge-Topologien angewendet werden kann – insbesondere auf die Erstellung von CI/CD-Pipelines, mit denen Anwendungen auf weit entfernten Edge-Geräten bereitgestellt werden können. Um es noch einmal zu wiederholen: Edge umfasst alle Edge-Geräte bis hin zur Cloud, einschließlich Enterprise Edge und Network Edge.
GitOps ist eine DevOps-Praxis, bei der Git als Single-Source-of-Truth (SSOT) verwendet wird, in der der gewünschte Konfigurationsstatus gespeichert wird. Der Schwerpunkt liegt auf der Automatisierung von Vorgängen, die aus Git-Repositorys gesteuert werden. Obwohl es im Titel steht, ist Git nicht das einzige Repository, das verwendet werden kann. Es sind die von Git bereitgestellten Schnittstellen, die Vorgänge automatisieren. GitOps verwendet letztendlich Informationen, die aus den Build-Metadaten extrahiert wurden, um zu bestimmen, welche Pakete aufgrund einer bestimmten Codeänderung erstellt werden sollen:
Im Kern verwendet das GitOps-Modell das Controller-Muster. Dies wird durch das Operator-Muster aus Sicht von Kubernetes oder OpenShift weiter unterstützt, wobei Operatoren Softwareerweiterungen sind, die benutzerdefinierte Ressourcen zur Verwaltung von Anwendungen und deren Komponenten verwenden.
Wir möchten auch Argo CD erwähnen, ein GitOps-Tool, das bei GitOps-Workflows hilft. Argo CD ist ein Open-Source-Tool für die deklarative kontinuierliche Integration und kontinuierliche Bereitstellung (CI/CD) von Anwendungen. Argo CD wird als Kubernetes-Controller implementiert und überwacht kontinuierlich die laufenden Anwendungsdefinitionen und -konfigurationen, wobei der aktuelle Live-Status im Cluster mit dem in einem Git-Repository definierten Soll-Status verglichen wird.
GitOps ist jedoch kein einzelnes Produkt, Plugin oder Plattform. GitOps-Workflows helfen Teams dabei, die IT-Infrastruktur mithilfe von Prozessen zu verwalten, die sie bereits in der Anwendungsentwicklung einsetzen. Um es mit den Worten eines GitLab-Blogeintrags zu sagen: GitOps erfordert drei Kernkomponenten: GitOps = IaC + PRs oder MRs + CI/CD
- IaC: Infrastructure-as-Code (IaC) bezeichnet die Speicherung der gesamten Infrastrukturkonfiguration als Code. GitOps verwendet ein Git-Repository als Single-Source-of-Truth (SSOT) für Infrastrukturdefinitionen. Git verfolgt alle Änderungen an der Codeverwaltung.
- PRs oder MRs: GitOps verwendet „Pull Requests“ (PRs) oder „Merge Requests“ (MRs) als Änderungsmechanismus für alle Infrastruktur-Updates. Hier können Teams über Überprüfungen und Kommentare zusammenarbeiten und hier finden formelle Genehmigungen statt.
- CI/CD: GitOps automatisiert Infrastruktur-Updates mithilfe eines Git-Workflows mit kontinuierlicher Integration (Continuous Integration, CI) und kontinuierlicher Bereitstellung (Continuous Delivery, CD). Wenn neuer Code zusammengeführt wird, führt die CI/CD-Pipeline die Änderung in der Umgebung durch. Jegliche Konfigurationsabweichungen, wie manuelle Änderungen oder Fehler, werden durch die GitOps-Automatisierung überschrieben, sodass die Umgebung auf den in Git definierten gewünschten Zustand konvergiert und somit einen kontinuierlichen Betrieb (Continuous Operations, CO) gewährleistet:
Red Hat OpenShift-Operatoren vereinfachen die Installation und automatisierte Orchestrierung komplexer Workloads. Sie helfen dabei, die menschliche Betriebslogik zu kodieren, um Services zu verwalten, die als Kubernetes-native Anwendungen laufen, und erleichtern so den Betrieb am zweiten Tag. Der Operator ist eine Software, die in einem Pod auf dem Cluster ausgeführt wird und mit dem Kubernetes-API-Server interagiert. Ein OpenShift-Operator ist im Wesentlichen ein benutzerdefinierter Controller und kann in der Praxis ein anwendungsspezifischer Controller sein.
Red Hat OpenShift erleichtert Entwicklern, die GitOps nutzen möchten, die Arbeit, indem es die erforderlichen Operatoren bereitstellt. Nach der Bereitstellung können sie dann im Abschnitt „Installierte Operatoren“ in der OpenShift-Konsole angezeigt werden. Der Red Hat OpenShift GitOps Operator ist der vorgelagerte Operator für ArgoCD, und der ebenfalls bereitgestellte Red Hat OpenShift Pipelines Operator ist der vorgelagerte Operator für Tekton. Siehe Abbildung 3:
Die Operatoren und zugehörigen APIs können dann verwendet werden, um eine oder mehrere GitOps-Pipelines zu starten, die in verschiedenen Umgebungen bereitgestellt werden können und das gewünschte Konfigurationsergebnis aus Git abrufen. Bei den Umgebungen kann es sich um die üblichen Entwicklungs-, Test- und Produktionsumgebungen handeln, sie können aber auch geografische Umgebungen wie die Unternehmenscloud, Telekommunikationsnetzwerke oder Edge-Computing-Knoten umfassen.
Die Bereitstellungsressourcen werden in drei Bereiche unterteilt: Infrastruktur, Services und Anwendungen. Diese Bereiche erleichtern die Trennung und Verwaltung der Bereitstellung von zusammenhängenden Ressourcen:
- Infrastruktur ist der Ort, an dem die erforderlichen Namespaces und Speichereinheiten definiert werden.
- Unter Services werden die verschiedenen Operatoren beschrieben, die zum Einrichten der Instanzen erforderlich sind.
- Unter Anwendungen werden die bereitzustellenden Anwendungen aufgeführt.
In einem früheren Blogbeitrag haben wir DevOps im Bereich Edge Computing behandelt. Hier sehen wir uns nun an, wie GitOps im Edge Computing angewendet werden kann. Wir haben auf die drei Bereiche des Edge-Computing hingewiesen:
- Enterprise Edge
- Netzwerk-Edge
- Geräte-Edge (oder Remote-Edge)
Es gibt auch die Cloud oder das Unternehmensrechenzentrum. Sehen wir uns diese Bereiche im Detail an. Neben den Edge-Umgebungen zeigt Abbildung 4 auch die drei GitOps-Bereiche: Infrastruktur, Services und Anwendungen.
Cloud-/Unternehmensrechenzentrum
Edge Computing führt in den meisten IT-Zentren zu einer zunehmenden Verbreitung von OpenShift- oder Kubernetes-Clustern. Es hat das Potenzial, eine enorme Größenordnung von Hunderten bis Tausenden von Bereitstellungen pro Kunde zu erreichen. Das Ergebnis ist, dass IT-Abteilungen in Unternehmen mehrere unabhängige oder kooperative Container-Laufzeit-Cluster verwalten müssen, die On-Prem und/oder in Public Clouds ausgeführt werden.
Sicherzustellen, dass Cluster denselben gewünschten Zustand aufweisen – das Ausrollen einer Änderung und das Zurücksetzen einer Änderung in mehreren Clouds – ist ein wesentlicher Vorteil, den GitOps für Edge- und IoT-basierte Unternehmen bietet.
Netzwerk-Edge
Das GitOps-Paradigma ist am Netzwerkrand anwendbar, da eine der größten Herausforderungen für Kommunikationsdienstleister (CSPs) darin besteht, ihre Netzwerke zu orchestrieren, zu automatisieren und zu verwalten. Während 5G für Verbraucher ein Segen ist, stellen softwaredefinierte Netzwerke (SDNs), Network Slicing mit unterschiedlichen Bandbreiten und eine schnellere Bereitstellung die Telekommunikationsanbieter vor Herausforderungen.
Eine automatisierte Bereitstellungspipeline ist eine Möglichkeit für CSPs, ihren Kunden Dienste schneller zur Verfügung zu stellen. Ein zentrales Repository und ein deklarativer Ansatz für die Bereitstellung der Container-Infrastruktur bedeuten eine schnellere Markteinführung neuer Funktionen und Änderungsanforderungen. Ein solches Paradigma wird die Bereitstellung von VNFs (Virtual Network Functions) und CNFs (Cloud-Native Network Functions) am Netzwerkrand unterstützen. Die Containerisierung von Netzwerkkomponenten ermöglicht die Verwaltung solcher Funktionen. Da alle Konfigurationsaktivitäten protokolliert und in Git gespeichert werden, ist die Möglichkeit, Änderungen nachzuverfolgen, für Compliance- und Audit-Zwecke von entscheidender Bedeutung. In den Referenzen finden sich einige verwandte Blogs von WeaveWorks:
Enterprise Edge
Mit GitOps können Unternehmen gleichzeitig auf mehrere Ziele bereitstellen. Es ermöglicht die Einführung detaillierter Bereitstellungen. Dies wäre äußerst nützlich bei der Bereitstellung von Anwendungen auf Hunderten und Zehntausenden von Edge-Knoten, die unterschiedliche Formen und Formfaktoren aufweisen und verschiedene Kommunikationsprotokolle verwenden – insbesondere wenn es sich bei den Edge-Knoten um kleine Edge-Cluster handelt, die einen Intel NUC oder NVIDIA Jetson verwenden.
Das GitOps-Framework kann bei der Bereitstellung von Anwendungen und der Verwendung des Git-Repositorys als Single-Source-of-Truth (SSOT) von Vorteil sein. ITOps-Teams streben eine autonome Anwendungsbereitstellung, Verwaltung und den autonomen Betrieb von Edge-Knoten an, was durch den Einsatz von Red Hat OpenShift-Operatoren erleichtert wird.
Geräte-Edge (oder Remote-Edge)
Der Vorteil von GitOps liegt am Netzwerkrand und am Unternehmensrand auf der Hand. Die Ear-Edge-Geräte stellen eine andere Herausforderung dar, da die Speicher- und Rechenkapazität einiger dieser Geräte nicht groß genug ist, um GitOps-Services zu hosten und Anwendungen auszuführen.
Die Veröffentlichung von leichtgewichtigen Kubernetes-Distributionen wie K3s und K0s ist für IoT- und Edge-Anwendungsfälle gedacht. Die Möglichkeit, eine schlanke Kubernetes-Distribution auf einem Edge-Gerät einzusetzen, ermöglicht es uns, ein GitOps-Tool wie Argo CD auszuführen. Das/die Gerät(e) kann/können dann das Pull-Modell anwenden, um ein Git-Repository nach dem gewünschten Zustand abzufragen und diesen mit dem Live-Zustand des Clusters zu synchronisieren.
Durch den Einsatz von GitOps lösen Sie die Probleme der unkontrollierten Ausbreitung von Infrastruktur- und Anwendungskonfigurationen. Der in Red Hat OpenShift integrierte GitOps-Operator erleichtert die Implementierung einer Argo CD-gesteuerten Pipeline. Kunden von IBM Cloud Paks, einschließlich IBM Cloud Pak for Network Automation, können Red Hat-Operatoren zur Installation von Ressourcen nutzen und das GitOps-Framework zur Automatisierung und Steuerung des Bereitstellungsprozesses einsetzen.
Das IBM Cloud Native Toolkit ist ein guter Ausgangspunkt. Es handelt sich um eine Open-Source-Sammlung von Assets, die die Anwendungsentwicklung und den Einsatz von Ops ermöglichen.
Besonderer Dank gilt Hollis Chui und Kavitha Bade für die Überprüfung des Artikels.