GitOps: Was den IT Operations Dampf macht

Der Development-Booster

Von Roland Freist

Der Name GitOps lässt an DevOps denken. Doch tatsächlich hat dieses Konzept damit nur wenig zu tun. Denn bei DevOps geht es um das Etablieren von technischen Methoden und einer Kultur für die Zusammenarbeit zwischen Entwicklern (Development = Dev) und den Mitarbeitern, die den IT-Betrieb organisieren und aufrechterhalten (Operations = Ops). GitOps hingegen konzentriert sich, wie der Name schon andeutet, auf die Organisation des IT-Betriebs mittels der quelloffenen Versionskontrolle Git. GitOps kann Teil eines DevOps-Konzepts sein, muss es aber nicht.

Wie funktioniert GitOps?

Das lässt sich am einfachsten erklären, indem man das Konzept dem Verfahren Continuous Delivery (CD) über einen Continuous-Integration-Server (CI-Server) gegenüberstellt. Continuous Delivery bedeutet, dass die Entwickler ihre Änderungen am Code einer Applikation kontinuierlich in der Sourcecode-Verwaltung, dem Git-Repository, ablegen. Von dort übernimmt der CI-Server die Daten, kompiliert den Code zu Builds und führt Tests durch. Die aus den Builds entstandenen Applikationen legt er auf einem Server ab und kümmert sich anschließend um das Deployment.

Auch das GitOps-Konzept beginnt damit, dass die Entwickler ihre Codes an das Git-Repository übergeben. Das Deployment erfolgt jedoch in diesem Fall nicht über den CI-Server – er ist nur noch für das Kompilieren der Builds und die Tests zuständig. Stattdessen synchronisiert sich die Betriebsumgebung über eine Pull-Anfrage mit dem Git-Repository und überprüft anschließend kontinuierlich in einer Schleife, wie stark die Abweichungen vom definierten Zielzustand sind, und gleicht dabei den Code immer stärker an das gewünschte Ergebnis an. Die Änderungen am Code werden lückenlos im Git abgelegt und dokumentiert und können von dort jederzeit abgerufen werden. In diesem Prozess lassen sich auch Code-Fehler automatisch beheben. Das Continuous Deployment (CD) erfolgt dann ebenfalls über die Betriebsumgebung, bei der es sich in den meisten Fällen um einen Kubernetes-Cluster handelt.

Höherer Automatisierungsgrad, mehr Transparenz

Dieses Verfahren weist gleich mehrere Vorteile auf: So lässt sich mit GitOps ganz generell ein standardisierter Workflow für die Entwicklung von Anwendungen etablieren. Gegenüber anderen Verfahren bietet das GitOps-Konzept jedoch im Vorfeld einer Entwicklung eine höhere Sicherheit, was die Anforderungen der Anwendung anbelangt. Gleichzeitig sind GitOps-Projekte aufgrund der Kontrolle durch Git grundsätzlich transparenter.

Die Entwickler können den aktuellen Stand des Projekts jederzeit bis aufs Detail überprüfen und die vorherigen Schritte nachvollziehen. Die Operations-Teams können bei Problemen verhältnismäßig einfach den Punkt finden, an dem die Entwicklung in eine falsche Richtung lief und sich Fehler eingeschlichen haben. Unternehmen verringern auf diese Weise das Risiko, dass aufgrund von Bugs die bereits fertigen Produkte in einer späten Phase ihrer Entwicklung noch einmal kostenintensiv geändert werden müssen. Stattdessen gewinnen sie durch die Automation des Entwicklungsprozesses und die Möglichkeiten zur schnellen Anpassung des Codes eine hohe Flexibilität, um auf Veränderungen in der Geschäfts- und Wettbewerbssituation schnell reagieren zu können.

Und: Die Entwickler müssen nicht auf die Ergebnisse anderer Teams warten, sondern können in ihrem eigenen Rhythmus arbeiten. Mit GitOps ergibt sich zudem eine Konsistenz bei der Entwicklung über unterschiedliche Cluster, Clouds und On-premises-Umgebungen hinweg.

Deklarative Programmierung

Mit GitOps setzt ein Unternehmen eine vollständig deklarative Programmierung um. Es steht also das Was im Vordergrund und nicht, wie bei der imperativen Programmierung, das Wie. Das lässt einen erheblich höheren Automatisierungsgrad zu. Bei deklarativen Programmiersprachen wie Haskell, Lisp oder auch Prolog beschreibt der Entwickler lediglich, was das Programm mit einer Eingabe machen soll. Der Ablauf der Berechnung ist dabei nicht von Interesse.

