Git für deklarative Anwendungsumgebungen nutzen GitOps – die bessere Art, DevOps zu machen

DevOps führt als agile Arbeitsmethode die unterschiedlichen Bereiche der Softwareentwicklung zusammen GitOps optimiert derweil die technische Umsetzung und ist eine effektive Alternative zu Continuous-Integration- und -Delivery-Systemen.

In der Softwareentwicklung gibt es immer wieder neue Ansätze zur Verbesserung der Effizienz des IT-Betriebs und zur Beschleunigung von Prozessen. Hierbei war der DevOps-Ansatz bereits eine kleine Revolution, denn mit ihm gelingt eine effizientere Zusammenarbeit der Bereiche Entwicklung (Development), IT-Operations und Qualitätssicherung.

Der DevOps-Ansatz zielt allerdings lediglich auf die Unternehmenskultur und führt die Teams in den unterschiedlichen Bereichen der Softwareentwicklung in einem Prozess zusammen. Die technische Umsetzung findet jedoch weiterhin in Handarbeit oder automatisiert mit Continuous-Integration- und -Delivery-, kurz CI/CD-Systemen statt.

Mit GitOps gibt es inzwischen einen völlig neuen Ansatz, der konkret auf den IT-Betrieb (Operations) fokussiert ist. Im Gegensatz zu CI/CD wird hier der Sollzustand der Produktionsumgebung deklarativ beschrieben und durch spezielle Software kontinuierlich mit dem Ist-Zustand verglichen. Abweichungen und Fehler werden automatisiert korrigiert, um den Zielzustand herzustellen.

Prinzipiell ist es möglich, GitOps ohne DevOps und DevOps ebenso ohne GitOps umzusetzen. Aber beide Ansätze ergänzen sich bestens und es ist sinnvoll, sie gemeinsam zu nutzen. Alexis Richards, Erfinder des Begriffs GitOps, sieht darin sogar den richtigen Weg, um DevOps zu machen.

Das bisherige Vorgehen mit CIOps

GitOps lässt sich am deutlichsten im Vergleich zu CI/CD-Pipelines beschreiben, die mittlerweile zur besseren Unterscheidung als CIOps bezeichnet werden. Bei einer klassischen CIOps-Pipeline mit Staging- und Produktionsumgebung kann die Automatisierung des Deployments durch die Verwendung von Branches in der Versionsverwaltung, z.B. Git, umgesetzt werden.

Der Develop-Branch enthält den integrierten Entwicklungsstand, der Main-Branch die produktiven Versionen: Jeder Push auf Develop führt zu einem Deployment auf Staging, jeder Push auf Main geht in die Produktion. Damit steht die letzte integrierte Version auf Staging für Tests bereit und das Deployment kann durch einen Pull Request auf Main angestoßen werden.

Ein ausführliches Beispiel ist in dem Artikel „Coding Continuous Delivery — Statische Code Analyse mit SonarQube und Deployment auf Kubernetes et al. mit dem Jenkins Pipeline Plugin“ beschrieben. Nachteil ist, dass der Prozess langsam ist, da für jedes Deployment ein Build im CI-Server durchlaufen werden muss. Eigentlich ist aber gar kein neuer Build notwendig, da das gleiche Artefakt auf allen Stages deployt werden könnte.

Funktion und Vorteile des GitOps-Ansatzes

GitOps hat demgegenüber den Vorteil, dass eine Anwendung nur einmal gebaut werden muss und anschließend das Artefakt in unterschiedlichen Umgebungen deployt werden kann. Im Git-Repository ist der gewünschte Zustand des Systems beschrieben und der GitOps-Operator prüft nach dem Pull-Prinzip den Ist-Zustand des Clusters kontinuierlich gegen diesen Soll-Zustand.

E-Book zum Thema

Unser eBook „Ein kleiner GitOps-Guide“ befasst sich mit den Grundprinzipien von GitOps und zeigt einige Tools und Best Practices für die GitOps-Pipeline auf.

eBook herunterladen

Auf diese Weise lassen sich keine Änderungen nach dem Push-Prinzip in die Produktion überführen und die kontinuierliche Integration einer Anwendung ist vom eigentlichen Deployment-Prozess getrennt. Das heißt, der CI-Server übernimmt nicht mehr das Deployment, sondern führt nur noch Build und Tests durch. GitOps wird über Tools implementiert, die das deklarative Abbild aus Git kontinuierlich mit dem System spiegeln und sicherstellen, dass dieses dieselbe Konfiguration enthält wie in Git beschrieben und umgekehrt.

Durch den GitOps-Ansatz entstehen mehrere Vorteile: Von außen wird kein Zugriff auf den Cluster benötigt, da der GitOps-Operator Deployments durchführt und sich dieser innerhalb des Clusters befindet. Darüber hinaus ist der Zugriff auf Git oft einfacher zu organisieren als der zu einem API-Server. Nicht nur, dass gegebenenfalls eine Firewall-Freischaltung entfällt, auch die Entwicklungsteams sind mit Git vertraut.

Diese GitOps-Tools und -Werkzeuge gibt es

