Viele von uns stellen sich früher oder später die Frage, wenn sie einen neuen Begriff in der IT-Blogosphäre oder auf einer Konferenz hören: "Was ist das? Ein weiteres Modewort oder etwas, das wirklich Aufmerksamkeit und Untersuchung verdient und neue Perspektiven eröffnet?" Genau so erging es mir mit dem Begriff GitOps vor einiger Zeit. Ausgestattet mit zahlreichen bereits bestehenden Artikeln sowie dem Wissen meiner Kollegen aus der Firma , versuchte ich herauszufinden, was es mit diesem Begriff auf sich hat und wie seine Anwendung in der Praxis aussehen könnte.
Übrigens spricht auch die Neuheit des Begriffs für sich: Eine von uns kürzlich durchgeführte Umfrage hat ergeben, dass über die Hälfte der Befragten noch nicht mit seinen Prinzipien begonnen hat. GitOps laut einer kürzlich durchgeführten Umfrage von uns hat mehr als die Hälfte der Befragten noch nicht mit seinen Prinzipien begonnen.
Die Herausforderung im Infrastrukturmanagement ist nicht neu. Viele Cloud-Anbieter sind bereits seit über einem Jahrzehnt für die breite Öffentlichkeit zugänglich und sollten die Arbeit der Infrastruktur-Teams eigentlich einfacher und unkomplizierter gemacht haben. Trotzdem beinhalten Infrastrukturprojekte im Vergleich zu Anwendungsentwicklungsprozessen, in denen der Automatisierungsgrad kontinuierlich wächst, immer noch viele manuell durchzuführende Aufgaben und erfordern spezielle Kenntnisse und Fachleute. Dies gilt insbesondere vor dem Hintergrund der modernen Anforderungen an Ausfallsicherheit, Flexibilität, Skalierbarkeit und Elastizität.
Cloud-Dienste haben diese Anforderungen sehr erfolgreich erfüllt und genau sie haben einen bedeutenden Anstoß zur Entwicklung des Ansatzes gegeben. IaCDas ist nachvollziehbar. Denn sie ermöglichen die Konfiguration eines vollständig virtuellen Rechenzentrums: Es gibt keine physischen Server, Racks oder Netzwerkkomponenten; die gesamte Infrastruktur kann mit Skripten und Konfigurationsdateien beschrieben werden.
Was ist also der Unterschied? GitOps ab IaC? Именно с этого вопроса я и начал свое расследование. Пообщавшись с коллегами, у меня получилось выработать следующее сравнение:
GitOps
IaC
Der gesamte Code wird in einem Git-Repository gespeichert.
Die Versionierung des Codes ist nicht obligatorisch.
Deklarative Beschreibung des Codes / Idempotenz
Sowohl deklarative als auch imperative Beschreibungen sind zulässig
Änderungen werden durch Merge-Request-/Pull-Request-Mechanismen wirksam
Genehmigung, Bestätigung und Zusammenarbeit sind nicht obligatorisch
Der Rollout-Prozess von Updates ist automatisiert
Der Rollout-Prozess von Updates ist nicht standardisiert (automatisch, manuell, Dateiübertragung, Verwendung der Befehlszeile usw.)
Mit anderen Worten GitOps ist gerade durch die Anwendung von Prinzipien entstanden IaC. Zunächst konnte die Infrastruktur und die Konfigurationen nun genau wie Anwendungen gespeichert werden. Code ist einfach zu speichern, zu teilen, zu vergleichen und von den Möglichkeiten der Versionierung zu profitieren. Versionen, Branches, Historie. Und das alles an einem für das gesamte Team zugänglichen Ort. Daher war die Verwendung von Versionskontrollsystemen eine logische Weiterentwicklung, insbesondere git als das beliebteste.
Andererseits eröffnete sich die Möglichkeit, Infrastrukturmanagementprozesse zu automatisieren. Jetzt kann dies schneller, zuverlässiger und kostengünstiger geschehen. Zumal die Prinzipien von CI/CD bereits unter Softwareentwicklern bekannt und beliebt waren. Es galt lediglich, vorhandenes Wissen und Fähigkeiten auf ein neues Gebiet zu übertragen und anzuwenden. Diese Praktiken jedoch gingen über die Standarddefinition von Infrastructure as Code hinaus, und so entstand der Begriff. GitOps.
Neugier GitOps, natürlich liegt das auch daran, dass es sich nicht um ein Produkt, ein Plugin oder eine Plattform handelt, die mit einem bestimmten Anbieter verbunden ist. Es ist eher eine Paradigmenwechsel und eine Sammlung von Prinzipien, ähnlich unserem vertrauten Begriff: DevOps.
In unserem Unternehmen Wir haben zwei Definitionen dieses neuen Begriffs entwickelt: eine theoretische und eine praktische. Lassen Sie uns mit der theoretischen beginnen:
GitOps ist eine Methodologie, die moderne Prinzipien von DevOps anwendet, die für die Anwendungsentwicklung genutzt werden, wie Versionskontrolle, Interaktion, Abstimmung, CI/CD, und sie auf die Automatisierung des Infrastrukturmanagements anwendet.
Alle Prozesse GitOps Ich arbeite mit bereits vorhandenen Werkzeugen. Der gesamte Infrastrukturcode wird in einem bereits bekannten Git-Repository gespeichert, Änderungen durchlaufen denselben Genehmigungsprozess wie jeder andere Programmcode, und der Bereitstellungsprozess ist automatisiert, was menschliche Fehler auf ein Minimum reduziert und die Zuverlässigkeit sowie Reproduzierbarkeit erhöht.
Praktisch gesehen beschreiben wir GitOps $ ../..../waf ...
Infrastruktur als Code haben wir bereits als einen der Schlüsselaspekte dieser Formel besprochen. Lassen Sie uns die anderen Beteiligten vorstellen.
Merge Request (alternativer Name für Pull Request). Im Hinblick auf den Prozess ist ein MR eine Anfrage zur Anwendung von Codeänderungen und die anschließende Zusammenführung von Branches. Hinsichtlich der Werkzeuge, die wir verwenden, ist es eher die Möglichkeit, einen vollständigen Überblick über alle vorgenommenen Änderungen zu erhalten: nicht nur den Code-Diff, der aus einer bestimmten Anzahl von Commits erstellt wurde, sondern auch den Kontext, die Testergebnisse und das endgültig erwartete Resultat. Wenn wir über Infrastrukturcode sprechen, interessiert uns besonders, wie sich die Infrastruktur ändern wird, wie viele neue Ressourcen hinzugefügt oder entfernt werden und was verändert wird. Ideal wäre dies in einem übersichtlicheren und leicht lesbaren Format. Im Fall von Cloud-Anbietern wäre es hilfreich zu wissen, welche finanziellen Auswirkungen diese Änderung haben wird.
Doch ein MR ist auch ein Mittel zur Zusammenarbeit, Interaktion und Kommunikation. Der Ort, an dem das System von Checks and Balances in Kraft tritt. Von einfachen Kommentaren bis hin zu formellen Genehmigungen und Bestätigungen.
Und der letzte Bestandteil: CI/CD ermöglicht, wie wir bereits wissen, die Automatisierung des Prozesses zur Durchführung von Infrastrukturänderungen, Tests (von einfachen Syntaxprüfungen bis hin zu komplexeren statischen Codeanalysen). Dies schließt auch die anschließende Entdeckung von Drift ein: Unterschiede zwischen dem aktuellen und dem gewünschten Zustand des Systems. Zum Beispiel als Ergebnis unautorisierter manueller Änderungen oder Systemausfälle.
Ja, der Begriff GitOps führt uns nicht zu etwas völlig Neuem, er erfindet das Rad nicht neu, sondern wendet lediglich bereits gesammelte Erfahrungen in einem neuen Bereich an. Darin liegt seine Stärke.
Und falls Sie sich fragen, wie das alles in der Praxis aussieht, lade ich Sie ein, unser anzusehen, in dem ich Schritt für Schritt erkläre, wie man mit GitLab:
die grundlegenden Prinzipien von GitOps umsetzt,
Änderungen an der Cloud-Infrastruktur vornimmt (am Beispiel von Yandex Cloud),
die Drift des Systems vom gewünschten Zustand durch aktives Monitoring automatisiert.
https://bit.ly/34tRpwZ
Quelle: habr.com
