GitOps: ein weiteres Schlagwort oder ein Durchbruch in der Automatisierung?

Die meisten von uns, die einen weiteren neuen Begriff in der IT-Blogosphäre oder -Konferenz bemerken, stellen früher oder später eine ähnliche Frage: „Was ist das?“ Nur ein weiteres Schlagwort, ein „Schlagwort“ oder etwas, das es wirklich wert ist, genau beachtet und studiert zu werden und das neue Horizonte verspricht?“ Das Gleiche ist mir mit dem Begriff passiert GitOps vor einiger Zeit. Ausgestattet mit vielen vorhandenen Artikeln sowie dem Wissen von Kollegen aus dem Unternehmen GitlabIch habe versucht herauszufinden, was für ein Biest das ist und wie seine Verwendung in der Praxis aussehen könnte.

Übrigens zur Neuheit des Begriffs GitOps Auch unsere aktuelle Umfrage sagt: Mehr als die Hälfte der Befragten hat noch nicht begonnen, mit seinen Prinzipien zu arbeiten.

Das Problem des Infrastrukturmanagements ist also nicht neu. Viele Cloud-Anbieter sind seit gut einem Dutzend Jahren für die breite Öffentlichkeit zugänglich und hätten den für die Infrastruktur verantwortlichen Teams scheinbar die Arbeit einfach und unkompliziert machen sollen. Allerdings umfassen Infrastrukturprojekte im Vergleich zum Anwendungsentwicklungsprozess (wo die Automatisierung immer neue Stufen erreicht) immer noch viele manuelle Aufgaben und erfordern spezielles Wissen und Fachwissen, insbesondere angesichts der heutigen Anforderungen an Fehlertoleranz, Flexibilität, Skalierbarkeit und Elastizität.

Cloud-Dienste erfüllten diese Anforderungen sehr erfolgreich und gaben der Entwicklung des Ansatzes entscheidende Impulse IaC. Das ist verständlich. Schließlich ermöglichten sie die Konfiguration eines vollständig virtuellen Rechenzentrums: Es gibt keine physischen Server, Racks oder Netzwerkkomponenten; die gesamte Infrastruktur kann mithilfe von Skripten und Konfigurationsdateien beschrieben werden.

Was genau ist also der Unterschied? GitOps aus IaC? Mit dieser Frage begann ich meine Untersuchung. Nach Gesprächen mit Kollegen konnte ich zu folgendem Vergleich kommen:

GitOps

IaC

Der gesamte Code wird in einem Git-Repository gespeichert

Die Codeversionierung ist optional

Deklarative Codebeschreibung / Idempotenz

Sowohl deklarative als auch imperative Beschreibungen sind zulässig

Änderungen werden über die Merge-Request-/Pull-Request-Mechanismen wirksam

Vereinbarung, Genehmigung und Zusammenarbeit sind optional

Der Update-Rollout-Prozess ist automatisiert

Der Update-Rollout-Prozess ist nicht standardisiert (automatisch, manuell, Kopieren von Dateien, Verwendung der Befehlszeile usw.)

Mit anderen Worten GitOps wurde genau durch die Anwendung der Prinzipien geboren IaC. Erstens könnten Infrastruktur und Konfigurationen nun genauso gespeichert werden wie Anwendungen. Der Code ist einfach zu speichern, einfach zu teilen, zu vergleichen und Versionierungsfunktionen zu verwenden. Versionen, Zweige, Geschichte. Und das alles an einem für das gesamte Team öffentlich zugänglichen Ort. Daher war der Einsatz von Versionskontrollsystemen eine völlig natürliche Entwicklung. Besonders beliebt ist Git.

Andererseits wurde es möglich, Infrastrukturmanagementprozesse zu automatisieren. Jetzt geht das schneller, zuverlässiger und kostengünstiger. Darüber hinaus waren die Prinzipien von CI/CD bei Softwareentwicklern bereits bekannt und beliebt. Es galt lediglich, bereits bekannte Kenntnisse und Fähigkeiten auf ein neues Gebiet zu übertragen und anzuwenden. Diese Praktiken gingen jedoch über die Standarddefinition von Infrastruktur als Code hinaus, daher das Konzept GitOps.

