Continuous Deployments für Cloud-Native-Infrastrukturen 11 Gründe für die Einführung von GitOps

Anbieter zum Thema

VON ZUR MÜHLEN'SCHE GmbH

GitOps ist für alle in greifbare Nähe gerückt: Denn mit Kubernetes lassen sich Deployments von Anwendungen und Infrastruktur-Komponenten rein über deklarative Konfigurationsdateien verwalten, die in einem Git-Repository liegen. Aber was spricht eigentlich für diesen Ansatz?

Als Entwickler ist es problemlos möglich, YAML-Dateien in ein Git-Repository hochzuladen und dieses an eine Pipeline wie Jenkins oder GitLab anzuschließen. Diese nimmt dann jegliche Änderungen an einem Container Cluster vor – et voilà: haben wir GitOps.

Damit das reibungslos funktioniert, müssen wir sicherstellen, dass ein Commit in das Git-Repository der einzige Weg ist, Änderungen am Cluster vorzunehmen. GitOps ist nicht Kubernetes-spezifisch, das gleiche Prinzip lässt sich auf jede Umgebung übertragen, die durch Terraform, CloudFormation oder andere deklarative Tools für das Konfigurationsmanagement verwaltet wird.

Viele nutzen bereits entsprechende Ansätze, aber mittlerweile realisiert auch der Großteil der IT-Branche das volle Potenzial von GitOps. Damit kommen wir auch gleich zu den Gründen, warum GitOps so großartig ist:

1. Änderungshistorie für Umgebungen

Eine Anwendungsumgebung kann nur durch Updates der Konfiguration im zugehörigen Git-Repository verändert werden. Dies bedeutet eine komplette Historie der gewünschten Zustandsänderungen – einschließlich einer Aufzeichnung, wer diese Änderung durchgeführt hat und weshalb. Diese Historie kann außerdem auch durch die bereits genutzte und geschätzte Git-Benutzeroberfläche gelesen werden.

2. Rollback auf früheren Zustand

Sobald all unsere Änderungen als Git-Historie gespeichert werden, ist es einfach, eine Umgebung auf einem beliebigen früheren Zustand zurückzurollen. Durch das Rückgängigmachen von ein paar Commits können wir zu einem Zustand zurückkehren, der zuvor funktionierte.

3. Sichere Deployment-Prozesse

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

Sobald alle Änderungen am Cluster durch das GitOps-Repository gehen, benötigen menschliche und maschinelle Nutzer (sprich der Continuous-Integration- also CI-Prozess selbst) keinen Zugriff auf den Cluster mehr. Dies reduziert die Angriffsoberfläche immens, vor allem wenn dies bedeutet, den Netzzugriff auf die Kubernetes API zu reduzieren.

Der Deployment-Prozess, unabhängig von seiner Implementierung, kann innerhalb des Clusters laufen und die Konfiguration aus Git laden. Der Zugriff auf die API ist durch rollenbasierte Zugriffskontrolle (englisch RBAC, Role-Based Access Control) beschränkt. Das erhöht die Sicherheit des Clusters, da jegliche böswilligen Änderungen über den „allmächtigen“ API-Server verhindert werden.

4. Leichtgewichtige Zulassungsverfahren

Entwickler dürfen in vielen Firmen nicht die Produktionsumgebungen modifizieren. Was auch immer hinter dem Misstrauen und der Forderung nach einem Vier-Augen Prinzip steckt, GitOps liefert einen simplen Weg, dieses zu implementieren.

Die genaue Implementierung hängt vom genutzten Git-Server ab; aber grundsätzlich besteht die Strategie darin Entwicklern die Berechtigung zu erteilen, Pull-Requests an das Git-Repository zu stellen, während eine andere Gruppe das Recht auf Reviews und Merges hat. Die meisten Git-Server bieten eine exzellente Benutzeroberfläche, um Änderungen zu begutachten und Pull-Requests zu genehmigen – diese Lösung ist also nicht nur günstig, sondern auch sehr benutzerfreundlich.

5. Modulare Architektur

