👩🏻‍⚕️ 🤵🏼 🍃 Was ist GitOps? ⚓️ 🍜 🔻

Hinweis perev. : Nach der jüngsten Veröffentlichung von Material zu Pull- und Push-Methoden in GitOps haben wir Interesse an diesem Modell als Ganzes gesehen. Es gab jedoch nur sehr wenige russischsprachige Veröffentlichungen zu diesem Thema (sie befinden sich einfach nicht im Hub). Wir freuen uns daher, Sie auf eine Übersetzung eines anderen Artikels aufmerksam zu machen - allerdings vor fast einem Jahr! - von der Firma Weaveworks, deren Leiter den Begriff "GitOps" geprägt hat. Der Text erklärt das Wesentliche des Ansatzes und die wichtigsten Unterschiede zu bestehenden.

Vor einem Jahr haben wir eine Einführung in GitOps veröffentlicht . Anschließend sprachen wir darüber, wie das Weaveworks-Team SaaS auf Kubernetes-Basis gestartet und eine Reihe von Best Practices für die Bereitstellung, Verwaltung und Überwachung in einer Cloud-nativen Umgebung entwickelt hat.

Der Artikel erwies sich als beliebt. Andere Leute sprachen über GitOps und veröffentlichten neue Tools für Git Push , Entwicklung , Geheimnisse , Funktionen , kontinuierliche Integration usw. Eine große Anzahl von Veröffentlichungen und Anwendungsfällen von GitOps ist auf unserer Website erschienen. Aber einige Leute haben noch Fragen. Wie unterscheidet sich das Modell von der herkömmlichen Infrastruktur als Code und kontinuierliche Bereitstellung? Ist die Verwendung von Kubernetes obligatorisch?

Bald stellten wir fest, dass eine neue Beschreibung erforderlich war, die Folgendes bot:

Eine große Anzahl von Beispielen und Geschichten;
Die spezifische Definition von GitOps;
Vergleich mit traditioneller kontinuierlicher Lieferung.

In diesem Artikel haben wir versucht, alle diese Themen zu behandeln. Darin finden Sie eine aktualisierte Einführung in GitOps und einen Blick von Seiten der Entwickler und von CI / CD. Wir konzentrieren uns hauptsächlich auf Kubernetes, obwohl das Modell verallgemeinert werden kann.

Treffen Sie GitOps

Stellen Sie sich Alice vor. Sie leitet die Familienversicherung, ein Unternehmen, das Kranken-, Auto-, Immobilien- und Reiseversicherungen für Menschen anbietet, die zu beschäftigt sind, um die Nuancen ihrer Verträge selbst zu verstehen. Ihr Geschäft begann als Nebenprojekt, als Alice als Datenwissenschaftlerin bei der Bank arbeitete. Als sie erkannte, dass sie fortschrittliche Computeralgorithmen verwenden konnte, um Daten effizienter zu analysieren und Versicherungspakete zu bilden. Investoren haben das Projekt finanziert, und jetzt bringt ihr Unternehmen mehr als 20 Millionen US-Dollar pro Jahr ein und wächst rasant. Derzeit arbeiten 180 Personen in verschiedenen Positionen. Darunter ein Technologieteam, das eine Site und eine Datenbank entwickelt, pflegt und den Kundenstamm analysiert. Ein Team von 60 Mitarbeitern wird von Bob, dem technischen Direktor des Unternehmens, geleitet.

Bobs Team setzt Produktionssysteme in der Cloud ein. Ihre Hauptanwendungen laufen auf GKE und nutzen Kubernetes in Google Cloud. Darüber hinaus verwenden sie verschiedene Tools für die Arbeit mit Daten und Analysen in ihrer Arbeit.

Die Familienversicherung wollte keine Container verwenden, war aber von der Begeisterung für Docker befallen. Bald stellten Unternehmensexperten fest, dass GKE die Bereitstellung von Clustern zum Testen neuer Funktionen einfach und unkompliziert macht. Jenkins für CI und Quay wurden hinzugefügt, um die Containerregistrierung zu organisieren. Es wurden Skripte für Jenkins geschrieben, die Push- oder neue Container und Konfigurationen in GKE enthalten.

