Author
Im Jahr 2017 stellte Weaveworks, ein Start-up im Bereich Kubernetes-Lösungen, das Konzept „GitOps“ vor – eine Reihe von Best Practices für die Anwendungsbereitstellung und -verwaltung unter Verwendung von Cloud-nativen Tools und Cloud-Diensten, die als Erweiterung des DevOps-Ansatzes für die Softwareentwicklung positioniert sind.
Weaveworks basiert auf einem GitOps Operator namens Flux, einer Open-Source-Software, die in einem Kubernetes- oder einem OpenShift-Cluster läuft. Die Rolle von Flux besteht darin, eine automatisierte Überwachung bereitzustellen, die garantiert, dass der Status eines Kubernetes-Clusters mit der in Git gelieferten Konfiguration übereinstimmt.
GitOps ist jedoch mehr als nur Flux oder alternative Überwachungswerkzeuge wie Argo CD oder Jenkins X. Der Ansatz basiert auf DevOps sowie Site-Reliability-Engineering (SRE) und ist zum neuesten Trend in der Cloud-nativen App-Entwicklung und -Bereitstellung geworden.
Wenn es sich hierbei nicht nur um ein Tool handelt, was genau ist GitOps eigentlich? Welche Vorteile bieten die bewährten Praktiken für DevOps-Teams und die Entwicklung? Und was sind letztendlich die geschäftlichen Gründe für Organisationen, GitOps als Teil einer DevOps CI/CD-Pipeline einzuführen?
Das sind einige der Fragen, die wir hier ansprechen werden und die gleichzeitig beantworten, warum GitOps vollständig in die DevOps-Dienste von K&C integriert ist.
Was genau ist GitOps?
Weaveworks beschreibt GitOps als Betriebsmodell für Kubernetes und andere Technologien, die in der Cloud-nativen Entwicklung verwendet werden. GitOps liefert…
- …eine Reihe von Best-Practices, die Bereitstellung, Verwaltung und Überwachung von Container-Clustern und -Anwendungen vereinheitlichen.
- …einen entwicklerfreundlichen Weg zur Verwaltung von Anwendungen, in welchem end-to-end CICD-Pipelines und Git-Workflows für Operationen und Entwicklung umgesetzt werden.
Eine erweiterte Definition von GitOps gibt an, dass es sich hierbei um einen Standard zur kontinuierlichen Bereitstellung für Cloud-native Anwendungen handelt, der sich auf eine Entwickler-zentrische Erfahrung für den Infrastrukturbetrieb konzentriert. Hierbei werden das Kubernetes-Clustermanagement und die Anwendungslieferung mit Tools ausgeführt, mit denen Entwickler bereits vertaut sind – nämlich Git und Continuous-Deployment-Tools.
Git übernimmt hierbei den „Single Source of Truth“ für die deklarative Infrastruktur und Anwendungen. Jede Diskrepanz zwischen Git und dem, was tatsächlich in einem K8s-Cluster läuft (oder einem alternativen Cluster-Orchestrator mit Technologie-agnostischen GitOps), wird von Software-Agenten isoliert. Die Kubernetes-Reconciler können dann entweder das Cluster zurücksetzen, um den Git anzupassen oder diese automatisch aktualisieren – erneut als exaktes Replikat des Git-Repositorys.
Mit Git als Zentrum der Delivery-Pipelines können Pull-Requests mit Tools erstellt werden, mit denen Entwickler bereits vertraut sind. Ein automatisierter Prozess gleicht den im Repository beschriebenen Zustand an die Produktionsumgebung an. GitOps wird in diesem Kontext als „Geschwindigkeitsregler zur Verwaltung Ihrer Anwendungen in der Produktion“ bezeichnet.
GitOps-Prinzipien zusammengefasst
GitOps-Workflows, die Kubernetes-Cluster verwalten, basieren auf den folgenden 4 Prinzipien:
Deklarative Beschreibung des gesamten Systems
GitOps arbeitet mit deklarativen Systemen, die häufig in Form von Cloud-nativen Tools, einschließlich Kubernetes, auftreten. Ein deklaratives System kann als Code behandelt werden, da die Konfiguration durch Fakten anstatt Anweisungen gewährleistet wird. Wenn die Deklarationen einer App in Git versioniert sind, wird dies zur „Single Source of Truth“ – dem Kernmerkmal von GitOps.
Mit ihrer einzigen Single Source of Truth in Stein (oder Git) gemeißelt können Apps von Kubernetes leicht eingesetzt und versioniert werden. In einem Worst-Case-Szenario kann die Infrastruktur eines Clusters präzise aus dem Repository reproduziert werden.
Git gewährleistet den Systemzustand
Die Deklaration des in Git gespeicherten Systems stellt immer das gewünschte Standard-System dar. Wenn die Produktions-Deklaration jemals von der Git-Version abweicht, von der alles abgeleitet wird, wird eine Warnung veröffentlicht. Falls ein Rollback erforderlich ist, kann ein einfacher Git-Revert die korrekte Systemdeklaration wiederherstellen.
Gits robuste Sicherheitsvorkehrungen beinhalten SSH-Keys, die verwendet werden, um Commits zu unterzeichnen, sodass die Urheberschaft und Herkunft des Codes immer nachverfolgt werden kann.
Automatisierung für die Bereitstellung von genehmigten Änderungen
Das Produktionscluster muss den von Git deklarierten Zustand genau widerspiegeln, Änderungen an diesem Zustand können automatisch bereitgestellt werden. Cluster-Informationen werden nicht für Systemwechsel benötigt, da die Status-Definition außerhalb der Produktionsumgebung in der Git existiert. Somit ermöglicht GitOps die Trennung dessen, was getan wird und wie etwas getan werden soll.
Benachrichtigungen von Software-Agenten bei Abweichungen
Wenn das Produktionscluster nicht mit Ihrer deklarierten Systemsoftware übereinstimmt, können Agenten eine Warnung versenden. Dies ermöglicht die Selbstheilung des Systems – und zwar nicht nur bei Fehlern von Nodes und Pods, sondern auch bei menschlichem Versagen. Software-Agenten liefern kontinuierliches Feedback und Kontrollschleifen in GitOps.
Eine GitOps-Pipeline
Warum sollten Sie GitOps in Ihre Cloud-native Entwicklung übernehmen?
Wir haben die Funktionen von GitOps beschrieben, aber wo liegen die geschäftlichen Vorteile? Die meisten Continuous-Development-Technologien oder -Methodiken versprechen eine schnellere und häufigere Bereitstellung. GitOps bildet hier keine Ausnahme, kann das Versprechen aber einhalten.
Automatisierte ci cd Delivery-Pipelines übernehmen Git-Änderungen in Ihrer Infrastruktur. GitOps geht noch einen Schritt weiter. Es verwendet Tools wie Weaveworks Flux, um den Vergleich zwischen dem Zustand eines Clusters und der Git-Konfiguration zu automatisieren. Ein Operator im Cluster löst Bereitstellungen in Kubernetes aus, was alle anderen CD-Tools überflüssig macht.
Das bedeutet konkret, dass CI keinen Zugriff auf das Cluster benötigt. Jedes Update ist atomar, transaktional und findet im Git-Audit-Protokoll statt. Transaktionen gelingen entweder einwandfrei oder versagen. Dank eines völlig codierten Ansatzes ist keine neue Infrastruktur erforderlich.
Git als „Single Source of Truth“ sowohl für Infrastruktur als auch für den Anwendungscode beschleunigt die Bereitstellung und erhöht die Zuverlässigkeit, da Fehler schnell identifiziert werden können. Es ist anschließend problemlos möglich, entweder den Produktionsstatus zurückzusetzen oder von der Git zu aktualisieren.
Vorteile des GitOps-Ansatzes
Höhere Produktivität
Die Automatisierung der kontinuierlichen Bereitstellung mit integrierten Feedback-Kontrollschleifen verringert die Bereitstellungszeit erheblich. Weaveworks schätzt, dass bei einem durchschnittlichen Softwareentwicklungsprozess 30- bis 100-mal mehr Änderungen pro Tag gemacht werden können. Die Entwicklungsergebnisse können sich hierdurch verdoppeln und sogar verdreifachen.
Eine Steigerung von 200% bis 300% ist ein massiver Produktivitätsgewinn und veranschaulicht perfekt, warum GitOps in kurzer Zeit so beliebt werden konnte.
Verbesserte Entwicklererfahrung
Da GitOps Codes und keine Container beinhaltet, verwenden Entwickler bekannte Tools wie Git, um Kubernetes-Updates zu verwalten und neue Funktionen hinzuzufügen. Da sich Entwickler nicht mit allen Einzelheiten von Kubernetes vertraut machen müssen, kann der Onboarding-Prozess für neue Entwickler von Monaten auf nur wenige Tage reduziert werden.
Größere Stabilität
Als Folge der Verwendung von Git-Workflows zur Verwaltung eines K8s werden praktische Audit-Protokolle für die Cluster-Änderungen bereitgestellt, die außerhalb von Kubernetes stattfinden. Die Möglichkeit zurückzuverfolgen, wer was wann getan hat, gewährleistet Stabilität und wird den SOC 2 Compliance-Anforderungen gerecht.
Mehr Zuverlässigkeit
Git vereinfacht stabile, replizierbare Rollbacks. Die Tatsache, dass das gesamte System in Git beschrieben wird, liefert einen klar definierten Zustand, der wiederhergestellt werden kann, falls etwas schiefgeht. Das bringt die Wiederherstellungszeit auf Minuten anstatt Stunden und reduziert den finanziellen Schaden, der durch Downtime entstehen kann.
Standardisierung und Konsistenz
Ein einzelnes Modell zur Erstellung der Infrastruktur, Apps und Kubernetes-Änderungen führt zu einheitlichen Arbeitsabläufen innerhalb des Unternehmens. CI/CD-Pipelines basieren auf Pull-Requests und Operations-Aufgaben, die in Git vollständig reproduzierbar sind.
Sicherheit
Das Thema Sicherheit nimmt einen immer größeren Stellenwert ein. Gits Sicherheit ist hervorragend, nicht zuletzt dank der Kryptographie, die zur Verfolgung und Verwaltung von Änderungen verwendet wird und in der Lage ist, den gewünschten Clusterstatus anhand von Änderungen von Autor und Herkunft sicher zu beschreiben.
Warum ist der GitOps-Wechsel vom Push- zum Pull-Modell so wichtig?
Im bis dato noch dominierenden Push-Ansatz von DevOps leitet ein externes System (in der Regel ein CD-Pipine-Tool) die Bereitstellung von Änderungen im Cluster ein, nachdem ein Git-Repository eingesetzt oder eine frühere CI-Pipeline erfolgreich ausgeführt wurde.
Das Pipeline-System muss Zugriff auf das Cluster haben.
In GitOps führen CI/CD-Pipelines Änderungen an einem System aus, wenn diese durch Pull-Anforderung an Git erfolgen. Dies wird vom Observer-Agent innerhalb des Clusters automatisiert, der den Live-Status mit dem des Repositorys abgleicht. Wenn es Abweichungen geben sollte, wird eine Warnung versendet. Falls diese bestätigt wird, wird die Repository-Zustandsänderung ins Cluster gezogen.
Warum ist dies so erwähnenswert? Eine Push-Pipeline bedeutet, dass der Code im CI-System beginnt und dass codierte Skripts Änderungen an das K8s-Cluster senden. Es ist möglich, diese CI-Skripts zu sichern, was aber wiederum bedeuten würde, außerhalb der Trust Domain des Clusters zu agieren.
Eine Pull-Pipeline enthält einen Kubernetes-Operator, z.B. Flux, der neue Bilder innerhalb des Clusters bereitstellt. Neue Bilder werden in der Git erkannt und in den Clusterzustand gezogen. Dadurch wird verhindert, dass Cluster-Informationen außerhalb der Produktionsumgebung verfügbar sind.
GitOps bedeutet nicht, dass nicht auch CI-Tools, Test-Automatisierungen oder sogar direkte Bereitstellungen von der Entwicklung zur Produktion genutzt werden können. Sie werden lediglich darüber informiert, sobald sich der Zustand des Clusters von der „Single Source of Truth“ des Git-Repositorys unterscheidet. Wie Pull-Bereitstellungen anschließend ausgeführt werden, liegt ganz bei Ihnen. Sie können bei der Entwicklung, Staging oder QS eingesetzt werden.
Was ist der Unterschied zwischen GitOps und versionierter Infrastruktur als Code?
Eine deklarative Infrastruktur als Code ist zentral für die Umsetzung von GitOps, wobei GitOps aber weitaus mehr als nur Infrastruktur als Code beinhaltet. Das GitOps-Betriebsmodell bezieht sich auf die Gesamtheit des Ökosystems, während Git-Tooling für die Infrastruktur gilt.
Der gewünschte Zustand der in der Produktionsumgebung bereitgestellten Infrastruktur wird von CD-Systemen garantiert. Weitere Vorteile sind Codeüberprüfungen, Pull-Requests und ein unveränderliches Protokoll von Zeitstempeln, Quellen und Kommentaren zu Änderungen in der Infrastruktur.
Was ist der Unterschied zwischen GitOps und DevOps?
DevOps koordiniert die Verantwortlichkeiten von Entwicklungs- und Operations-Teams, sodass alle auf ein gemeinsames Ziel hinarbeiten, ohne dass sich Verantwortungen überschneiden. GitOps besteht aus einer Reihe von Best-Practices für die Umsetzung von Continuous-Delivery, sodass die Entwicklungsteams auch direkt an den Operations beteiligt sind.
Sowohl DevOps als auch GitOps teilen sich die Prinzipien von Automatisierung und SB-Infrastruktur, aber ansonsten lassen sich nur schwer Vergleiche ziehen. Diese gemeinsamen Prinzipien machen es jedoch einfacher, GitOps-Workflows mit vorhandenen DevOps-Techniken zu verbinden.
Macht GitOps Operations überflüssig?
GitOps ermöglicht es, einen Großteil von den traditionellen Operations-Aufgaben an die Entwicklung zu übertragen, aber in den meisten Fällen spielen Operations immer noch eine entscheidende Rolle. GitOps kann Cloud-Ressourcen automatisieren, aber bestimmte Elemente der Infrastruktur wie Netzwerkkonfiguration oder Kubernetes-Cluster müssen immer noch zentral von Operations-Spezialisten verwaltet werden.
Wenn Container und Cloud-native die Zukunft sind, dann auch GitOps
Mit einem gleichwertigen Fokus auf Entwickler und CI/CD ist GitOps ein elementarer Bestandteil der weiteren Entwicklung von Dev- und Ops-Beziehungen.
DevOps unterstützt mehr Anwendungsmodelle als GitOps, aber wenn sich das Umfeld weiterhin in Richtung Container und Kubernetes als Standard-Orchestrator-Technologie bewegt, wird die Vielseitigkeit von DevOps weniger wichtig.
DevOps lässt sich zwar an eine containerisierte Umgebung anpassen, aber Orchestrationsstandards sind nicht immer mit dem schnell wachsenden K8s-Ökosystem kompatibel.
DevOps und GitOps sind nicht inkompatibel und haben viele Gemeinsamkeiten. GitOps und Kubernetes scheinen aber durch die abweichenden Applikations- und Infrastruktur-Frameworks die Zukunft von Cloud-nativer Entwicklung und Kubernetes zu dominieren. DevOps gerät langsam aber sicher in den Hintergrund, um GitOps das Feld als dominierender Ansatz für Entwicklungspipelines zu überlassen.
Wann gelingt IT Outsourcing?
(und wann nicht?)
