Anmerkung des Übersetzers.: Nach der kürzlichen Veröffentlichung über Pull- und Push-Methoden in GitOps haben wir ein großes Interesse an diesem Modell festgestellt. Allerdings gab es auf Russisch kaum Veröffentlichungen zu diesem Thema (auf Habré gibt es schlichtweg keine). Daher freuen wir uns, Ihnen die Übersetzung eines anderen Artikels anzubieten — auch wenn er bereits fast ein Jahr alt ist! — von der Firma Weaveworks, deren Leiter den Begriff „GitOps“ geprägt hat. Der Text erläutert die Essenz des Ansatzes und die wesentlichen Unterschiede zu den bereits bestehenden.
Vor einem Jahr haben wir . Damals berichteten wir, wie das Team von Weaveworks eine SaaS vollständig auf Kubernetes basierend gestartet hat und einen Katalog von empfohlenen Best Practices für Bereitstellung, Verwaltung und Überwachung in einer cloud-nativen Umgebung entwickelt hat.
Der Artikel war sehr populär. Andere Menschen begannen über GitOps zu sprechen und veröffentlichten neue Werkzeuge für , , , , usw. Auf unserer Website erschienen Veröffentlichungen und Anwendungsfälle für GitOps. Aber einige Menschen hatten trotzdem noch Fragen. Wie unterscheidet sich das Modell von traditioneller und kontinuierlicher Lieferung ()? Ist es zwingend erforderlich, Kubernetes zu verwenden?
Bald erkannten wir, dass eine neue Beschreibung erforderlich war, die Folgendes bietet:
- Eine große Anzahl von Beispielen und Geschichten;
- Eine konkrete Definition von GitOps;
- Einen Vergleich mit traditioneller Continuous Delivery.
In diesem Artikel haben wir versucht, all diese Themen abzudecken. Sie finden eine aktualisierte Einführung in GitOps und eine Sichtweise darauf von Entwicklern und CI/CD. Wir konzentrieren uns hauptsächlich auf Kubernetes, obwohl das Modell durchaus verallgemeinerbar ist.
Lernen Sie GitOps kennen
Stellen Sie sich Alice vor. Sie leitet die Familie Versicherungen, die Policen für Kranken-, Auto-, Immobilienversicherungen und Reiseversicherungen für Menschen anbieten, die zu beschäftigt sind, um die Nuancen der Verträge selbst zu verstehen. Ihr Geschäft begann als Nebenprojekt, als Alice als Datenwissenschaftlerin 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 pro Jahr ein und wächst schnell. Zurzeit arbeiten 180 Personen in verschiedenen Positionen für sie. Dazu gehört auch ein technologisches Team, das für die Entwicklung, Wartung der Website, der Datenbank und die Analyse der Kundenbasis zuständig ist. Das Team von 60 Personen wird von Bob, dem technischen Direktor des Unternehmens, geleitet.
Bobs Team implementiert Produktionssysteme in der Cloud. Ihre Hauptanwendungen laufen auf GKE und nutzen die Vorteile von Kubernetes in Google Cloud. Darüber hinaus verwenden sie verschiedene Werkzeuge zur Datenverarbeitung und Analyse.
Die Familie Versicherungen hatte nicht vor, Container zu verwenden, wurde jedoch vom Enthusiasmus für Docker angesteckt. Bald stellte das Unternehmen fest, dass GKE es ermöglicht, Cluster für das Testen neuer Funktionen einfach und mühelos bereitzustellen. Jenkins wurde für CI hinzugefügt und Quay zur Organisation des Container-Registers, und Skripte für Jenkins wurden geschrieben, die neue Container und Konfigurationen in GKE pushen.
Es ist einige Zeit vergangen. Alice und Bob waren von der Leistung des gewählten Ansatzes und dessen Einfluss auf das Geschäft enttäuscht. Die Einführung von Containern hatte die Leistung nicht so gesteigert, wie das Team gehofft hatte. Manchmal brachen die Deployments zusammen, und es war unklar, ob die Änderungen im Code dafür verantwortlich waren. Auch das Verfolgen der Änderungen in den Konfigurationen stellte sich als schwierig heraus. Oft war es einfacher, einen neuen Cluster zu erstellen und die Anwendungen dorthin zu verschieben, um das Chaos zu beseitigen, in das das System geraten war. Alice hatte Angst, dass sich die Situation im Zuge der Weiterentwicklung der Anwendung verschlechtern würde (darüber hinaus kündigte sich ein neues Projekt im Bereich des maschinellen Lernens an). Bob hatte einen Großteil der Arbeit automatisiert und konnte nicht verstehen, warum die Pipeline immer noch instabil, schlecht skalierbar war und sporadisch manuelles Eingreifen erforderte.
Dann erfuhren sie von GitOps. Diese Lösung stellte sich als genau das heraus, was sie benötigten, um selbstbewusst voranzukommen.
Alice und Bob hatten seit mehreren Jahren von git-basierten Workflows, DevOps und Infrastructure as Code gehört. Das Besondere an GitOps ist, dass es eine Reihe bewährter Praktiken – kategorisch und normativ – in den Kontext von Kubernetes bringt. wurde mehrfach angesprochen .
Weaveworks-Blog. Family Insurance beschließt die Einführung von GitOps. Jetzt hat das Unternehmen ein automatisiertes Betriebsmodell, das mit Kubernetes kompatibel ist und die Geschwindigkeit für Stabilität, da sie:
- feststellten, dass die Produktivität des Teams sich verdoppelt hat und niemand dabei den Verstand verliert;
- die Skripte nicht mehr warten mussten. Stattdessen können sie sich nun auf neue Funktionen konzentrieren und die Ingenieurmethoden verbessern – beispielsweise durch die Einführung von Canary-Releases und die Verbesserung der Tests;
- den Deploy-Prozess verbessert haben – nun bricht er selten zusammen;
- sie die Möglichkeit haben, Deployments nach partiellen Ausfällen ohne manuelles Eingreifen wiederherzustellen;
- sie mehr Vertrauen in die Bereitstellungssysteme gewonnen haben. Alice und Bob stellten fest, dass sie das Team in Gruppen aufteilen konnten, die sich mit Mikrodiensten befassen und parallel arbeiten;osie täglich 30 bis 50 Änderungen am Projekt durch die Anstrengungen jeder Gruppe einbringen können und neue Techniken ausprobieren;
- können täglich 30-50 Änderungen am Projekt durch die Anstrengungen jeder Gruppe vornehmen und neue Techniken ausprobieren;
- Sie ziehen leicht neue Entwickler an, die in der Lage sind, Updates über Pull-Requests innerhalb von nur wenigen Stunden in die Produktion zu bringen;
- sie bestehen leicht die SOC2-Prüfung (um die Anforderungen an die sichere Datenverwaltung von Dienstanbietern zu entsprechen; mehr dazu lesen Sie beispielsweise — Anm. d. Übersetzer).
Was ist passiert?
GitOps ist zwei Dinge:
- Ein Betriebsmodell für Kubernetes und Cloud-native Anwendungen. Es bietet eine Sammlung von Best Practices für die Bereitstellung, Verwaltung und Überwachung von in Containern gebündelten Clustern und Anwendungen. Eine elegante Definition in Form von ab :
- Der Weg zur Schaffung einer entwicklerfreundlichen Umgebung für das Anwendungsmanagement. Wir wenden den Git-Workflow sowohl auf die Betriebsführung als auch auf die Entwicklung an. Beachten Sie, dass es nicht nur um Git Push geht, sondern um die Organisation des gesamten Sets an CI/CD- und UI/UX-Tools.
Ein paar Worte über Git
Wenn Sie mit Versionskontrollsystemen und dem auf Git basierenden Workflow 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 überwiegen die aufgebrachte Mühe. Hier ist ein guter Ausgangspunkt.
Wie Kubernetes funktioniert
In unserer Geschichte wandten Alice und Bob sich an GitOps, nachdem sie eine Weile mit Kubernetes gearbeitet hatten. Tatsächlich ist GitOps eng mit Kubernetes verbunden – es ist ein Betriebsmodell für Infrastruktur und Anwendungen, die auf Kubernetes basieren.
Was bietet Kubernetes den Nutzern?
Hier sind einige der wichtigsten Funktionen:
- Im Kubernetes-Modell kann alles in deklarativer Form beschrieben werden.
- Der Kubernetes-API-Server akzeptiert eine solche Deklaration als Eingabe und versucht dann ständig, den Cluster in den in der Deklaration beschriebenen Zustand zu versetzen.
- Deklarationen sind ausreichend, um eine große Vielfalt von Workloads – 'Anwendungen' – zu beschreiben und zu verwalten.
- Infolgedessen erfolgen Änderungen an der Anwendung und dem Cluster aufgrund von:
- Änderungen an Container-Images;
- Änderungen an der deklarativen Spezifikation;
- Fehler in der Umgebung – zum Beispiel Container-Abstürze.
Die hervorragenden Konvergenzfähigkeiten von Kubernetes
Wenn ein Administrator Änderungen an der Konfiguration vornimmt, wird der Kubernetes-Orchestrator diese auf den Cluster anwenden, bis sein Zustand der neuen Konfiguration näherkommt.. Dieses Modell funktioniert für jede Kubernetes-Ressource und lässt sich durch Custom Resource Definitions (CRDs) erweitern. Daher verfügen Kubernetes-Deployments über die folgenden wunderbaren Eigenschaften:
- Automatisierung: Kubernetes-Updates bieten einen Mechanismus zur Automatisierung des Prozesses, Änderungen korrekt und zeitgerecht 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 nur 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 von der Family Insurance verwalteten Micodiensten zurückkehren. Womit haben sie normalerweise zu tun? Schauen Sie sich die Liste unten an (wenn Ihnen einige Punkte seltsam oder unbekannt vorkommen — bitte sehen Sie von Kritik ab und bleiben Sie bei uns). Das sind nur Beispiele für Arbeitsabläufe basierend auf Jenkins. Es gibt auch viele andere Prozesse bei der Verwendung anderer Tools.
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" das Cluster aktualisiert:
1. Arbeitsablauf: „Jenkins-Bau — master-Zweig».
Aufgabenliste:
- Jenkins pusht getaggte Images in Quay;
- Jenkins pusht Konfiguration und Helm-Charts in den Bucket des master-Speichers;
- Die Cloud-Funktion kopiert Konfiguration und Charts aus dem Bucket des master-Speichers in das Git-Repository master;
- Der GitOps-Operator aktualisiert das Cluster.
2. Jenkins-Bau — release- oder hotfix-Zweig:
- Jenkins pusht ungetaggte Images in Quay;
- Jenkins pusht Konfiguration und Helm-Charts in den Bucket des staging-Speichers;
- Die Cloud-Funktion kopiert Konfiguration und Charts aus dem Bucket des staging-Speichers in das Git-Repository staging;
- Der GitOps-Operator aktualisiert das Cluster.
3. Jenkins-Bau — develop- oder feature-Zweig:
- Jenkins pusht ungetaggte Images in Quay;
- Jenkins pusht Konfiguration und Helm-Charts in den Bucket des develop-Speichers;
- Die Cloud-Funktion kopiert Konfiguration und Charts aus dem Bucket des develop-Speichers in das Git-Repository develop;
- Der GitOps-Operator aktualisiert das Cluster.
4. Hinzufügen eines neuen Clients:
- Der Manager oder Administrator (LCM/ops) ruft Gradle für das erste Deployment und die Einrichtung von Load-Balancern (NLB) auf;
- LCM/ops committet eine neue Konfiguration zur Vorbereitung des Deployments auf Updates;
- Der GitOps-Operator aktualisiert das Cluster.
Kurze Beschreibung von GitOps
- Beschreiben Sie den gewünschten Zustand des gesamten Systems unter Verwendung 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 in Bezug auf den gewünschten Zustand des gesamten Systems.
- Alle Änderungen an dem gewünschten Zustand erfolgen durch Commits in Git.
- Alle gewünschten Clusterparameter sind auch im Cluster selbst sichtbar. So können wir feststellen, ob die gewünschten und beobachteten Zustände übereinstimmen (konvergieren, converge) oder sich unterscheiden (divergieren, diverge) .
- Wenn sich der gewünschte und der beobachtete Zustand unterscheiden, dann:
- Es gibt einen Konvergenzmechanismus, der früher oder später automatisch den Ziel- und den beobachteten Zustand synchronisiert. Innerhalb des Clusters kümmert sich Kubernetes darum.
- Der Prozess wird umgehend mit der Benachrichtigung "Änderung eingepflegt" gestartet.
- Nach einem einstellbaren Zeitraum kann eine Benachrichtigung "Diff" gesendet werden, wenn sich die Zustände unterscheiden.
- So verursachen alle Commits in Git überprüfbare und idempotente Updates im Cluster.
- Rollback ist eine Konvergenz zu einem früheren gewünschten Zustand.
- Die Konvergenz ist endgültig. Ihr Eintritt wird angezeigt durch:
- Das Fehlen von "Diff"-Benachrichtigungen über einen bestimmten Zeitraum.
- Eine "konvergierte" Benachrichtigung (z. B. Webhook, Git-Writeback-Ereignis).
Was ist Divergenz?
Nochmals: Alle gewünschten Eigenschaften des Clusters müssen im Cluster selbst sichtbar sein..
Einige Beispiele für Divergenz:
- Änderung in der Konfigurationsdatei aufgrund von Zusammenführungen in Git.
- Änderung in der Konfigurationsdatei aufgrund eines Commits in Git, der von einem GUI-Client vorgenommen wurde.
- Mehrere Änderungen im gewünschten Zustand aufgrund eines PR in Git mit anschließender Erstellung des Container-Images und Änderungen an der Konfiguration.
- Änderung des Clusterzustands aufgrund eines Fehlers, Ressourcen-Konflikts, der zu "schlechtem Verhalten" führt, oder einfach einer zufälligen Abweichung vom ursprünglichen Zustand.
Was stellt der Konvergenzmechanismus dar?
Einige Beispiele:
- Für Container und Cluster stellt Kubernetes den Konvergenzmechanismus bereit.
- Der gleiche Mechanismus kann zur Verwaltung von Anwendungen und Konstruktionen auf Basis von Kubernetes (z. B. Istio und Kubeflow) verwendet werden.
- Der Mechanismus zur Verwaltung der Arbeitsinteraktion zwischen Kubernetes, Abbild-Repositorys und Git bietet , der Teil von .
- Für Basismaschinen muss der Konvergenzmechanismus deklarativ und autonom sein. Aus eigener Erfahrung können wir sagen, dass dieser Definition jedoch am nächsten kommt, es dennoch menschlicher Kontrolle bedarf. In diesem Sinne erweitert GitOps die Traditionen von Infrastructure as Code.
GitOps vereint Git mit einem hervorragenden Kubernetes-Konvergenzmechanismus und bietet ein Modell für den Betrieb.
GitOps ermöglicht es uns zu erklären: Automatisierung und Kontrolle sind nur für solche Systeme möglich, die beschrieben und beobachtet werden können..
GitOps ist für den gesamten Cloud-Native-Stack gedacht (z.B. Terraform usw.)
GitOps ist nicht nur Kubernetes. Wir wollen, dass das gesamte System deklarativ verwaltet wird und Konvergenz nutzt. Mit "Gesamtsystem" meinen wir eine Ansammlung von Umgebungen, die mit Kubernetes betrieben werden — zum Beispiel "dev cluster 1", "Produktion" usw. Jede Umgebung besteht aus Maschinen, Clustern, Anwendungen sowie Schnittstellen zu externen Diensten, die Daten, Überwachung usw. bereitstellen.
Beachten Sie, wie wichtig Terraform in diesem Fall für das Bootstrapping-Problem ist. Kubernetes muss irgendwo bereitgestellt werden, und die Verwendung von Terraform bedeutet, dass wir dieselben GitOps-Workflows anwenden können, um die Steuerungsebene unter Kubernetes und Anwendungen zu erstellen. Das ist eine nützliche bewährte Methode.
Ein großes Augenmerk liegt auf der Anwendung von GitOps-Konzepten auf Ebenen über Kubernetes. Momentan gibt es GitOps-Lösungen für Istio, Helm, Ksonnet, OpenFaaS und Kubeflow, sowie z.B. für Pulumi, was eine Schicht zum Entwickeln von Cloud-Native-Anwendungen schafft.
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 zur Schaffung einer entwicklerorientierten Umgebung für die Verwaltung von Anwendungen.
Für viele ist GitOps in erster Linie ein Workflow auf Basis von Git Pushs. Das gefällt uns auch. Aber das ist nicht alles: Lassen Sie uns nun die CI/CD-Pipelines betrachten.
GitOps ermöglicht kontinuierliche Bereitstellung (CD) unter Kubernetes.
GitOps bietet einen Mechanismus für kontinuierliche Bereitstellung, der die Notwendigkeit separater "Bereitstellungssysteme" überflüssig macht. Die gesamte Arbeit wird von Kubernetes für Sie erledigt.
- Die Aktualisierung der 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 Funktionsweise von Kubernetes sind diese Updates konvergent. Dies gewährleistet einen Mechanismus für kontinuierliches Deployment, bei dem alle Updates atomar sind.
- Hinweis: bietet einen GitOps-Operator, der Git und Kubernetes integriert und es ermöglicht, Continuous Delivery (CD) durch die Abstimmung des gewünschten und aktuellen Zustands des Clusters durchzuführen.
Ohne kubectl und Skripte
Die Verwendung von Kubectl zur Aktualisierung des Clusters sollte vermieden werden, insbesondere Skripte zur Gruppierung von kubectl-Befehlen. Stattdessen kann der Benutzer über eine GitOps-Pipeline seinen Kubernetes-Cluster über Git aktualisieren.
Die Vorteile umfassen:
- Richtigkeit. Eine Gruppe von Updates kann angewendet, konvergiert und schließlich validiert werden, was uns dem Ziel des atomaren Deployments näher bringt. Im Gegensatz dazu bieten Skripte keine Garantien für die Konvergenz (mehr dazu unten).
- Sicherheit. Kelsey Hightower: „Beschränken Sie den Zugriff auf den Kubernetes-Cluster auf Automatisierungswerkzeuge und Administratoren, die für dessen Debugging oder den Betrieb verantwortlich sind“. Siehe auch zur Sicherheit und Compliance mit technischen Anforderungen sowie durch den Diebstahl von Anmeldeinformationen aus einem nachlässig verfassten Jenkins-Skript.
- Benutzererfahrung. Kubectl legt die Mechanik des Kubernetes-Objektmodells offen, die sehr komplex ist. Ideal wäre es, wenn die Benutzer auf einer höheren Abstraktionsebene mit dem System interagieren. Hier verweise ich erneut auf Kelsey und empfehle, sich .
Der Unterschied zwischen CI und CD
GitOps verbessert bestehende CI/CD-Modelle.
Ein moderner CI-Server ist ein Werkzeug zur Orchestrierung. Insbesondere ist es ein Werkzeug zur Orchestrierung von CI-Pipelines. Diese umfassen Build, Test, Merge to Trunk usw. CI-Server automatisieren die Verwaltung komplexer mehrstufiger Pipelines. Eine verbreitete Versuchung besteht darin, ein Skript für die Aktualisierungen von Kubernetes zu erstellen und es als Teil der Pipeline zur Übertragung von Änderungen in den Cluster auszuführen. Tatsächlich verfahren viele Fachleute so. Aber das ist suboptimal, und das ist der Grund.
CI sollte verwendet werden, um Aktualisierungen in den trunk einzubringen, und der Kubernetes-Cluster sollte sich basierend auf diesen Aktualisierungen ändern, um CD „intern“ zu verwalten. Wir nennen das , im Gegensatz zum CI-Push-Modell. CD ist Teil der Laufzeit-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-Muster, über das wir in unserem Blog.
Kommen wir zurück zu Alice und Bob.
Mit welchen Problemen hatten sie zu kämpfen? Bobs CI-Server wendet Änderungen auf den Cluster an, aber wenn er während dieses Prozesses abstürzt, weiß Bob nicht, in welchem Zustand sich der Cluster befindet (oder befinden sollte) und wie er ihn reparieren kann. Das Gleiche gilt im Falle eines Erfolgs.
Angenommen, Bobs Team hat ein neues Image erstellt und dann seine Deployments gepatcht, um das Image bereitzustellen (alles aus dem CI-Pipeline).
Wenn das Image erfolgreich erstellt wird, aber die Pipeline abstürzt, muss das Team herausfinden:
- Wurde das Update bereitgestellt?
- Führen wir den neuen Build aus? Führt das zu unerwünschten Nebeneffekten – besteht die Möglichkeit, zwei Builds des gleichen unveränderten Images zu erhalten?
- Sollten wir auf das nächste Update warten, bevor wir den Build ausführen?
- Was genau ist schief gelaufen? Welche Schritte müssen wiederholt werden (und welche dürfen sicher wiederholt werden)?
Die Organisation eines Git-basierten Workflows garantiert nicht, dass Bobs Team nicht mit diesen Problemen konfrontiert wird. Sie können weiterhin beim Pushen des Commits, beim Tag oder einem anderen Parameter einen Fehler machen; dieser Ansatz ist jedoch dennoch viel näher am expliziten Alles-oder-Nichts.
Zusammenfassend: Hier ist der Grund, warum CI-Server sich nicht um CD kümmern sollten:
- Aktualisierungsskripte sind nicht immer deterministisch; man kann leicht Fehler machen.
- CI-Server konvergieren nicht zu einem deklarativen Modell des Clusters.
- Es ist schwierig, Idempotenz sicherzustellen. Benutzer müssen sich mit der tiefen Semantik des Systems auseinandersetzen.
- Es ist schwieriger, sich von teilweisen Ausfällen zu erholen.
Hinweis zu Helm: Wenn Sie Helm verwenden möchten, empfehlen wir, ihn mit einem GitOps-Operator wie zu kombinieren. Das hilft, Konvergenz zu gewährleisten. Helm ist für sich genommen weder deterministisch noch atomar.
GitOps als der beste Weg, um Continuous Delivery für Kubernetes zu realisieren
Das Team von Alice und Bob implementiert GitOps und stellt fest, dass die Arbeit mit Softwareprodukten, die Aufrechterhaltung von hoher Leistung und Stabilität wesentlich einfacher geworden ist. 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 Dienste sprechen, jedoch kann GitOps zur Verwaltung der gesamten Plattform eingesetzt werden.
Betriebsmodell für Kubernetes
Sehen Sie sich das folgende Diagramm an. Es stellt Git und das Container-Images-Repository als gemeinsame Ressourcen für zwei orchestrierte Lebenszyklen dar:
- Ein Pipeline für kontinuierliche Integration, der Dateien in Git liest und schreibt und möglicherweise das Container-Image-Repository aktualisiert.
- Eine Pipeline für Runtime GitOps, die Deployment mit Management und Überwachung kombiniert. Sie liest und schreibt Dateien in Git und kann Container-Images hochladen.
Was sind die wichtigsten Erkenntnisse?
- Trennung der Probleme: Beachten Sie, dass beide Pipelines Daten austauschen können, indem sie nur Git oder das Image-Repository aktualisieren. Mit anderen Worten, es gibt eine Netzwerkgrenze zwischen CI und Runtime-Umgebung. Wir nennen es "Unveränderlichkeits-Firewall" (immutability firewall), da alle Repository-Aktualisierungen neue Versionen erzeugen. Für weitere Informationen zu diesem Thema können Sie die Folien 72-87 konsultieren. .
- Jeder CI- und Git-Server kann verwendet werden: GitOps funktioniert mit allen Komponenten. Sie können weiterhin Ihre bevorzugten CI- und Git-Server, Image-Repositories und Test-Sets verwenden. Fast alle anderen Tools für Continuous Delivery auf dem Markt erfordern einen eigenen CI-/Git-Server oder ein Image-Repository. Dies kann zum begrenzenden Faktor bei der Entwicklung von Cloud-Native-Anwendungen werden. Im Fall von GitOps können Sie die gewohnten Werkzeuge verwenden.
- Ereignisse als Integrationswerkzeug: Sobald Daten in Git aktualisiert werden, informiert Weave Flux (oder der Weave Cloud Operator) darüber die Runtime. Jedes Mal, wenn Kubernetes eine Reihe von Änderungen annimmt, wird Git aktualisiert. Dies bietet ein einfaches Integrationsmodell für die Organisation von Workflows für GitOps, wie unten gezeigt.
Fazit
GitOps bietet wesentliche Garantien für Updates, die jedes moderne CI/CD-Tool benötigt:
- Automatisierung;
- Konvergenz;
- Idempotenz;
- Determinismus.
Das ist wichtig, da es ein Betriebsmodell für Entwickler im Bereich Cloud Native bietet.
- Traditionelle Werkzeuge zur Verwaltung und Überwachung von Systemen sind mit Betriebsteams verbunden, die im Rahmen eines Runbooks arbeiten, (eines Satzes von Routineverfahren und -operationen — Anm. d. Übers.)., das an ein bestimmtes Deployment gebunden ist.
- Im Management von Cloud Native-Systemen ist das Werkzeug zur Überwachung der beste Weg, um die Ergebnisse von Bereitstellungen zu bewerten, damit das Entwicklerteam schnell darauf reagieren kann.
Stellen Sie sich eine Vielzahl von Clustern vor, die über verschiedene Clouds verteilt sind, und viele Dienste mit eigenen Teams und Bereitstellungsplänen. GitOps bietet ein skalierbar-invariantes Modell, um all diese Vielfalt zu verwalten.
P.S. vom Übersetzer
Lesen Sie auch in unserem Blog:
- «»;
- «»;
- «».
Nur registrierte Benutzer können an der Umfrage teilnehmen. .
Wussten Sie von GitOps, bevor diese beiden Übersetzungen auf Habr erschienen?
Ja, ich wusste es.
Nur oberflächlich.
Nein
35 Benutzer haben abgestimmt. 10 Benutzer haben sich enthalten.
Quelle: habr.com