Einige Zeit ist vergangen. Alice und Bob waren enttäuscht von der Leistung des gewählten Ansatzes und seinen Auswirkungen auf das Geschäft. Die Einführung von Containern erhöhte die Produktivität nicht so sehr, wie das Team gehofft hatte. Manchmal brachen Bereitstellungen aus und es war unklar, ob die Codeänderungen schuld waren. Es stellte sich auch als schwierig heraus, Änderungen in Konfigurationen zu verfolgen. Oft war es notwendig, einen neuen Cluster zu erstellen und Anwendungen in diesen zu verschieben, da dies der einfachste Weg war, um das Chaos zu beseitigen, in das sich das System verwandelte. 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 basierte). Bob automatisierte den größten Teil der Arbeit und verstand nicht, warum die Pipeline immer noch instabil ist, nicht gut skaliert und von Zeit zu Zeit manuelle Eingriffe erfordert?

Dann lernten sie GitOps kennen. Diese Entscheidung erwies sich als genau das, was sie brauchten, um sicher voranzukommen.

Alice und Bob haben jahrelang von Workflows gehört, die auf Git, DevOps und Infrastruktur als Code basieren. Die Einzigartigkeit von GitOps besteht darin, dass es eine Reihe von Best Practices - kategorisch und normativ - bringt, um diese Ideen im Kontext von Kubernetes umzusetzen. Dieses Thema wurde wiederholt angesprochen , auch im Weaveworks-Blog .

Die Familienversicherung beschließt, GitOps zu implementieren. Das Unternehmen verfügt nun über ein mit Kubernetes kompatibles automatisiertes Betriebsmodell, das Geschwindigkeit mit Stabilität kombiniert, da:

festgestellt, dass das Team die Produktivität verdoppelt hat und niemand verrückt wird;
hat die Wartung von Skripten eingestellt. Stattdessen können sie sich jetzt auf neue Funktionen konzentrieren und die technischen Methoden verbessern - beispielsweise kanarische Roll-outs einführen und Tests verbessern;
verbesserter Bereitstellungsprozess - jetzt bricht er selten ab;
die Möglichkeit erhalten, Bereitstellungen nach Teilfehlern ohne manuelles Eingreifen wiederherzustellen;
mehr Vertrauen in die Versorgungssysteme gewonnen. Alice und Bob stellten fest, dass das Team in Gruppen unterteilt werden kann, die in Microservices arbeiten und parallel arbeiten.
kann durch die Bemühungen jeder Gruppe jeden Tag 30-50 Änderungen am Projekt vornehmen und neue Techniken ausprobieren;
Sie werden leicht von neuen Entwicklern für das Projekt angezogen, die in der Lage sind, Aktualisierungen der Produktion mithilfe von Pull-Anforderungen in wenigen Stunden durchzuführen.
Einfache Prüfung innerhalb von SOC2 (zur Einhaltung der Anforderungen für die sichere Datenverwaltung durch Dienstanbieter; lesen Sie beispielsweise hier mehr - ca. übersetzt) .

Was ist passiert?

GitOps sind zwei Dinge:

Betriebsmodell für Kubernetes und Cloud Native. Es bietet eine Reihe von Best Practices für die Bereitstellung, Verwaltung und Überwachung von containerisierten Clustern und Anwendungen. Elegante Definition in einer einzigen Folie von Luis Faceira :
Der Weg zum Erstellen einer entwicklerorientierten Umgebung für die Verwaltung von Anwendungen. Wir wenden den Git-Workflow sowohl auf die Nutzung 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 von CI / CD- und UI / UX-Tools.

Ein paar Worte zu Git

