Notiz. übersetzen: Nach einer aktuellen Veröffentlichung In Bezug auf Pull- und Push-Methoden in GitOps sahen wir generell Interesse an diesem Modell, aber es gab nur sehr wenige russischsprachige Veröffentlichungen zu diesem Thema (es gibt einfach keine auf Habré). Deshalb freuen wir uns, Ihnen die Übersetzung eines weiteren Artikels anbieten zu können – allerdings vor fast einem Jahr! – von Weaveworks, dessen Chef den Begriff „GitOps“ geprägt hat. Der Text erläutert das Wesentliche des Ansatzes und die wichtigsten Unterschiede zu bestehenden Ansätzen.
Vor einem Jahr haben wir veröffentlicht . Damals erzählten wir, wie das Weaveworks-Team ein vollständig auf Kubernetes basierendes SaaS auf den Markt brachte und eine Reihe präskriptiver Best Practices für die Bereitstellung, Verwaltung und Überwachung in einer Cloud-nativen Umgebung entwickelte.
Der Artikel erwies sich als beliebt. Andere Leute sprachen über GitOps und begannen, neue Tools dafür zu veröffentlichen , , , , usw. Erschien auf unserer Website Veröffentlichungen und GitOps-Anwendungsfälle. Aber einige Leute haben immer noch Fragen. Wie unterscheidet sich das Modell vom herkömmlichen? und kontinuierliche Lieferung ()? Ist es notwendig, Kubernetes zu verwenden?
Wir erkannten bald, dass eine neue Beschreibung erforderlich war, die Folgendes enthielt:
- Zahlreiche Beispiele und Geschichten;
- Spezifische Definition von GitOps;
- Vergleich mit traditioneller kontinuierlicher Lieferung.
In diesem Artikel haben wir versucht, alle diese Themen abzudecken. Es bietet eine aktualisierte Einführung in GitOps und eine Entwickler- und CI/CD-Perspektive. Wir konzentrieren uns hauptsächlich auf Kubernetes, obwohl das Modell verallgemeinert werden kann.
Lernen Sie GitOps kennen
Stellen Sie sich Alice vor. Sie leitet die Familienversicherung, die Kranken-, Auto-, Hausrat- und Reiseversicherungen für Menschen anbietet, die zu beschäftigt sind, um die Einzelheiten von Verträgen selbst herauszufinden. Ihr Unternehmen begann als Nebenprojekt, als Alice als Datenwissenschaftlerin bei einer Bank arbeitete. Eines Tages wurde ihr klar, dass sie fortschrittliche Computeralgorithmen nutzen konnte, um Daten effektiver zu analysieren und Versicherungspakete zu formulieren. Investoren finanzierten das Projekt, mittlerweile bringt ihr Unternehmen mehr als 20 Millionen US-Dollar pro Jahr ein und wächst rasant. Derzeit sind 180 Mitarbeiter in verschiedenen Positionen beschäftigt. Dazu gehört ein Technologieteam, das die Website und die Datenbank entwickelt, pflegt und den Kundenstamm analysiert. Das 60-köpfige Team wird von Bob, dem technischen Direktor des Unternehmens, geleitet.
Bobs Team stellt Produktionssysteme in der Cloud bereit. Ihre Kernanwendungen laufen auf GKE und nutzen die Vorteile von Kubernetes in Google Cloud. Darüber hinaus nutzen sie bei ihrer Arbeit verschiedene Daten- und Analysetools.
Family Insurance hatte nicht vor, Container zu verwenden, sondern wurde von der Docker-Begeisterung erfasst. Das Unternehmen stellte bald fest, dass GKE die Bereitstellung von Clustern zum Testen neuer Funktionen vereinfacht. Jenkins für CI und Quay wurden hinzugefügt, um die Container-Registrierung zu organisieren, und es wurden Skripte für Jenkins geschrieben, die neue Container und Konfigurationen an GKE weitergaben.
Es ist einige Zeit vergangen. Alice und Bob waren von der Leistung ihres gewählten Ansatzes und seinen Auswirkungen auf das Unternehmen enttäuscht. Die Einführung von Containern steigerte die Produktivität nicht so stark, wie das Team gehofft hatte. Manchmal brachen Bereitstellungen ab und es war unklar, ob Codeänderungen daran schuld waren. Außerdem erwies es sich als schwierig, Konfigurationsänderungen zu verfolgen. Oft war es notwendig, einen neuen Cluster zu erstellen und Anwendungen dorthin zu verschieben, da dies der einfachste Weg war, das Chaos im System zu beseitigen. Alice befürchtete, dass sich die Situation mit der Entwicklung der Anwendung verschlechtern würde (außerdem braute sich ein neues Projekt zusammen, das auf maschinellem Lernen basiert). Bob hatte den Großteil der Arbeit automatisiert und verstand nicht, warum die Pipeline immer noch instabil war, sich nicht gut skalieren ließ und regelmäßig manuelle Eingriffe erforderte?
Dann lernten sie GitOps kennen. Diese Entscheidung erwies sich als genau das, was sie brauchten, um selbstbewusst voranzukommen.
Alice und Bob hören seit Jahren von Git, DevOps und Infrastructure-as-Code-Workflows. Das Besondere an GitOps ist, dass es eine Reihe von Best Practices – sowohl endgültiger als auch normativer Art – für die Umsetzung dieser Ideen im Kontext von Kubernetes bereitstellt. Dieses Thema , auch in .
Die Familienversicherung entscheidet sich für die Implementierung von GitOps. Das Unternehmen verfügt nun über ein automatisiertes Betriebsmodell, das mit Kubernetes kompatibel ist und kombiniert Geschwindigkeit mit Stabilitätweil sie:
- stellte fest, dass sich die Produktivität des Teams verdoppelte, ohne dass jemand verrückt wurde;
- Die Bereitstellung von Skripten wurde eingestellt. Stattdessen können sie sich nun auf neue Funktionen konzentrieren und technische Methoden verbessern – zum Beispiel durch die Einführung von Canary-Rollouts und die Verbesserung von Tests;
- Wir haben den Bereitstellungsprozess so verbessert, dass es seltener zu Ausfällen kommt.
- erhielt die Möglichkeit, Bereitstellungen nach Teilausfällen ohne manuelles Eingreifen wiederherzustellen;
- gebraucht gekauftоGrößeres Vertrauen in Liefersysteme. Alice und Bob entdeckten, dass sie das Team in parallel arbeitende Microservice-Teams aufteilen konnten;
- kann durch die Bemühungen jeder Gruppe jeden Tag 30–50 Änderungen am Projekt vornehmen und neue Techniken ausprobieren;
- Es ist einfach, neue Entwickler für das Projekt zu gewinnen, die die Möglichkeit haben, Updates innerhalb weniger Stunden mithilfe von Pull-Requests in die Produktion auszurollen.
- Bestehen Sie problemlos das Audit im Rahmen von SOC2 (zur Einhaltung der Anforderungen an ein sicheres Datenmanagement durch Dienstleister; weiterlesen z.B. - ca. übersetzt).
Was ist passiert?
GitOps besteht aus zwei Dingen:
- Betriebsmodell für Kubernetes und Cloud Native. Es bietet eine Reihe bewährter Methoden für die Bereitstellung, Verwaltung und Überwachung von Container-Clustern und -Anwendungen. Elegante Definition im Formular aus :
- Der Weg zur Schaffung einer entwicklerzentrierten Anwendungsverwaltungsumgebung. Wir wenden den Git-Workflow sowohl auf den Betrieb als auch auf die Entwicklung an. Bitte beachten Sie, dass es hier nicht nur um Git-Push geht, sondern um die Organisation des gesamten Satzes an CI/CD- und UI/UX-Tools.
Ein paar Worte zu Git
Wenn Sie mit Versionskontrollsystemen und Git-basierten Arbeitsabläufen nicht vertraut sind, empfehlen wir Ihnen dringend, sich damit vertraut zu machen. Die Arbeit mit Branches und Pull Requests mag auf den ersten Blick wie schwarze Magie erscheinen, aber die Vorteile sind die Mühe wert. Hier für den Anfang.
Wie Kubernetes funktioniert
In unserer Geschichte wandten sich Alice und Bob an GitOps, nachdem sie eine Zeit lang mit Kubernetes gearbeitet hatten. Tatsächlich ist GitOps eng mit Kubernetes verwandt – es handelt sich um ein Betriebsmodell für Infrastruktur und Anwendungen, die auf Kubernetes basieren.
Was bietet Kubernetes Benutzern?
Hier sind einige Hauptmerkmale:
- Im Kubernetes-Modell kann alles in deklarativer Form beschrieben werden.
- Der Kubernetes-API-Server verwendet diese Deklaration als Eingabe und versucht dann kontinuierlich, den Cluster in den in der Deklaration beschriebenen Zustand zu versetzen.
- Deklarationen reichen aus, um eine Vielzahl von Workloads – „Anwendungen“ – zu beschreiben und zu verwalten.
- Infolgedessen kommt es zu Änderungen an der Anwendung und am Cluster aus folgenden Gründen:
- Änderungen in Containerbildern;
- Änderungen an der deklarativen Spezifikation;
- Fehler in der Umgebung – zum Beispiel Containerabstürze.
Die großartigen Konvergenzfähigkeiten von Kubernetes
Wenn ein Administrator Konfigurationsänderungen vornimmt, wendet der Kubernetes-Orchestrator diese auf den Cluster an, solange dieser sich in diesem Zustand befindet wird nicht annähernd an die neue Konfiguration herankommen. Dieses Modell funktioniert für jede Kubernetes-Ressource und ist mit benutzerdefinierten Ressourcendefinitionen (CRDs) erweiterbar. Daher verfügen Kubernetes-Bereitstellungen über die folgenden wunderbaren Eigenschaften:
- Automatisierung: Kubernetes-Updates bieten einen Mechanismus zur Automatisierung des Prozesses der ordnungsgemäßen und zeitnahen Anwendung von Änderungen.
- Konvergenz: Kubernetes wird bis zum Erfolg weiterhin versuchen, Aktualisierungen durchzuführen.
- Idempotenz: Wiederholte Konvergenzanwendungen führen zum gleichen Ergebnis.
- Determinismus: Wenn die Ressourcen ausreichend sind, hängt der Status des aktualisierten Clusters nur vom gewünschten Status ab.
So funktioniert GitOps
Wir haben genug über Kubernetes gelernt, um zu erklären, wie GitOps funktioniert.
Kehren wir zu den Microservices-Teams von Family Insurance zurück. Was müssen sie normalerweise tun? Schauen Sie sich die Liste unten an (sollten Ihnen darin Elemente seltsam oder unbekannt vorkommen, halten Sie sich bitte mit Kritik zurück und bleiben Sie bei uns). Dies sind nur Beispiele für Jenkins-basierte Workflows. Bei der Arbeit mit anderen Tools gibt es viele andere Prozesse.
Die Hauptsache ist, dass wir sehen, dass jedes Update mit Änderungen an den Konfigurationsdateien und Git-Repositorys endet. Diese Änderungen an Git veranlassen den „GitOps-Operator“, den Cluster zu aktualisieren:
1.Arbeitsprozess: „Jenkins-Build – Master-Zweig".
Aufgabenliste:
- Jenkins schiebt getaggte Bilder an Quay;
- Jenkins verschiebt Konfigurations- und Helm-Charts in den Master-Speicher-Bucket;
- Die Cloud-Funktion kopiert die Konfiguration und Diagramme vom Master-Storage-Bucket in das Master-Git-Repository;
- Der GitOps-Operator aktualisiert den Cluster.
2. Jenkins-Build – Release- oder Hotfix-Zweig:
- Jenkins schiebt Bilder ohne Tags an Quay;
- Jenkins verschiebt Konfigurations- und Helm-Diagramme in den Staging-Speicher-Bucket;
- Die Cloud-Funktion kopiert die Konfiguration und Diagramme aus dem Staging-Speicher-Bucket in das Staging-Git-Repository.
- Der GitOps-Operator aktualisiert den Cluster.
3. Jenkins-Build – Entwicklungs- oder Feature-Zweig:
- Jenkins schiebt Bilder ohne Tags an Quay;
- Jenkins schiebt Konfigurations- und Helm-Diagramme in den Entwicklungsspeicher-Bucket;
- Die Cloud-Funktion kopiert die Konfiguration und Diagramme aus dem Entwicklungsspeicher-Bucket in das Entwicklungs-Git-Repository.
- Der GitOps-Operator aktualisiert den Cluster.
4. Einen neuen Kunden hinzufügen:
- Der Manager oder Administrator (LCM/Ops) ruft Gradle an, um zunächst Netzwerk-Load-Balancer (NLBs) bereitzustellen und zu konfigurieren;
- LCM/ops schreibt eine neue Konfiguration vor, um die Bereitstellung auf Updates vorzubereiten;
- Der GitOps-Operator aktualisiert den Cluster.
Kurze Beschreibung von GitOps
- Beschreiben Sie den gewünschten Zustand des gesamten Systems mithilfe deklarativer Spezifikationen für jede Umgebung (in unserer Geschichte definiert Bobs Team die gesamte Systemkonfiguration in Git).
- Das Git-Repository ist die einzige Quelle der Wahrheit über den gewünschten Zustand des gesamten Systems.
- Alle Änderungen am gewünschten Zustand werden durch Commits in Git vorgenommen.
- Alle gewünschten Clusterparameter sind auch im Cluster selbst beobachtbar. Auf diese Weise können wir feststellen, ob sie übereinstimmen (konvergieren, konvergieren) oder unterscheiden (divergieren, divergieren) gewünschte und beobachtete Zustände.
- Wenn der gewünschte und der beobachtete Zustand unterschiedlich sind, dann:
- Es gibt einen Konvergenzmechanismus, der früher oder später den Zielzustand und den beobachteten Zustand automatisch synchronisiert. Innerhalb des Clusters erledigt Kubernetes dies.
- Der Prozess beginnt sofort mit der Meldung „Änderung festgeschrieben“.
- Nach einem konfigurierbaren Zeitraum kann eine „Diff“-Benachrichtigung gesendet werden, wenn die Zustände unterschiedlich sind.
- Auf diese Weise führen alle Commits in Git zu überprüfbaren und idempotenten Aktualisierungen des Clusters.
- Rollback ist die Konvergenz zu einem zuvor gewünschten Zustand.
- Die Konvergenz ist endgültig. Sein Vorkommen wird angezeigt durch:
- Für einen bestimmten Zeitraum gibt es keine Diff-Warnungen.
- „konvergierte“ Warnung (z. B. Webhook, Git-Writeback-Ereignis).
Was ist Divergenz?
Wiederholen wir es noch einmal: Alle gewünschten Clustereigenschaften müssen im Cluster selbst beobachtbar sein.
Einige Beispiele für Divergenz:
- Änderung in der Konfigurationsdatei aufgrund der Zusammenführung von Zweigen in Git.
- Eine Änderung in der Konfigurationsdatei aufgrund eines Git-Commits durch den GUI-Client.
- Mehrere Änderungen am gewünschten Zustand aufgrund von PR in Git, gefolgt vom Erstellen des Container-Images und Konfigurationsänderungen.
- Eine Änderung des Status des Clusters aufgrund eines Fehlers, eines Ressourcenkonflikts, der zu „schlechtem Verhalten“ führt, oder einfach einer zufälligen Abweichung vom ursprünglichen Status.
Was ist der Konvergenzmechanismus?
Einige Beispiele:
- Für Container und Cluster wird der Konvergenzmechanismus von Kubernetes bereitgestellt.
- Der gleiche Mechanismus kann zur Verwaltung von Kubernetes-basierten Anwendungen und Designs (wie Istio und Kubeflow) verwendet werden.
- Bietet einen Mechanismus zur Verwaltung der betrieblichen Interaktion zwischen Kubernetes, Image-Repositories und Git , was ein Teil ist .
- Für Basismaschinen muss der Konvergenzmechanismus deklarativ und autonom sein. Aus eigener Erfahrung können wir das sagen kommt dieser Definition am nächsten, erfordert aber dennoch menschliche Kontrolle. In diesem Sinne erweitert GitOps die Tradition von Infrastructure as Code.
GitOps kombiniert Git mit der hervorragenden Konvergenz-Engine von Kubernetes, um ein Modell für die Nutzung bereitzustellen.
Mit GitOps können wir sagen: Nur beschreibbare und beobachtbare Systeme lassen sich automatisieren und steuern.
GitOps ist für den gesamten cloudnativen Stack gedacht (z. B. Terraform usw.)
GitOps ist nicht nur Kubernetes. Wir möchten, dass das gesamte System deklarativ gesteuert wird und Konvergenz nutzt. Mit dem gesamten System meinen wir eine Sammlung von Umgebungen, die mit Kubernetes arbeiten – zum Beispiel „Entwicklungscluster 1“, „Produktion“ usw. Jede Umgebung umfasst Maschinen, Cluster, Anwendungen sowie Schnittstellen für externe Dienste, die Daten und Überwachung bereitstellen usw.
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 Kontrollschicht zu erstellen, die Kubernetes und Anwendungen zugrunde liegt. Dies ist eine nützliche Best Practice.
Ein starker Fokus liegt auf der Anwendung von GitOps-Konzepten auf Schichten über Kubernetes. Derzeit gibt es Lösungen vom Typ GitOps für Istio, Helm, Ksonnet, OpenFaaS und Kubeflow sowie beispielsweise für Pulumi, die eine Ebene für die Entwicklung von Anwendungen für Cloud Native schaffen.
Kubernetes CI/CD: Vergleich von GitOps mit anderen Ansätzen
Wie bereits erwähnt, besteht GitOps aus zwei Dingen:
- Das oben beschriebene Betriebsmodell für Kubernetes und Cloud Native.
- Der Weg zu einer entwicklerzentrierten Anwendungsverwaltungsumgebung.
Für viele ist GitOps in erster Linie ein Workflow, der auf Git-Pushes basiert. Wir mögen ihn auch. Aber das ist noch nicht alles: Schauen wir uns nun die CI/CD-Pipelines an.
GitOps ermöglicht Continuous Deployment (CD) für Kubernetes
GitOps bietet einen kontinuierlichen Bereitstellungsmechanismus, der separate „Bereitstellungsverwaltungssysteme“ überflüssig macht. Kubernetes erledigt die ganze Arbeit für Sie.
- Das Aktualisieren der Anwendung erfordert eine Aktualisierung in Git. Dies ist eine transaktionale Aktualisierung des gewünschten Status. Das „Deployment“ erfolgt dann innerhalb des Clusters durch Kubernetes selbst auf Basis der aktualisierten Beschreibung.
- Aufgrund der Funktionsweise von Kubernetes sind diese Updates konvergent. Dies bietet einen Mechanismus für die kontinuierliche Bereitstellung, bei dem alle Updates atomar sind.
- Hinweis: bietet einen GitOps-Operator, der Git und Kubernetes integriert und die Durchführung von CD durch den Abgleich des gewünschten und aktuellen Status des Clusters ermöglicht.
Ohne Kubectl und Skripte
Sie sollten Kubectl nicht zum Aktualisieren Ihres Clusters verwenden und insbesondere keine Skripts zum Gruppieren von Kubectl-Befehlen verwenden. Stattdessen kann ein Benutzer mit der GitOps-Pipeline seinen Kubernetes-Cluster über Git aktualisieren.
Zu den Vorteilen gehören:
- Rechts. Eine Gruppe von Updates kann angewendet, konvergiert und schließlich validiert werden, was uns dem Ziel der atomaren Bereitstellung näher bringt. Im Gegensatz dazu bietet die Verwendung von Skripten keine Konvergenzgarantie (mehr dazu weiter unten).
- Sicherheit. Kelsey Hightower: „Beschränken Sie den Zugriff auf Ihren Kubernetes-Cluster auf Automatisierungstools und Administratoren, die für das Debuggen oder die Wartung verantwortlich sind.“ siehe auch über Sicherheit und Einhaltung technischer Spezifikationen, sowie durch den Diebstahl von Anmeldeinformationen aus einem nachlässig geschriebenen Jenkins-Skript.
- Benutzererfahrung. Kubectl legt die Mechanik des Kubernetes-Objektmodells offen, die recht komplex ist. Idealerweise sollten Benutzer auf einer höheren Abstraktionsebene mit dem System interagieren. Auch hier verweise ich wieder auf Kelsey und empfehle das Anschauen .
Unterschied zwischen CI und CD
GitOps verbessert bestehende CI/CD-Modelle.
Ein moderner CI-Server ist ein Orchestrierungstool. Insbesondere handelt es sich um ein Tool zur Orchestrierung von CI-Pipelines. Dazu gehören Erstellen, Testen, Zusammenführen zum Trunk usw. CI-Server automatisieren die Verwaltung komplexer mehrstufiger Pipelines. Eine häufige Versuchung besteht darin, eine Reihe von Kubernetes-Updates zu skripten und als Teil einer Pipeline auszuführen, um Änderungen an den Cluster zu übertragen. Tatsächlich ist es das, was viele Experten tun. Dies ist jedoch nicht optimal, und hier erfahren Sie, warum.
CI sollte verwendet werden, um Aktualisierungen an den Trunk zu übertragen, und der Kubernetes-Cluster sollte sich basierend auf diesen Aktualisierungen selbst ändern, um die CD intern zu verwalten. Wir nennen es , im Gegensatz zum CI-Push-Modell. CD ist Teil Laufzeitorchestrierung.
Warum CI-Server keine CDs über direkte Updates in Kubernetes erstellen sollten
Verwenden Sie keinen CI-Server, um direkte Updates für Kubernetes als Satz von CI-Jobs zu orchestrieren. Das ist das Anti-Pattern, von dem wir sprechen auf deinem Blog.
Kehren wir zu Alice und Bob zurück.
Mit welchen Problemen waren sie konfrontiert? Bobs CI-Server wendet die Änderungen auf den Cluster an, aber wenn er dabei abstürzt, weiß Bob nicht, in welchem Zustand sich der Cluster befindet (oder sein sollte) und wie er das Problem beheben kann. Dasselbe gilt auch im Erfolgsfall.
Nehmen wir an, dass Bobs Team ein neues Image erstellt und dann seine Bereitstellungen gepatcht hat, um das Image bereitzustellen (alles aus der CI-Pipeline).
Wenn das Image normal erstellt wird, die Pipeline jedoch ausfällt, muss das Team Folgendes herausfinden:
- Ist das Update ausgerollt?
- Starten wir einen neuen Build? Wird dies zu unnötigen Nebenwirkungen führen – mit der Möglichkeit, dass zwei Builds desselben unveränderlichen Images vorliegen?
- 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 können sicher wiederholt werden)?
Die Einrichtung eines Git-basierten Workflows garantiert nicht, dass Bobs Team nicht auf diese Probleme stößt. Sie können immer noch einen Fehler mit dem Commit-Push, dem Tag oder einem anderen Parameter machen; Allerdings kommt dieser Ansatz einem expliziten Alles-oder-Nichts-Ansatz immer noch viel näher.
Zusammenfassend lässt sich sagen, dass CI-Server sich nicht mit CDs befassen sollten:
- Aktualisierungsskripte sind nicht immer deterministisch. Es ist leicht, darin Fehler zu machen.
- CI-Server konvergieren nicht zum deklarativen Clustermodell.
- Es ist schwierig, Idempotenz zu garantieren. Benutzer müssen die tiefe Semantik des Systems verstehen.
- Es ist schwieriger, sich von einem teilweisen Ausfall zu erholen.
Hinweis zu Helm: Wenn Sie Helm verwenden möchten, empfehlen wir die Kombination mit einem GitOps-Operator wie z . Dies wird dazu beitragen, die Konvergenz sicherzustellen. Helm selbst ist weder deterministisch noch atomar.
GitOps als beste Möglichkeit, Continuous Delivery für Kubernetes zu implementieren
Das Team von Alice und Bob implementiert GitOps und stellt fest, dass es viel einfacher geworden ist, mit Softwareprodukten zu arbeiten und eine hohe Leistung und Stabilität aufrechtzuerhalten. Lassen Sie uns diesen Artikel mit einer Illustration beenden, die zeigt, wie ihr neuer Ansatz aussieht. Bedenken Sie, dass es sich hier hauptsächlich um Anwendungen und Dienste handelt, GitOps jedoch zur Verwaltung einer gesamten Plattform verwendet werden kann.
Betriebsmodell für Kubernetes
Schauen Sie sich das folgende Diagramm an. Es präsentiert Git und das Container-Image-Repository als gemeinsame Ressourcen für zwei orchestrierte Lebenszyklen:
- Eine kontinuierliche Integrationspipeline, die Dateien in Git liest und schreibt und ein Repository mit Container-Images aktualisieren kann.
- Eine Laufzeit-GitOps-Pipeline, die Bereitstellung mit Verwaltung und Beobachtbarkeit kombiniert. Es liest und schreibt Dateien in Git und kann Container-Images herunterladen.
Was sind die wichtigsten Erkenntnisse?
- Trennung von Bedenken: Bitte beachten Sie, dass beide Pipelines nur durch Aktualisierung von Git oder dem Image-Repository kommunizieren können. Mit anderen Worten: Es gibt eine Firewall zwischen CI und der Laufzeitumgebung. Wir nennen es die „Unveränderlichkeits-Firewall“ (Unveränderlichkeits-Firewall), da alle Repository-Updates neue Versionen erstellen. Weitere Informationen zu diesem Thema finden Sie auf den Folien 72-87 .
- Sie können jeden CI- und Git-Server verwenden: GitOps funktioniert mit jeder Komponente. Sie können weiterhin Ihre bevorzugten CI- und Git-Server, Image-Repositorys und Testsuiten verwenden. Fast alle anderen Continuous-Delivery-Tools auf dem Markt erfordern einen eigenen CI/Git-Server oder ein eigenes Image-Repository. Dies kann zu einem limitierenden Faktor bei der Entwicklung von Cloud Native werden. Mit GitOps können Sie bekannte Tools nutzen.
- Events als Integrationstool: Sobald Daten in Git aktualisiert werden, benachrichtigt Weave Flux (oder der Weave Cloud-Operator) die Laufzeit. Immer wenn Kubernetes einen Änderungssatz akzeptiert, wird Git aktualisiert. Dies stellt ein einfaches Integrationsmodell zum Organisieren von Workflows für GitOps bereit, wie unten gezeigt.
Abschluss
GitOps bietet die starken Update-Garantien, die jedes moderne CI/CD-Tool benötigt:
- Automatisierung;
- Konvergenz;
- Idempotenz;
- Determinismus.
Dies ist wichtig, da es ein Betriebsmodell für Cloud-native-Entwickler bietet.
- Herkömmliche Tools zur Verwaltung und Überwachung von Systemen sind mit Betriebsteams verknüpft, die innerhalb eines Runbooks arbeiten (eine Reihe von Routineverfahren und -operationen – ca. übersetzt), an eine bestimmte Bereitstellung gebunden.
- Beim cloudnativen Management sind Observability-Tools die beste Möglichkeit, die Ergebnisse von Bereitstellungen zu messen, damit das Entwicklungsteam schnell reagieren kann.
Stellen Sie sich viele über verschiedene Clouds verstreute Cluster und viele Dienste mit eigenen Teams und Bereitstellungsplänen vor. GitOps bietet ein skaleninvariantes Modell zur Verwaltung all dieser Fülle.
PS vom Übersetzer
Lesen Sie auch auf unserem Blog:
- «";
- «";
- «".
An der Umfrage können nur registrierte Benutzer teilnehmen. bitte.
Wussten Sie von GitOps, bevor diese beiden Übersetzungen auf Habré erschienen?
-
Ja, ich wusste alles
-
Nur oberflächlich
-
Nein
35 Benutzer haben abgestimmt. 10 Benutzer enthielten sich der Stimme.
Source: habr.com