GitOps ist im Umfeld von Kubernetes (K8s) entstanden und findet inzwischen unabhängig davon Anwendung. Allerdings haben die meisten Tools noch einen Bezug zu Kubernetes, da dieser Ansatz bisher weit verbreitet und die Toolunterstützung am besten ist. Dem Bericht „The State of Kubernetes 2020“ zufolge, nutzen mehr als die Hälfte der Unternehmen K8s-Cluster.

Im Kontext von GitOps sind Tools sogenannte Operatoren, die auch als Custom Controller bezeichnet werden und auf einem K8s-Cluster laufen, wo sie Betriebsaufgaben automatisieren. Sie führen die Abstimmungsschleife (Reconciliation Loop) aus, die den im Git-Repository beschriebenen Soll-Zustand mit dem Ist-Zustand des Cluster synchronisiert.

Die populärsten und am weitesten verbreiteten Tools sind Flux und Argo CD, die beide aktiv von ihren Communities weiterentwickelt werden. Flux ist von der CNCF (Cloud Native Computing Foundation) Endanwender Community im Juni 2020 als „adopt“ eingestuft und damit für die Einführung empfohlen worden. Während Argo CD ein sehr breites Funktionsspektrum aufweist, ist Flux deutlich einfacher gestaltet und hat weniger Funktionen.

Im Unterschied zu anderen Tools benötigen jedoch beide einen zusätzlichen CI-Server. Operatoren wie zum Beispiel Jenkins-X sind dagegen eine vollständige CI/CD-Anwendung. Weitere Tools sind Fleet und werf, das außerhalb des Clusters läuft und trotzdem Kubernetes-Ressourcen wie ein Operator aus Git auf einem Cluster anwendet.

Weitere wichtige Tools und Operatoren für GitOps

Wie bereits erwähnt ist der zentrale Bestandteil in GitOps die vollständige deklarative Beschreibung des Zustands in Git. Dadurch sind aber manche Dinge nicht mehr direkt umsetzbar und es werden weitere Operatoren benötigt. Diese erweitern den Kubernetes API-Server um sogenannte Custom Resource Definitions (CRDs) und stellen Custom Resources (CRs) bereit, die eine deklarative Beschreibung des Zustands ermöglichen.

So können zum Beispiel Templating-Werkzeuge wie Helm oder Kustomize weiterhin verwendet werden, indem entsprechende Helm- oder Kustomize-Operatoren verwendet werden. Diese übernehmen dann das Templating oder Overlay. Eine Alternative zum Operator wäre es, das Templating-Ergebnis über eine CI-Pipeline direkt ins Git zu schreiben, was jedoch mit einer schwerer wartbaren YAML-Beschreibung im Git einhergeht.

Weitere Operatoren sind für die Ver- und Entschlüsselung mit GitOps notwendig, da durch das Speichern des gesamten Zustands in Git Secrets dort landen. Während das Tool Sealed Secrets das Schlüsselmaterial im Cluster selbst verwaltet, kommt es bei SOPS aus Key-Management-Systemen (KMS) großer Cloud-Anbieter, selbst verwalteten PGP-Schlüsseln oder einem eigenen HashiCorp Vault. Um SOPS mit GitOps zu verwenden, sind Operatoren notwendig, wie zum Beispiel das Plug-in helm_secrets. Kamus ist eine Art Kompromiss zwischen Sealed Secrets und SOPS, das einen Operator mitliefert und das Schlüsselmaterial selbst oder von den KMS der Cloud-Anbieter bezieht.

GitOps ausprobieren

Im ersten Moment kann das GitOps-Prinzip mit den vielen unterschiedlichen Operatoren schwer nachvollziehbar sein. Ein anschauliches Beispiel für die Umsetzung von GitOps bietet der quelloffene GitOps Playground.

Das Repository beinhaltet eine komplette reproduzierbare GitOps-Infrastruktur mit Kubernetes Cluster, CI-Server (Jenkins), Source Code Management (SCM-Manager) und unterschiedlichen GitOps-Operatoren (Flux und ArgoCD), auf der die Komponenten bereits mit Beispielapplikationen vorkonfiguriert sind.

* Daniel Huchthausen nutzt seine langjährige Erfahrung als IT-Consultant dafür, die komplexen Sachverhalte rund um moderne Softwareentwicklung verständlich zu vermitteln. Die Cloudogu GmbH hat es sich zum Ziel gesetzt, den gesamten Product Lifecycle der Softwareentwicklung durch ein einfach nutzbares Toolset abzubilden, das durch Standardisierung und Automatisierung dazu beiträgt, Software noch effizienter entwickeln zu können.

E-Book zum Thema

Ein kleiner GitOps-Guide

GitOps soll die Cloud-native Entwicklung containerisierter Anwendungen von Grund auf umkrempeln. Unser eBook „Ein kleiner GitOps-Guide“ befasst sich mit den Grundprinzipien von GitOps und zeigt einige Tools und Best Practices für die GitOps-Pipeline auf.

Im eBook erfahren Sie mehr über:

• GitOps-Prinzipien, Vorteile und Alternativen
• Tooling für GitOps
• Troubleshooting von GitOps-Pipelines

eBook „Ein kleiner GitOps-Guide“ herunterladen

(ID:47536973)