Wenn Sie mit Versionskontrollsystemen und dem Git-basierten Workflow nicht vertraut sind, empfehlen wir Ihnen dringend, diese zu studieren. Auf den ersten Blick mag die Arbeit mit Zweigen und Pull-Anfragen wie schwarze Magie erscheinen, aber die Profis sind die Mühe wert. Hier ist ein guter Artikel , um Ihnen den Einstieg zu erleichtern.

Wie Kubernetes funktioniert

In unserer Geschichte wandten sich Alice und Bob an GitOps, nachdem sie eine Weile mit Kubernetes gearbeitet hatten. In der Tat ist GitOps eng mit Kubernetes verbunden - es ist ein Betriebsmodell für die auf Kubernetes basierende Infrastruktur und Anwendungen.

Was gibt Kubernetes Benutzern?

Hier sind einige wichtige Funktionen:

Im Kubernetes-Modell kann alles deklarativ 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 bringen.
Erklärungen reichen aus, um eine Vielzahl von Workloads zu beschreiben und zu verwalten - „Anwendungen“.
Infolgedessen sind Änderungen an der Anwendung und am Cluster auf Folgendes zurückzuführen:
- Änderungen an Containerbildern;
- Änderungen der deklarativen Spezifikation;
- Fehler in der Umgebung - zum Beispiel Containerabstürze.

Kubernetes 'große Konvergenzfähigkeiten

Wenn ein Administrator Konfigurationsänderungen vornimmt, wendet der Kubernetes-Orchestrator diese auf den Cluster an, bis sich sein Status der neuen Konfiguration nähert . Dieses Modell funktioniert für jede Kubernetes-Ressource und wird mit benutzerdefinierten Ressourcendefinitionen (CRDs) erweitert. Daher weisen Kubernetes-Bereitstellungen die folgenden wunderbaren Eigenschaften auf:

Automatisierung : Kubernetes-Updates bieten einen Mechanismus, um den Prozess der korrekten und zeitnahen Anwendung von Änderungen zu automatisieren.
Konvergenz : Kubernetes wird weiterhin versuchen, Aktualisierungen bis zum Erfolg vorzunehmen.
Idempotenz : Wiederholte Konvergenzanwendungen führen zum gleichen Ergebnis.
Determinismus : Bei ausreichenden Ressourcen hängt der Status des aktualisierten Clusters nur vom gewünschten Status ab.

Wie GitOps funktioniert

Wir haben genug über Kubernetes gelernt, um zu erklären, wie GitOps funktioniert.

