🥇 Was ist GitOps?

Hinweis.: Nach der kürzlichen Veröffentlichung von Materialien über die Pull- und Push-Methoden in GitOps haben wir ein reges Interesse an diesem Modell insgesamt festgestellt. Allerdings gibt es nur sehr wenige russischsprachige Publikationen zu diesem Thema (auf Habr gibt es praktisch keine). Daher freuen wir uns, Ihnen die Übersetzung eines anderen Artikels anzubieten – auch wenn dieser bereits fast ein Jahr alt ist! – von Weaveworks, dessen Gründer den Begriff „GitOps“ geprägt hat. Der Text erläutert das Konzept und die wesentlichen Unterschiede zu bestehenden Ansätzen.

Vor einem Jahr haben wir eine Einführung in GitOps veröffentlicht. Damals haben wir berichtet, wie das Team von Weaveworks ein auf Kubernetes basierendes SaaS gestartet hat und einen Satz empfohlener Best Practices für Bereitstellung, Verwaltung und Überwachung in Cloud-Native-Umgebungen entwickelt hat.

Der Artikel war sehr beliebt. Andere begannen, über GitOps zu sprechen, und veröffentlichten neue Werkzeuge für git push, Entwicklung, Secrets, Funktionen, der kontinuierlichen Integration usw. Auf unserer Website erschienen viele Veröffentlichungen und Anwendungsbeispiele für GitOps. Doch es blieben einige Fragen offen. Wie unterscheidet sich das Modell von traditionellem Infrastructure as Code und Continuous Delivery (Continuous DeliveryIst der Einsatz von Kubernetes zwingend erforderlich?

Bald wurde uns klar, dass eine neue Beschreibung notwendig war, die Folgendes bietet:

Eine Vielzahl von Beispielen und Geschichten;
Eine klare Definition von GitOps;
Einen Vergleich mit traditioneller Continuous Delivery.

In diesem Artikel haben wir versucht, all diese Themen zu behandeln. Sie finden hier eine aktualisierte Einführung in GitOps sowie einen Blick aus der Perspektive von Entwicklern und CI/CD. Wir konzentrieren uns hauptsächlich auf Kubernetes, obwohl das Modell durchaus verallgemeinert werden kann.

Lernen Sie GitOps kennen:

Stellen Sie sich Alice vor. Sie leitet die Firma Family Insurance, die Versicherungen für Gesundheit, Autos, Immobilien und Reisen für Menschen anbietet, die zu beschäftigt sind, um die Feinheiten der Verträge selbst zu verstehen. Ihr Unternehmen begann als Nebenprojekt, während Alice als Data Scientist in einer Bank arbeitete. Eines Tages erkannte sie, dass sie fortschrittliche Computeralgorithmen nutzen kann, um Daten effizienter zu analysieren und Versicherungspakete zu schnüren. Investoren finanzierten das Projekt und nun bringt ihr Unternehmen über 20 Millionen Dollar jährlich ein und wächst rasant. Momentan beschäftigt es 180 Personen in verschiedenen Positionen. Dazu gehört ein Technikteam, das für die Entwicklung, Wartung der Website, Datenbanken und die Analyse der Kundenbasis zuständig ist. Das 60-köpfige Team wird von Bob geleitet, dem technischen Direktor des Unternehmens.

Bobs Team setzt Produktionssysteme in der Cloud ein. Ihre Hauptanwendungen laufen auf GKE und nutzen die Vorteile von Kubernetes in Google Cloud. Darüber hinaus verwenden sie verschiedene Tools für Datenmanagement und Analytik.

Die Family Insurance plante zunächst nicht, Container zu nutzen, wurde jedoch schnell von der Begeisterung für Docker angesteckt. Bald entdeckten die Fachleute des Unternehmens, dass GKE das einfache und unkomplizierte Bereitstellen von Clustern zum Testen neuer Funktionen ermöglicht. Jenkins wurde für CI integriert, und Quay wurde als Container-Registry hinzugefügt. Zudem wurden Skripte für Jenkins verfasst, die neue Container und Konfigurationen in GKE bereitstellten.

Es ist eine Weile vergangen. Alice und Bob sind von der Leistung des gewählten Ansatzes und dessen Einfluss auf das Geschäft enttäuscht. Die Einführung von Containern hat die Performance nicht in dem Maße verbessert, wie es sich das Team erhofft hatte. Gelegentlich schlugen Deployments fehl, und es war unklar, ob Änderungen im Code die Ursache waren. Außerdem war es schwierig, Änderungen an den Konfigurationen nachzuvollziehen. Oft musste ein neuer Cluster erstellt und die Anwendungen dorthin verschoben werden, da dies der einfachste Weg war, das Chaos zu beseitigen, in das das System geraten war. Alice hatte Angst, dass sich die Situation mit der Weiterentwicklung der Anwendung verschlechtern würde (außerdem stand ein neues Projekt im Bereich Machine Learning an). Bob hatte den Großteil der Arbeit automatisiert und verstand nicht, warum die Pipeline weiterhin instabil und schlecht skalierbar war und gelegentlich manuelles Eingreifen erforderte.

Dann erfuhren sie von GitOps. Diese Lösung stellte sich als genau das heraus, was sie für einen sicheren Fortschritt benötigten.

Alice und Bob haben seit vielen Jahren von Prozessen auf Basis von Git, DevOps und Infrastructure as Code gehört. Das Besondere an GitOps ist, dass es eine Reihe bewährter Praktiken — sowohl verbindlicher als auch normativer — für die Umsetzung dieser Ideen im Kontext von Kubernetes einführt. Dies ist ein Thema, das immer wieder angesprochen wurde, auch in dem Weaveworks-Blog.

Family Insurance hat beschlossen, GitOps einzuführen. Das Unternehmen verfügt nun über ein automatisiertes Betriebsmodell, das mit Kubernetes kompatibel ist und Geschwindigkeit , für mit Stabilität, da sie:

festgestellt haben, dass die Produktivität des Teams sich verdoppelt hat, ohne dass dabei Stress entsteht;
sie aufgehört haben, Skripte zu verwalten. Stattdessen können sie sich jetzt auf neue Funktionen konzentrieren und die Ingenieurmethoden verbessern — zum Beispiel durch die Einführung von Canary-Releases und die Optimierung von Tests;
sie den Bereitstellungsprozess verbessert haben — dieser bricht nun selten zusammen;
sie in der Lage sind, Deployments nach partiellen Ausfällen ohne manuelles Eingreifen wiederherzustellen;
sie größere Sicherheit in den Lieferketten gewonnen haben. Alice und Bob haben festgestellt, dass sie das Team in Gruppen aufteilen können, die parallel an Mikrodiensten arbeiten;größtengrößeren Vertrauen in die Bereitstellungssysteme. Alice und Bob haben festgestellt, dass das Team in Gruppen aufgeteilt werden kann, die sich mit Mikrodiensten befassen und parallel arbeiten.
können täglich 30-50 Änderungen am Projekt durch jede Gruppe vornehmen und neue Techniken ausprobieren;
ziehen mühelos neue Entwickler an, die in der Lage sind, Updates innerhalb weniger Stunden über Pull-Requests in die Produktion einzuspielen;
überstehen problemlos eine SOC2-Prüfung (in Bezug auf die Einhaltung von Sicherheitsanforderungen für Datenmanagement durch Dienstleister; mehr dazu lesen Sie beispielsweise hier — Anmerkung des Übersetzers)..

Was ist passiert?

GitOps — das sind zwei Dinge:

Ein Betriebsmodell für Kubernetes und Cloud-native Anwendungen. Es bietet eine Sammlung bewährter Verfahren für die Bereitstellung, Verwaltung und Überwachung von in Containern bereitgestellten Clustern und Anwendungen. Eine elegante Definition in Form von einer Folie ab Luis Faceira:
Der Weg zur Schaffung einer entwicklerorientierten Umgebung für das Management von Anwendungen. Wir wenden den Git-Workflow sowohl auf den Betrieb als auch auf die Entwicklung an. Beachten Sie, dass es hier nicht nur um Git Push geht, sondern um die Organisation des gesamten Toolsatzes für CI/CD und UI/UX.

Ein paar Worte zu Git

Wenn Sie mit Versionskontrollsystemen und einem auf Git basierenden Arbeitsablauf nicht vertraut sind, empfehlen wir Ihnen dringend, sich damit auseinanderzusetzen. Zunächst kann die Arbeit mit Branches und Pull-Requests wie schwarze Magie erscheinen, aber die Vorteile rechtfertigen den Aufwand. Hier ist ein guter Artikel zum Einstieg.

Wie funktioniert Kubernetes?

In unserer Geschichte wandten sich Alice und Bob GitOps zu, nachdem sie eine Zeit lang mit Kubernetes gearbeitet hatten. Tatsächlich ist GitOps eng mit Kubernetes verbunden – es ist ein Betriebsmodell für Infrastrukturen und Anwendungen, die auf Kubernetes basieren.

Was bietet Kubernetes den Nutzern?

Hier sind einige der Hauptfunktionen:

In der Kubernetes-Modell können alle Ressourcen in deklarativer Form beschrieben werden.
Der Kubernetes-API-Server akzeptiert diese Deklarationen als Eingabe und versucht kontinuierlich, den Cluster in den in der Deklaration beschriebenen Zustand zu versetzen.
Die Deklarationen sind ausreichend, um eine Vielzahl von Arbeitslasten – 'Anwendungen' – zu beschreiben und zu verwalten.
Infolgedessen erfolgen Änderungen an Anwendungen und Clustern aufgrund von:
- Änderungen der Container-Images;
- Änderungen der deklarativen Spezifikation;
- Fehler in der Umgebung – zum Beispiel Containerabstürze.

Außergewöhnliche Fähigkeiten von Kubernetes in der Konvergenz

Wenn der Administrator Änderungen an der Konfiguration vornimmt, wird der Kubernetes-Orchestrator diese auf den Cluster anwenden, bis dessen Zustand nah an der neuen Konfiguration ist. Dieses Modell funktioniert für jede Kubernetes-Ressource und lässt sich durch Custom Resource Definitions (CRDs) erweitern. Daher besitzen Kubernetes-Deployments folgende bemerkenswerte Eigenschaften:

Automatisierung: Kubernetes-Updates bieten einen Mechanismus zur Automatisierung des Prozesses, um Änderungen korrekt und rechtzeitig anzuwenden.
Konvergenz: Kubernetes wird weiterhin versuchen, Updates durchzuführen, bis der Erfolg erreicht ist.
Idempotenz: Wiederholte Anwendungen der Konvergenz führen zum gleichen Ergebnis.
Determinismus: Bei ausreichenden Ressourcen hängt der Zustand des aktualisierten Clusters lediglich vom gewünschten Zustand ab.

Wie GitOps funktioniert

Wir haben genug über Kubernetes gelernt, um die Prinzipien von GitOps zu erklären.

Lassen Sie uns zu den Teams von Family Insurance zurückkehren, die mit Microservices verbunden sind. Womit haben sie in der Regel zu tun? Sehen Sie sich die Liste unten an (wenn Ihnen einige Punkte seltsam oder unbekannt erscheinen, bitte zögern Sie nicht mit Kritik und bleiben Sie bei uns). Das sind nur Beispiele für Arbeitsabläufe basierend auf Jenkins. Es gibt viele weitere Prozesse, die mit anderen Tools verbunden sind.

Das Wichtigste ist, dass wir sehen, dass jedes Update mit Änderungen an den Konfigurationsdateien und Git-Repositories endet. Diese Änderungen in Git führen dazu, dass der "GitOps-Operator" den Cluster aktualisiert:

1. Arbeitsablauf: „Jenkins-Bau – master-Branch».
Aufgabenliste:

Jenkins pusht getaggte Images in Quay;
Jenkins pusht Konfiguration und Helm-Charts in den Master-Storage-Bucket;
Eine Cloud-Funktion kopiert Konfiguration und Charts vom Master-Storage-Bucket ins Git-Repository des Masters;
Der GitOps-Operator aktualisiert den Cluster.

2. Jenkins-Bau – release- oder hotfix-Branch:

Jenkins pusht ungetaggte Images in Quay;
Jenkins pusht Konfiguration und Helm-Charts in den Staging-Storage-Bucket;
Eine Cloud-Funktion kopiert Konfiguration und Charts vom Staging-Storage-Bucket ins Git-Repository des Stagings;
Der GitOps-Operator aktualisiert den Cluster.

3. Jenkins-Bau – develop- oder feature-Branch:

Jenkins pusht ungetaggte Images in Quay;
Jenkins pusht die Konfiguration und Helm-Charts in den develop-Speicherbunker;
Die Cloud-Funktion kopiert die Konfiguration und Charts aus dem develop-Speicherbunker in das Git-Repository develop;
Der GitOps-Operator aktualisiert den Cluster.

4. Neuen Kunden hinzufügen:

Der Manager oder Administrator (LCM/ops) ruft Gradle für das initiale Deployment und die Konfiguration der Network Load Balancer (NLB) auf;
LCM/ops committet die neue Konfiguration zur Vorbereitung des Deployments auf Updates;
Der GitOps-Operator aktualisiert den Cluster.

Kurze Beschreibung von GitOps

Definieren Sie den gewünschten Zustand des gesamten Systems mithilfe deklarativer Spezifikationen für jede Umgebung (in unserer Geschichte definiert Bob's Team die gesamte Systemkonfiguration in Git).
- Das Git-Repository ist die einzige Quelle der Wahrheit bezüglich des gewünschten Zustands des gesamten Systems.
- Alle Änderungen am gewünschten Zustand erfolgen durch Commits in Git.
- Alle gewünschten Clusterparameter sind ebenfalls im Cluster selbst beobachtbar. So können wir feststellen, ob der gewünschte und der beobachtete Zustand übereinstimmen (konvergieren, converge) oder voneinander abweichen (divergieren, diverge).
Wenn der gewünschte und der beobachtete Zustand unterschiedlich sind, dann:
- Es gibt einen Konvergenzmechanismus, der irgendwann automatisch den Ziel- und den beobachteten Zustand synchronisiert. Innerhalb des Clusters übernimmt dies Kubernetes.
- Der Prozess wird sofort mit der Benachrichtigung "Änderung bestätigt" gestartet.
- Nach einem anpassbaren Zeitintervall kann eine Benachrichtigung "Diff" gesendet werden, falls die Zustände unterschiedlich sind.
So führen alle Commits in Git überprüfbare und idempotente Aktualisierungen im Cluster herbei.
- Ein Rollback ist die Konvergenz zu einem zuvor gewünschten Zustand.
Die Konvergenz ist endgültig. Anzeichen dafür sind:
- Das Fehlen von "Diff"-Benachrichtigungen über einen bestimmten Zeitraum.
- Die Benachrichtigung "konvergiert" (zum Beispiel Webhook, Git Writeback-Ereignis).

Was ist Divergenz?

Lassen Sie uns wiederholen: alle gewünschten Eigenschaften des Clusters müssen im Cluster selbst beobachtbar sein..

Einige Beispiele für Divergenz:

Änderung in der Konfigurationsdatei aufgrund von Zusammenführungen von Branches in Git.
Änderung in der Konfigurationsdatei aufgrund eines Git-Commits, der von einem GUI-Client durchgeführt wurde.
Mehrere Änderungen im gewünschten Zustand aufgrund eines PR in Git mit anschließender Erstellung des Container-Images und Änderungen in der Konfiguration.
Änderung des Clusterstatus aufgrund eines Fehlers, Ressourcen-Konflikts, der zu 'schlechtem Verhalten' führt, oder einfach einer zufälligen Abweichung vom ursprünglichen Zustand.

Was ist der Konvergenzmechanismus?

Einige Beispiele:

Für Container und Cluster stellt der Konvergenzmechanismus Kubernetes zur Verfügung.
Der gleiche Mechanismus kann zur Verwaltung von Anwendungen und Konstrukten auf Basis von Kubernetes (zum Beispiel Istio und Kubeflow) verwendet werden.
Der Mechanismus zur Verwaltung der Arbeitsabläufe zwischen Kubernetes, Image-Repositories und Git wird bereitgestellt von dem GitOps-Operator Weave Flux, der Teil von Weave Cloud.
Für Basismaschinen sollte der Konvergenzmechanismus deklarativ und autonom sein. Aus eigener Erfahrung können wir sagen, dass Terraform dieser Definition am nächsten kommt, jedoch dennoch menschliche Kontrolle erfordert. In diesem Sinne erweitert GitOps die Traditionen von Infrastructure as Code.

GitOps verbindet Git mit dem hervorragenden Konvergenzmechanismus von Kubernetes und bietet ein Modell für den Betrieb.

GitOps ermöglicht es uns zu erklären: Automatisierung und Kontrolle gelten nur für Systeme, die beschrieben und überwacht werden können..

GitOps ist für den gesamten Cloud-Native-Stack (zum Beispiel Terraform usw.) gedacht.

GitOps ist nicht nur Kubernetes. Wir möchten, dass das gesamte System deklarativ verwaltet wird und Konvergenz nutzt. Unter dem gesamten System verstehen wir eine Vielzahl von Umgebungen, die mit Kubernetes arbeiten – wie zum Beispiel „dev cluster 1“, „Produktion“ usw. Jede Umgebung umfasst Maschinen, Cluster, Anwendungen sowie Schnittstellen zu externen Diensten, die Daten, Monitoring usw. bereitstellen.

Beachten Sie, wie wichtig Terraform in diesem Zusammenhang für das Bootstrapping-Problem ist. Kubernetes muss irgendwo bereitgestellt werden, und die Verwendung von Terraform bedeutet, dass wir dieselben GitOps-Arbeitsabläufe anwenden können, um die Managementschicht zu erstellen, die Kubernetes und Anwendungen zugrunde liegt. Das ist eine nützliche Best Practice.

Es wird viel Wert auf die Anwendung der GitOps-Konzepte auf die Schichten über Kubernetes gelegt. Derzeit gibt es GitOps-Lösungen für Istio, Helm, Ksonnet, OpenFaaS und Kubeflow, sowie zum Beispiel für Pulumi, die eine Schicht zur Anwendungsentwicklung für Cloud-Native schaffen.

Kubernetes CI/CD: Vergleich von GitOps mit anderen Ansätzen.

Wie bereits erwähnt, ist GitOps zwei Dinge:

Ein Betriebsmodell für Kubernetes und Cloud-Native, wie oben beschrieben.
Der Weg zu einer entwicklerorientierten Umgebung für das Management von Anwendungen.

Für viele ist GitOps in erster Linie ein Workflow basierend auf Git-Pushes. Uns gefällt dieser Ansatz auch. Aber das ist nicht alles: Lassen Sie uns nun die CI/CD-Pipelines betrachten.

GitOps ermöglicht Continuous Deployment (CD) unter Kubernetes.

GitOps bietet einen Mechanismus für kontinuierliches Deployment, der die Notwendigkeit separater 'Deployment-Management-Systeme' eliminiert. Kubernetes erledigt die gesamte Arbeit für Sie.

Die Aktualisierung einer Anwendung erfordert ein Update in Git. Dies ist ein transaktionales Update auf den gewünschten Zustand. Das 'Deployment' erfolgt dann innerhalb des Clusters selbst durch Kubernetes basierend auf der aktualisierten Beschreibung.
Aufgrund der spezifischen Arbeitsweise von Kubernetes sind diese Updates konvergent. Dies gewährleistet einen Mechanismus für kontinuierliches Deployment, bei dem alle Updates atomar sind.
Hinweis: Weave Cloud bietet einen GitOps-Operator, der Git und Kubernetes integriert und es ermöglicht, CD durch Abstimmung des gewünschten und des aktuellen Zustands des Clusters durchzuführen.

Ohne kubectl und Skripte.

Vermeiden Sie es, Kubectl zur Aktualisierung des Clusters zu verwenden, insbesondere Skripte zur Gruppierung von Kubectl-Befehlen. Stattdessen kann der Benutzer über eine GitOps-Pipeline sein Kubernetes-Cluster über Git aktualisieren.

Die Vorteile umfassen:

Richtigkeit. Mit einer Gruppe von Updates kann man anwenden, konvergieren und schließlich validieren, was uns dem Ziel eines atomaren Deployments näher bringt. Im Gegensatz dazu bieten Skripte keine Gewähr für die Konvergenz (dazu weiter unten mehr).
Sicherheit. Zitat von Kelsey Hightower: „Beschränken Sie den Zugriff auf den Kubernetes-Cluster auf Automatisierungstools und Administratoren, deren Aufgabe es ist, ihn zu debuggen oder betriebsfähig zu halten.“ Siehe auch meinen Beitrag zur Sicherheit und Einhaltung technischer Anforderungen sowie den Artikel über den Homebrew-Hack durch das Stehlen von Anmeldeinformationen aus einem sorglos erstellten Jenkins-Skript.
Benutzererfahrung. Kubectl zeigt die Mechanik des Kubernetes-Objektmodells, das ziemlich komplex ist. Idealerweise sollten Benutzer auf einer höheren Abstraktionsebene mit dem System interagieren. Hier verweise ich erneut auf Kelsey und empfehle, sich anzusehen so ein Lebenslauf.

Der Unterschied zwischen CI und CD

GitOps verbessert bestehende CI/CD-Modelle.

Ein moderner CI-Server ist ein Werkzeug zur Orchestrierung. Konkret handelt es sich dabei um ein Werkzeug zur Orchestrierung von CI-Pipelines. Diese umfassen Build, Test, Merge zum Hauptzweig usw. CI-Server automatisieren das Management komplexer, mehrstufiger Pipelines. Der häufige Reiz besteht darin, ein Skript für eine Reihe von Kubernetes-Updates zu erstellen und es als Bestandteil der Pipeline zum Pushen von Änderungen in den Cluster auszuführen. Viele Fachleute machen das tatsächlich. Doch das ist suboptimal, und das ist der Grund.

CI sollte verwendet werden, um Updates in den Hauptzweig einzufügen, und der Kubernetes-Cluster sollte sich basierend auf diesen Updates ändern, um CD "intern" zu verwalten. Wir nennen das das Pull-Modell für CD, im Gegensatz zum Push-Modell von CI. CD ist Teil der Runtime-Orchestrierung.

Warum CI-Server CD nicht durch direkte Updates in Kubernetes durchführen sollten

Verwenden Sie den CI-Server nicht zur Orchestrierung direkter Updates in Kubernetes in Form einer Reihe von CI-Jobs. Dies ist ein Anti-Pattern, über das wir bereits berichtet haben in unserem Blog.

Lassen Sie uns zu Alice und Bob zurückkehren.

Welche Probleme traten auf? Der CI-Server von Bob wendet Änderungen auf den Cluster an, aber wenn er dabei abstürzt, weiß Bob nicht, in welchem Zustand sich der Cluster befindet oder befinden sollte und wie er ihn reparieren kann. Dasselbe gilt im Erfolgsfall.

Nehmen wir an, Bobs Team hat ein neues Image erstellt und dann ihre Deployments gepatcht, um das Image (alles aus der CI-Pipeline) bereitzustellen.

Wenn das Image erfolgreich erstellt wird, aber die Pipeline abstürzt, muss das Team Folgendes klären:

Wurde das Update erfolgreich bereitgestellt?
Starten wir einen neuen Build? Führt das zu unerwünschten Nebeneffekten — besteht die Möglichkeit, dass zwei Builds des gleichen unveränderten Images erstellt werden?
Sollten wir auf das nächste Update warten, bevor wir den Build starten?
Was genau ist schiefgegangen? Welche Schritte müssen wiederholt werden (und welche können sicher wiederholt werden)?

Die Organisation eines Git-basierten Workflows garantiert nicht, dass Bobs Team nicht mit diesen Problemen konfrontiert wird. Sie können immer noch beim Pushen eines Commits, beim Taggen oder bei einem anderen Parameter einen Fehler machen; jedoch ist dieser Ansatz dennoch viel näher an einem klaren Alles-oder-Nichts.

Zusammenfassend lässt sich sagen, warum CI-Server nicht für CD zuständig sein sollten:

Update-Skripte sind nicht immer deterministisch; Fehler sind leicht gemacht.
CI-Server konvergieren nicht zu einem deklarativen Cluster-Modell.
Es ist schwierig, die Idempotenz zu garantieren. Benutzer müssen sich mit der tiefen Semantik des Systems auseinandersetzen.
Die Wiederherstellung nach einem teilweisen Ausfall ist komplizierter.

Hinweis zu Helm: Wenn Sie Helm verwenden möchten, empfehlen wir, ihn mit einem GitOps-Operator wie Flux-Helm. Dadurch wird die Konvergenz sichergestellt. Helm allein ist weder deterministisch noch atomar.

GitOps als besten Ansatz für Continuous Delivery bei Kubernetes

Das Team von Alice und Bob implementiert GitOps und stellt fest, dass die Arbeit mit Softwareprodukten wesentlich einfacher geworden ist, während die Leistung und Stabilität hoch bleibt. Lassen Sie uns diesen Artikel mit Illustrationen abschließen, die zeigen, wie ihr neuer Ansatz aussieht. Beachten Sie, dass wir hauptsächlich über Anwendungen und Services sprechen, jedoch kann GitOps zur Verwaltung der gesamten Plattform eingesetzt werden.

Betriebsmodell für Kubernetes

Werfen Sie einen Blick auf das folgende Diagramm. Es zeigt Git und Container-Images als gemeinsame Ressourcen für die beiden orchestrierten Lebenszyklen:

den Continuous Integration-Pipeline, die Dateien in Git liest und schreibt und das Container-Image-Repository aktualisieren kann.
die Runtime GitOps-Pipeline, die Deployment mit Management und Observability kombiniert. Sie liest und schreibt Dateien in Git und kann Container-Images hochladen.

Was sind die wichtigsten Erkenntnisse?

Probleme trennen: Beachten Sie, dass beide Pipelines Daten austauschen können, indem sie lediglich Git oder das Image-Repository aktualisieren. Anders ausgedrückt, es gibt eine Firewall zwischen der CI- und der Runtime-Umgebung. Wir nennen es „Immutable Firewall“ (Immutable Firewall), da alle Updates der Repositories neue Versionen erstellen. Für weitere Informationen zu diesem Thema wenden Sie sich bitte an die Folien 72-87 dieser Präsentation.
Jeder CI- und Git-Server kann verwendet werden.: GitOps funktioniert mit allen Komponenten. Sie können weiterhin Ihre bevorzugten CI- und Git-Server, Container-Repositorys und Testsets verwenden. Nahezu alle anderen Tools für Continuous Delivery auf dem Markt erfordern ihren eigenen CI-/Git-Server oder Container-Repositorys. Dies kann ein hemmender Faktor für die Entwicklung von cloud-native Anwendungen sein. Bei GitOps können Sie jedoch gewohnte Werkzeuge nutzen.
Ereignisse als Integrationswerkzeug: Sobald die Daten in Git aktualisiert werden, informiert Weave Flux (oder der Weave Cloud Operator) die Laufzeit darüber. Jedes Mal, wenn Kubernetes eine Menge von Änderungen akzeptiert, wird Git aktualisiert. Dies bietet ein einfaches Integrationsmodell für die Arbeitsabläufe von GitOps, wie unten dargestellt.

Fazit

GitOps bietet gewichtige Garantien für Updates, die jedem modernen CI/CD-Tool erforderlich sind:

Automatisierung;
Konvergenz;
Idempotenz;
Determinismus.

Dies ist wichtig, da es ein Betriebsmodell für Entwickler im Bereich cloud-native Anwendungen bereitstellt.

Traditionelle Werkzeuge zur Verwaltung und Überwachung von Systemen sind mit Betriebsteams verbunden, die innerhalb eines Runbook agieren (einer Sammlung von Routineverfahren und -operationen — Anmerkung des Übersetzers), der an ein bestimmtes Deployment gebunden ist.
Bei der Verwaltung von cloud-nativen Systemen ist ein Überwachungstool der beste Weg, um die Ergebnisse von Deployments zu bewerten, sodass das Entwicklerteam schnell darauf reagieren kann.

Stellen Sie sich viele Cluster vor, die auf verschiedene Clouds verteilt sind, und zahlreiche Dienste mit eigenen Teams und Deployment-Plänen. GitOps bietet ein skalierbares, invariantes Modell zur Verwaltung all dieser Vielfalt.