Neugier GitOps, natürlich auch darin, dass es sich nicht um ein Produkt, Plugin oder eine Plattform handelt, die einem Anbieter zugeordnet ist. Es handelt sich eher um ein Paradigma und eine Reihe von Prinzipien, ähnlich einem anderen Begriff, den wir kennen: DevOps.

Das Unternehmen Gitlab Wir haben zwei Definitionen dieses neuen Begriffs entwickelt: theoretisch und praktisch. Beginnen wir mit der Theorie:

GitOps ist eine Methodik, die die besten DevOps-Prinzipien für die Anwendungsentwicklung, wie Versionskontrolle, Zusammenarbeit, Orchestrierung, CI/CD, auf die Herausforderungen der Automatisierung des Infrastrukturmanagements anwendet.

Alle Prozesse GitOps Ich arbeite mit vorhandenen Tools. Der gesamte Infrastrukturcode wird im bereits bekannten Git-Repository gespeichert, Änderungen durchlaufen denselben Genehmigungsprozess wie jeder andere Programmcode und der Rollout-Prozess ist automatisiert, wodurch wir menschliche Fehler minimieren und die Zuverlässigkeit und Reproduzierbarkeit erhöhen können.

Aus praktischer Sicht beschreiben wir GitOps следующим обрахом:

Wir haben Infrastruktur als Code bereits als eine der Schlüsselkomponenten dieser Formel besprochen. Stellen wir den Rest der Teilnehmer vor.

Merge Request (alternativer Name Pull Request). Prozesstechnisch handelt es sich bei MR um eine Aufforderung, Codeänderungen anzuwenden und anschließend Zweige zusammenzuführen. Aber im Hinblick auf die von uns verwendeten Tools ist dies eher eine Gelegenheit, sich ein vollständiges Bild aller vorgenommenen Änderungen zu machen: nicht nur die Code-Differenzen, die aus einer bestimmten Anzahl von Commits gesammelt wurden, sondern auch der Kontext, die Testergebnisse usw endgültiges erwartetes Ergebnis. Wenn wir über Infrastrukturcode sprechen, dann interessiert uns, wie genau sich die Infrastruktur ändert, wie viele neue Ressourcen hinzugefügt oder entfernt und verändert werden. Am besten in einem bequemeren und leichter lesbaren Format. Für Cloud-Anbieter ist es gut zu wissen, welche finanziellen Auswirkungen diese Änderung haben wird.

Aber MR ist auch ein Mittel der Zusammenarbeit, Interaktion und Kommunikation. Der Ort, an dem das System der Checks and Balances ins Spiel kommt. Von einfachen Kommentaren bis hin zu formellen Genehmigungen und Genehmigungen.

Nun, die letzte Komponente: CI/CD ermöglicht, wie wir bereits wissen, die Automatisierung des Prozesses der Durchführung von Infrastrukturänderungen und Tests (von der einfachen Syntaxprüfung bis hin zur komplexeren statischen Codeanalyse). Und auch bei der anschließenden Erkennung von Drift: Unterschieden zwischen realem und gewünschtem Zustand des Systems. Beispielsweise aufgrund unbefugter manueller Änderungen oder eines Systemausfalls.

Ja, der Begriff GitOps stellt uns nichts völlig Neues vor, erfindet das Rad nicht neu, sondern wendet lediglich die bereits gesammelten Erfahrungen in einem neuen Bereich an. Aber hier liegt seine Stärke.

Und wenn es Sie plötzlich interessiert, wie das alles in der Praxis aussieht, dann lade ich Sie ein, sich unsere anzusehen Master Class, in dem ich Ihnen Schritt für Schritt erkläre, wie Sie GitLab verwenden:

• Implementieren Sie die Grundprinzipien von GitOps

• Erstellen und Änderungen an der Cloud-Infrastruktur vornehmen (am Beispiel von Yandex Cloud)

• Automatisieren Sie die Erkennung von Systemabweichungen von einem gewünschten Zustand durch aktive Überwachung

https://bit.ly/34tRpwZ

Source: habr.com