Ein weiterer Vorteil ist die erweiterte Sicherheit eines GitOps-Systems: Denn der Kubernetes-Cluster greift bei Datenabfragen nahezu ausschließlich auf Git zu, das Git-System ist seine Single Source of Truth. Zugriff auf andere Quellen lassen sich beinahe komplett reduzieren. Und: Zwischen dem CI-Server und dem Cluster besteht keine direkte Verbindung mehr. Auf dem Server müssen daher auch keine Anmeldeinformationen mehr hinterlegt werden, was wiederum die Sicherheit des Gesamtsystems erhöht. Und schließlich ist der Zugriff auf Git in der Praxis auch einfacher umzusetzen als der Zugriff auf eine API.

Die Basis: Infrastructure as Code

Eine wichtige Rolle im GitOps-Umfeld spielt Infrastructure as Code (IaC). Der Ausdruck erinnert an Infrastructure as a Service (IaaS), und tatsächlich ist das Konzept eng mit diesem Cloud-Computing-Modell verwandt. Es geht um einen Ansatz in der IT, bei dem Infrastruktur-Leistungen wie Computing (Rechenleistung), Storage und Networking über Skripte und/oder Programme beschrieben werden. Die Leistungen der Infrastruktur lassen sich damit schnell, kostengünstig und in praktisch beliebigem Umfang bereitstellen, anpassen und erweitern. Voraussetzung dafür sind lediglich eine virtualisierte Umgebung und möglichst eine Public-Cloud-Infrastruktur. IaC ist allerdings auch in einer On-premises-Umgebung in einer Private Cloud denkbar.

Wenn ein Unternehmen sich für GitOps entscheidet, nutzt es die Versionskontrolle Git für die Bereitstellung von IaC. Der CI-Server prüft und kompiliert in diesem Fall den Code der IaC-Umgebung, während das Continuous Deployment die Anforderungen an die Sicherheit und andere Limitierungen prüft und anwendet. GitOps kann aber auch mit IaC-Tools wie beispielsweise Terraform zusammenarbeiten. Die Software der amerikanischen HashiCorp wurde entwickelt, um die Infrastruktur in Cloud-Umgebungen als Code umzusetzen und Aufgaben wie beispielsweise die Provisionierung von Servern, Datenbanken, Firewall-Policies oder auch Kubernetes-Clustern zu automatisieren.

Kubernetes ist nahezu unabdingbar

Eine weitere enge Verwandtschaft besteht zwischen GitOps und der Container-Verwaltung Kubernetes. Der GitOps-Operator, oftmals auch als Custom Controller bezeichnet, gleicht kontinuierlich den im Git beschriebenen Zielzustand mit dem Ist-Zustand des Kubernetes-Clusters ab und passt ihn bei Änderungen entsprechend an. Dabei kommen Tools wie Flux oder ArgoCD zum Einsatz. Mittlerweile funktioniert das allerdings nicht nur mit Kubernetes, sondern auch mit einer Reihe anderer Betriebsumgebungen.

GitOps wird in der Industrie häufig eingesetzt, um Anwendungscontainer in Kubernetes zu deployen. Genauso ist es aber auch möglich, mit GitOps-Operatoren ganze Kubernetes-Cluster einzurichten. Dabei zeigen sich dann auch die besonderen Stärken des GitOps-Konzepts: Denn man kann damit weitgehend automatisiert gleich mehrere Cluster parallel konfigurieren.

Eine Möglichkeit zum Ausrollen von Kubernetes-Clustern ist die Cluster API, ein Projekt aus dem Kubernetes-Umfeld, das sich der Entwicklung von deklarativen APIs und Tools für die Provisionierung, das Upgrade und den parallelen Betrieb mehrerer Cluster verschrieben hat. Darüber hinaus existiert noch eine ganze Reihe weiterer IaC-Tools, die sich für die Nutzung im Rahmen eines GitOps-Konzepts anbieten. Die Mehrheit darunter zielt jedoch ebenfalls auf einen Einsatz als Kubernetes-Operator. Der Einsatz von GitOps ohne Kubernetes ist daher zwar theoretisch ohne weiteres möglich, in der Praxis fehlen dafür jedoch in den meisten Fällen die benötigten Werkzeuge.

Fazit: Optimierte IT-Operations

Mit Git als Single Source of Truth soll den IT-Operations noch einmal Dampf gemacht werden. Auf diesem vollständig deklarativen Level von Infrastructure as Code erreicht die Automatisierung neue Dimensionen: Nach dem Pull-Prinzip verfolgt das System den hinterlegten Zielzustand quasi „von selbst“. Das Deployment von Anwendungen mithilfe von GitOps ist mittlerweile eine ausgereifte Technik. Auch das Einrichten von (Kubernetes‑)Clustern funktioniert bereits recht gut. Die Verwaltung physischer Infrastruktur mit GitOps steckt derzeit jedoch noch in den Kinderschuhen.

Nützliche Links

• App-Portabilität
• Berufsbild DevOps Engineer
• Container Security
• Datacenter Automation
• Site Reliability Engineer