Kehren wir zu den Familienversicherungsteams zurück, die sich mit Microservices befassen. Was müssen sie normalerweise tun? Schauen Sie sich die Liste unten an (wenn Punkte darin seltsam oder ungewohnt erscheinen - verschieben Sie bitte die Kritik 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 in Git bewirken, dass die "GitOps-Anweisung" den Cluster aktualisiert:

1. Workflow: „ Jenkins Build - Hauptzweig “.
Die Liste der Aufgaben:

Jenkins Push-Tagged-Bilder in Quay;
Jenkins schiebt seine Konfigurations- und Helm-Diagramme in den Master-Speicherbereich.
Die Cloud-Funktion kopiert die Konfiguration und die Diagramme aus dem Master-Speicher-Bucket in das Master-Git-Repository.
Die GitOps-Anweisung aktualisiert den Cluster.

2. Jenkins Build - Release oder Hotfix - Zweig :

Jenkins schiebt Bilder ohne Tags in Quay;
Jenkins schiebt die Konfigurations- und Helm-Diagramme in den Eimer mit dem Staging-Speicher.
Die Cloud-Funktion kopiert die Konfiguration und die Diagramme aus dem Bucket des Staging-Speichers in das Git-Repository-Staging.
Die GitOps-Anweisung aktualisiert den Cluster.

3. Jenkins Build - Entwickeln oder Feature-Zweig :

Jenkins schiebt Bilder ohne Tags in Quay;
Jenkins schiebt die Konfigurations- und Helmdiagramme in den Entwicklungsspeicherbereich.
Die Cloud-Funktion kopiert die Konfiguration und die Diagramme aus dem Entwicklungsspeicher-Bucket in das Entwicklungs-Git-Repository.
Die GitOps-Anweisung aktualisiert den Cluster.

4. Hinzufügen eines neuen Clients :

Ein Manager oder Administrator (LCM / ops) ruft Gradle an, um zunächst Network Load Balancer (NLBs) bereitzustellen und zu konfigurieren.
LCM / ops schreibt eine neue Konfiguration fest, um die Bereitstellung für Updates vorzubereiten.
Die GitOps-Anweisung aktualisiert den Cluster.

Kurzbeschreibung von GitOps

Beschreiben Sie den gewünschten Status des gesamten Systems anhand deklarativer Spezifikationen für jede Umgebung (in unserer Geschichte definiert das Bob-Team die gesamte Systemkonfiguration in Git).
- Das Git-Repository ist die einzige Wahrheitsquelle in Bezug auf den gewünschten Zustand des gesamten Systems.
- Alle Änderungen am gewünschten Status werden durch Commits in Git vorgenommen.
- Alle gewünschten Clusterparameter können auch im Cluster selbst beobachtet werden. Somit können wir bestimmen, ob die gewünschten und beobachteten Zustände zusammenfallen (konvergieren, konvergieren ) oder sich unterscheiden ( divergieren , divergieren ).
Wenn die gewünschten und beobachteten Zustände unterschiedlich sind, dann:
- Es gibt einen Konvergenzmechanismus, der früher oder später das Ziel und die beobachteten Zustände automatisch synchronisiert. Innerhalb des Clusters erledigt Kubernetes dies.
- Der Prozess beginnt sofort mit einer Benachrichtigung über festgeschriebene Änderungen.
- Nach einer konfigurierbaren Zeitspanne kann eine Diff-Warnung gesendet werden, wenn die Zustände unterschiedlich sind.
Somit lösen alle Commits in Git überprüfbare und idempotente Aktualisierungen im Cluster aus.
- Rollback ist eine Konvergenz zu einem zuvor gewünschten Zustand.
Konvergenz ist endgültig. Über seinen Beginn bezeugen:
- Fehlende "Diff" -Warnungen für einen bestimmten Zeitraum.
- Eine konvergierte Warnung (z. B. Webhook, Git Writeback-Ereignis).

Was ist Divergenz?

Wir wiederholen noch einmal: Alle gewünschten Eigenschaften des Clusters sollten im Cluster selbst beobachtbar sein .

Einige Beispiele für Abweichungen:

Änderung in der Konfigurationsdatei durch Zusammenführen von Zweigen in Git.
Eine Änderung in der Konfigurationsdatei aufgrund eines vom GUI-Client vorgenommenen Commits in Git.
Mehrfache Änderungen im gewünschten Status aufgrund von PR in Git mit der anschließenden Zusammenstellung des Container-Images und Änderungen an der Konfiguration.
Änderung des Clusterstatus aufgrund eines Fehlers, eines Ressourcenkonflikts, der zu „schlechtem Verhalten“ führt, oder nur einer versehentlichen Abweichung vom ursprünglichen Status.

Was ist ein Konvergenzmechanismus?

Einige Beispiele:

Für Container und Cluster bietet der Konvergenzmechanismus Kubernetes.
Der gleiche Mechanismus kann verwendet werden, um Kubernetes-basierte Anwendungen und Designs (z. B. Istio und Kubeflow) zu verwalten.
Der Mechanismus zum Verwalten der Arbeitsinteraktion zwischen Kubernetes, Image-Repositorys und Git wird vom Weave Flux GitOps-Operator bereitgestellt , der Teil der Weave Cloud ist .
Für Basismaschinen muss der Konvergenzmechanismus deklarativ und autonom sein. Aus eigener Erfahrung können wir sagen, dass Terraform dieser Definition am nächsten kommt, aber dennoch menschliche Kontrolle erfordert. In diesem Sinne erweitert GitOps die Tradition der Infrastruktur als Code.

GitOps kombiniert Git mit der hervorragenden Konvergenz-Engine von Kubernetes und bietet ein Modell für den Betrieb.

Mit GitOps können wir erklären, dass nur die Systeme, die beschrieben und beobachtet werden können, automatisiert und gesteuert werden können .

GitOps ist für den gesamten nativen Cloud-Stack (z. B. Terraform usw.).

GitOps ist nicht nur Kubernetes. Wir möchten, dass das gesamte System deklarativ verwaltet wird und Konvergenz verwendet wird. Mit einem Gesamtsystem ist eine Reihe von Umgebungen gemeint, die mit Kubernetes arbeiten, z. B. "Dev Cluster 1", "Production" usw. Jede Umgebung umfasst Maschinen, Cluster, Anwendungen sowie Schnittstellen für externe Dienste, die Daten, Überwachung und Daten bereitstellen usw.

Beachten Sie, wie wichtig Terraform in diesem Fall für das Bootstrapping-Problem ist. Kubernetes muss irgendwo bereitgestellt werden. Die Verwendung von Terraform bedeutet, dass wir dieselben GitOps-Workflows verwenden können, um die Kontrollschicht zu erstellen, die Kubernetes und Anwendungen zugrunde liegt. Dies ist eine gute Best Practice.

Besonderes Augenmerk wird auf die Anwendung von GitOps-Konzepten auf Ebenen über Kubernetes gelegt. Derzeit gibt es GitOps-ähnliche Lösungen für Istio, Helm, Ksonnet, OpenFaaS und Kubeflow sowie beispielsweise Pulumi, die eine Ebene für die Entwicklung von Anwendungen für Cloud Native erstellen.

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

Wie bereits erwähnt, sind GitOps zwei Dinge:

Das oben beschriebene Betriebsmodell für Kubernetes und Cloud Native.
Der Weg zum Organisieren einer entwicklerorientierten Anwendungsverwaltungsumgebung.

Für viele ist GitOps in erster Linie ein Git-Push-basierter Workflow. Wir mögen ihn auch. Dies ist jedoch noch nicht alles: Schauen wir uns nun die CI / CD-Pipelines an.

GitOps bietet Continuous Deployment (CD) für Kubernetes

GitOps bietet einen kontinuierlichen Bereitstellungsmechanismus, der die Notwendigkeit separater "Bereitstellungsverwaltungssysteme" überflüssig macht. Kubernetes erledigt die ganze Arbeit für Sie.

Das Aktualisieren der Anwendung erfordert ein Aktualisieren in Git. Dies ist ein Transaktions-Upgrade auf den gewünschten Status. Die „Bereitstellung“ wird dann innerhalb des Clusters von Kubernetes selbst basierend auf einer aktualisierten Beschreibung durchgeführt.
Aufgrund der Besonderheiten von Kubernetes sind diese Updates konvergent. Dies bietet einen Mechanismus für die kontinuierliche Bereitstellung, bei dem alle Aktualisierungen atomar sind.
Hinweis: Weave Cloud bietet einen GitOps-Operator, der Git und Kubernetes integriert und es Ihnen ermöglicht, eine CD auszuführen, indem Sie den gewünschten und aktuellen Status des Clusters abgleichen.

Ohne Kubectl und Skripte

Vermeiden Sie die Verwendung von Kubectl zum Aktualisieren des Clusters und insbesondere von Skripten zum Gruppieren von Kubectl-Befehlen. Stattdessen kann ein Benutzer mit einer GitOps-Pipeline seinen Kubernetes-Cluster über Git aktualisieren.

Zu den Vorteilen gehören:

Richtigkeit . Eine Gruppe von Updates kann angewendet, konvergiert und schließlich validiert werden, was uns dem Ziel der atomaren Bereitstellung näher bringt. Im Gegenteil, die Verwendung von Skripten gibt keine Garantie für die Konvergenz (mehr dazu weiter unten).
Sicherheit Zitat von Kelsey Hightower: „ Beschränken Sie den Zugriff auf den Kubernetes-Cluster auf Automatisierungstools und Administratoren, die für das Debuggen oder die Wartung verantwortlich sind.“ Siehe auch meine Veröffentlichung zu Sicherheit und Compliance sowie einen Artikel zum Hacken von Homebrew durch Diebstahl von Anmeldeinformationen aus einem nachlässig geschriebenen Jenkins-Skript.
Benutzererfahrung . Kubectl enthüllt die Mechanik des Kubernetes-Objektmodells, das recht komplex ist. Im Idealfall sollten Benutzer auf einer höheren Abstraktionsebene mit dem System interagieren. Hier werde ich noch einmal auf Kelsey verweisen und empfehlen, sich einen solchen Lebenslauf anzusehen .

Der Unterschied zwischen CI und CD

GitOps verbessert vorhandene CI / CD-Modelle.

Der moderne CI-Server ist ein Instrument für die Orchestrierung. Insbesondere ist es ein Instrument zur Orchestrierung von CI-Pipelines. Dazu gehören das Erstellen, Testen, Zusammenführen mit dem Trunk usw. CI-Server automatisieren die Verwaltung komplexer mehrstufiger Pipelines. Eine häufige Versuchung besteht darin, ein Skript für das Kubernetes-Update-Set zu erstellen und es als Pipeline-Element auszuführen, um Änderungen an den Cluster zu übertragen. In der Tat tun dies viele Experten. Dies ist jedoch nicht optimal, und hier ist der Grund dafür.

CI muss verwendet werden, um Aktualisierungen am Trunk vorzunehmen, und der Kubernetes-Cluster muss sich basierend auf diesen Aktualisierungen selbst ändern, um die CD „intern“ zu verwalten. Wir nennen dies das Pull-Modell für die CD , im Gegensatz zum CI-Push-Modell. Die CD ist Teil einer Laufzeit-Orchestrierung .

Warum CI-Server keine CDs durch direkte Updates in Kubernetes erstellen sollten

Verwenden Sie den CI-Server nicht, um direkte Updates in Kubernetes als eine Reihe von CI-Aufgaben zu orchestrieren. Dies ist das Anti-Muster, über das wir bereits in unserem Blog gesprochen haben.

Kommen wir zurück zu Alice und Bob.

Auf welche Probleme sind sie gestoßen? Der CI-Server von Bob wendet die Änderungen auf den Cluster an. Wenn dies jedoch der Fall ist, weiß Bob nicht, in welchem Status sich der Cluster befindet (oder befinden sollte) und wie er behoben werden kann. Das gleiche gilt, wenn erfolgreich.

Nehmen wir an, dass Bobs Team ein neues Image zusammengestellt und dann seine Bereitstellungen gepatcht hat, um das Image bereitzustellen (alle aus der CI-Pipeline).

Wenn das Image normal erstellt wird, die Pipeline jedoch ausfällt, muss das Team Folgendes herausfinden:

Wurde das Update bereitgestellt?
Beginnen wir mit einem Neubau? — ?
, ?
? ( )?

Git' , . - push' , - ; --.

, CI- CD:

; .
CI- .
. .
.

Helm'e: Helm, GitOps-, Flux-Helm . . Helm , .

GitOps Continuous Delivery Kubernetes

GitOps , , . , , . , , GitOps .

Kubernetes

. Git :

, Git .
Runtime GitOps, . Git .

?

: , , Git . , CI runtime-. « » (immutability firewall) , . 72-87 .
CI- Git- : GitOps . CI- Git-, . Continuous Delivery CI-/Git- . cloud native. GitOps .
: Git , Weave Flux ( Weave Cloud) runtime. , Kubernetes , Git . GitOps, .

Fazit

GitOps , CI/CD:

;
;
;
.

, cloud native.

, runbook' ( — . .) , deployment'.
cloud native- , .

, . GitOps - .

PS vom Übersetzer

Lesen Sie auch in unserem Blog:

Was ist GitOps?