GitOps besteht aus drei Teilen: dem Git-Repository, dem Deployment-Prozess und wahrscheinlich einem Prozess, der Versionsupdates im Git-Repository automatisiert. Alle drei können sich weiterentwickeln oder unabhängig voneinander ersetzt werden.

Einerseits schreibt eine Komponente in das Git-Repository, andererseits liest eine Komponente davon. Die Struktur des Git-Repositories ist damit der Vertrag zwischen diesen Komponenten.

Da dies eine ziemlich lockere Verkopplung ist, können beide Seiten auf verschiedene Weisen mit unterschiedlichen Technologien implementiert werden.

6. Tool-unabhängige Architektur

Die Modularität aus Punkt 5 führt uns direkt zu der Tatsache, dass eine GitOps-Architektur die besten Tools auf flexible Weise zusammenführt. Quasi jeder bekannte Git-Server tut es für den Git-Teil – und Flux oder ArgoCD können sich derweil darum kümmern, das Repository und das Cluster zu synchronisieren.

JenkinsX wiederum ist ein Tool, das alle Teile dieses Prozesses abdecken kann. Das schließt auch die Erstellung von Git-Repositories und das Updaten zu neuen Versionen ein, sobald ein neues Docker Image gebaut wurde.

7. Bestehendes Wissen nutzen

Durch die Nutzung von Git im Zentrum des Deployment-Prozesses kann man auf das bestehende Git-Know-how setzen, das die meisten Entwickler und IT-Mitarbeiter bereits haben. Es besteht keine Notwendigkeit, neue Tools einzuführen, um Deployment-Historien zu durchsuchen oder Commits zu implementieren. Alles passiert mithilfe von Tools, die jeder kennt.

8. Vergleich verschiedener Umgebungen

Wenn man von der Entwicklung über Akzeptanztests (englisch: User Acceptance Testing, UAT) bis hin zur Produktion eine ganze Reihe an Umgebungen einsetzt, kann es sehr aufwändig sein, all ihre Unterschiede im Auge zu behalten.

Dank deklarativer Konfigurationen in Git-Repositories ist der Vergleich nun so einfach wie zwischen einer Gruppe von YAML-Dateien. Es existieren sehr gute Tools, die eine entsprechende Umsetzung ermöglichen. Darüber hinaus ist das Erstellen einer neuen Umgebung von Grund auf äußerst einfach: man muss nur noch die angepassten YAML-Dateien in ein neues Repository kopieren.

9. Integrierte Backups

Da der Zustand der Umgebung in Git gespeichert ist, wird nie etwas verloren gehen, selbst wenn dem etcd-Speicher des Kubernetes-Clusters etwas passiert. So wird automatisch auch der Zustand des Clusters gesichert.

10. Änderungen wie bei Software testen

Man kann Änderungen, die eventuell den Cluster zerstören, auf die gleiche Weise testen wie man es mit Anwendungen tun würde. Man muss die Änderungen schlicht auf einen Branch schieben und durch eine CI-Pipeline laufen lassen. Das CI-Tool ist in der Lage, Tests auszuführen und den Status des Pull-Requests abhängig vom Ergebnis auf grün oder rot zu setzen.

Sobald alles getestet und überprüft ist, darf der Code auf den Masterbranch gemerged werden. Das klingt sehr unkompliziert, aber automatisierte Tests sind eine oftmals vernachlässigte Aufgabe in der Verwaltung von Infrastrukturen. GitOps macht das nicht leichter, aber man vertraut zumindest auf den bereits bekannten Git-Workflow, den man auch an anderen Stellen nutzt.

11. Hochverfügbare Deployment-Infrastruktur

Es ist wichtig, Deployment-Infrastrukturen dauerhaft aufrecht zu erhalten. Git-Server sind gewöhnlich schon auf eine replizierte, hochverfügbare Art und Weise aufgesetzt. Alle Entwickler benötigen die meiste Zeit einen Zugriff auf Quellcode, also ist der Gebrauch von Git als Deployment-Quelle keine zusätzliche Belastung für Git selbst.

* Ádám Sándor ist ein Cloud Native Architekt bei Container Solutions, einem Dienstleistungs- und Beratungsunternehmen mit Standorten in Europa, UK und Kanada.

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:46388105)