Close

Ist GitOps der nächste neue Trend in DevOps?

Viele Unternehmen betrachten DevOps heute als Teil ihrer Strategie für die digitale Transformation, da dadurch eine Unternehmenskultur gefördert wird, die auf gemeinsamer Verantwortung, Transparenz und schnellerem Feedback beruht. Doch mit der Verringerung der Kluft zwischen Entwicklungs- und Operations-Teams wird auch die Kluft zwischen den Prozessen kleiner.

Ähnlich verhält es sich mit Git, dem heute am weitesten verbreiteten Versionskontrollsystem der Welt. Unternehmen haben DevOps-Methoden und -Tools eingeführt, was eine Entwicklung zu GitOps nach sich zog – eine Reihe von Praktiken, die es Entwicklern ermöglichen, mehr Aufgaben im Zusammenhang mit dem IT-Betrieb auszuführen.


Was ist GitOps?


Im Grunde umfasst GitOps eine codebasierte Infrastruktur und Betriebsabläufe, die sich auf Git als Quellkontrollsystem stützen. Es handelt sich um eine Weiterentwicklung von Infrastructure as Code (IaC) und eine Best Practice für DevOps, die Git als zentrale Informationsquelle und als Steuerungsmechanismus für das Erstellen, Aktualisieren und Löschen von Systemarchitektur nutzt. Einfacher ausgedrückt: GitOps ist eine Methode, bei der mithilfe von Git-Pull-Anfragen Änderungen der Systeminfrastruktur überprüft und automatisch bereitgestellt werden.

GitOps bietet nicht nur mit Git einen wichtigen DevOps-Mechanismus, sondern wird auch zur Beschreibung von Tools verwendet, die die Standardfunktionen von Git erweitern. Diese Tools wurden hauptsächlich mit Betriebsmodellen für Kubernetes-basierte Infrastrukturen und Anwendungen verwendet. In der DevOps-Community wird laufend an der Weiterentwicklung von GitOps-Tools gearbeitet und erörtert, wie diese auf anderen Plattformen wie Terraform genutzt werden können.

GitOps stellt sicher, dass die Cloud-Infrastruktur eines Systems sofort basierend auf dem Status eines Git-Repository reproduzierbar ist. Pull-Anfragen ändern den Status des Git-Repository. Nach der Genehmigung und dem Merge konfigurieren die Pull-Anfragen die Live-Infrastruktur automatisch neu und synchronisieren diese mit dem Status des Repository. Dieser Pull-Anfrage-Workflow zur Live-Synchronisierung ist das Herzstück von GitOps.

Git-Logo
Zugehöriges Material

Git-Merkzettel

Bitbucket-Logo
Lösung anzeigen

Git kennenlernen mit Bitbucket Cloud

Die Geschichte von GitOps


Git ist ein erfolgskritisches Tool für Softwareentwicklung, die Workflows für Pull-Anfragen und Code-Reviews ermöglicht. Pull-Anfragen erleichtern den Einblick in eingehende Änderungen an einer Codebasis und fördern die Kommunikation, die Diskussion und den Review von Änderungen.

Pull-Anfragen sind ein zentrales Merkmal in der kollaborativen Softwareentwicklung. Sie haben die Art und Weise verändert, wie Teams und Unternehmen Software entwickeln. Pull-Anfragen bringen Transparenz und Messbarkeit in einen ehemals undurchsichtigen Prozess. Git-Pull-Anfragen haben die Weiterentwicklung von DevOps-Prozessen zur Softwareentwicklung ermöglicht. Systemadministratoren, die normalerweise zögerten, Änderungen vorzunehmen, setzen jetzt auf neue Softwareentwicklungspraktiken wie Agile und DevOps.

Die Geschichte der Systemadministration als Handwerk ist alles andere als glorreich. Früher verwalteten Systemadministratoren Hardware manuell, indem sie eine Verbindung zu Rechnern herstellten, die sie entweder in einem physischen Server-Rack oder über eine Cloud-Bereitstellungs-API bereitstellten. Neben dem manuellen Bereitstellungsprozess musste regelmäßig eine Unmenge an manuellen Konfigurationsaufgaben durchgeführt werden. Administratoren verfügten über benutzerdefinierte Sammlungen imperativer Skripte und Konfigurationen, stückelten diese zusammen und platzierten sie an verschiedenen Stellen. Diese Skripte konnten jederzeit beschädigt werden oder verloren gehen. Die Zusammenarbeit war schwierig, da die benutzerdefinierten Toolketten nicht regelmäßig dokumentiert oder geteilt wurden.

Aus diesem Morast der Systemadministration erhob sich die DevOps-Bewegung. DevOps wandte die besten Ideen aus der Softwareentwicklung auf die Systemadministration an, wo die zusammengestückelten Tools zu Code mit Versionskontrolle wurden.

IaC ist eine der größten Offenbarungen von DevOps. Zuvor nutzten Systemadministratoren für die Konfiguration von Systemen bevorzugt benutzerdefinierte imperative Skripte. Imperative Software folgt einer Abfolge von Schritten, um einen gewünschten Zustand zu erreichen, wie z. B.:

Imperative Software ist oft fehleranfällig und kann durch Änderungen an der Ereignisreihenfolge leicht beschädigt werden. In der modernen Softwareentwicklung wurden imperative Muster durch deklarative Muster abgelöst.

Deklarative Software folgt der Erklärung eines erwarteten Zustands anstelle einer Abfolge von Befehlen. Im Folgenden findest du einen Vergleich von imperativen und deklarativen DevOps-Aussagen.

Beispiele für imperative Aussagen sind:

  1. Installiere ein Betriebssystem auf diesem Computer.
  2. Installiere diese Abhängigkeiten.
  3. Lade Code von dieser URL herunter.
  4. Verschiebe den Code in dieses Verzeichnis.
  5. Wiederhole dies dreimal für drei andere Rechner.

Die deklarative Version davon würde einfach lauten: Auf 4 Computern ist Software von dieser URL in diesem Verzeichnis installiert.

IaC begünstigt und fördert die Nutzung deklarativer Systemverwaltungstools gegenüber benutzerdefinierten imperativen Lösungen. Dies führte zur Entstehung von Technologien wie Docker-Containern, Ansible, Terraform und Kubernetes, die statische deklarative Konfigurationsdateien verwenden. Zu den Vorteilen zählen Menschenlesbarkeit und ein konsistent reproduzierbarer Zustand. Natürlich wurden diese Konfigurationsdateien zur Nachverfolgung und zum Reviewen zu Git hinzugefügt. Das ist so ähnlich, aber noch nicht ganz so wie GitOps.

Zu diesem Zeitpunkt in der Geschichte von DevOps waren viele der herkömmlichen Probleme der Systemadministration gelöst. Konfigurationsdateien und Tools werden nun an einem zentralen Ort gespeichert und dokumentiert und sind für viele Teammitglieder zugänglich. Commits und Pull-Anfragen wurden genutzt, um Änderungen an der Konfiguration nachzuverfolgen und Diskussionen sowie gemeinsame Reviews zu fördern. Das einzige verbleibende Problem in dieser Phase ist, dass die Konfiguration immer noch vom Live-System abgekoppelt zu sein scheint. Nach der Genehmigung einer Konfigurations-Pull-Anfrage und ihrem Merge mit dem Repository wird das Live-System manuell aktualisiert, damit es dem Zustand des statischen Repositorys entspricht. Genau dieses Problem wird durch GitOps gelöst.

Die GitOps-Idee wurde zunächst von WeaveWorks, einem Anbieter von Managementlösungen für Enterprise-Kubernetes, entwickelt und geteilt. Seitdem hat sich dieses Prinzip in der gesamten DevOps-Community verbreitet. GitOps ist eine Weiterentwicklung von IaC und dem Prinzip der deklarativen Konfiguration wie oben besprochen. GitOps bringt ein wenig Magie in den Pull-Anfrage-Workflow, der den Zustand des Live-Systems mit dem des statischen Konfigurations-Repositorys synchronisiert.

Die Vorteile von GitOps


GitOps bietet viele der Vorteile eines Feature-Branch-Workflows in der agilen Softwareentwicklung. Der erste große Vorteil ist die einfache Einführung dank der Verwendung gängiger Tools. Git ist der De-facto-Standard von Versionskontrollsystemen und ein gängiges Softwareentwicklertool für die meisten Entwickler und Softwareteams. Daher können Entwickler, die mit Git vertraut sind, leicht als funktionsübergreifende Beitragende an GitOps mitwirken.

Mit einem Versionskontrollsystem kann ein Team alle Änderungen an der Konfiguration eines Systems verfolgen. Es erhält eine "zentrale Informationsquelle" und einen wertvollen Audit-Trail, sodass es reviewen kann, ob es zu Fehlern oder unerwartetem Verhalten kommt. Teams können den GitOps-Verlauf reviewen und sehen, wann eine Regression aufgetreten ist. Darüber hinaus kann dieser Audit-Trail als Referenz für Compliance- oder Sicherheitsüberprüfungen dienen. Der GitOps-Verlauf kann als Nachweis verwendet werden, wenn Dinge wie Verschlüsselungszertifikate geändert oder aktualisiert werden.

GitOps bringt Transparenz und Klarheit in die Infrastrukturanforderungen eines Unternehmens mithilfe eines zentralen Repositorys. Wenn alle Systemkonfigurationen in einem zentralen Repository enthalten sind, können die Beiträge der Teammitglieder skaliert werden. Pull-Anfragen, die über gehostete Git-Services wie Bitbucket gestellt werden, verfügen über umfangreiche Tools für Code-Reviews und Diskussionskommentare. Dadurch werden passive Kommunikationsschleifen erstellt, die es dem gesamten Entwicklerteam ermöglichen, Änderungen an der Infrastruktur zu beobachten und zu überwachen.

GitOps kann die Produktivität von DevOps-Teams erheblich steigern, da sie in der Lage sind, schnell mit neuen Infrastrukturkonfigurationen zu experimentieren. Wenn sich die neuen Änderungen nicht wie erwartet verhalten, können Teams die Änderungen anhand des Git-Verlaufs auf einen als funktionierend bekannten Zustand zurückzusetzen. Dies ist unglaublich hilfreich, da so in einer komplizierten Infrastruktur die Nutzung der vertrauten "Rückgängigmachen"-Funktion ermöglicht wird.

Wie GitOps funktioniert


GitOps-Verfahren werden von einem zugrunde liegenden Orchestrierungssystem durchgeführt. Bei GitOps selbst handelt es sich um ein agnostisches Muster für Best Practices. Viele beliebte GitOps-Lösungen verwenden heute hauptsächlich Kubernetes als Orchestrierungssystem. Es kommen aber auch einige andere GitOps-Toolsets auf den Markt, die die direkte Bearbeitung mit Terraform unterstützen.

Für eine vollständige GitOps-Installation ist eine Pipeline-Plattform erforderlich. Jenkins, Bitbucket Pipelines oder CircleCI sind einige beliebte Pipeline-Tools, die GitOps ergänzen. Pipelines schließen durch Automatisierung die Lücke zwischen Git-Pull-Anfragen und dem Orchestrierungssystem. Sobald Pipeline-Hooks eingerichtet und von Pull-Anfragen ausgelöst wurden, werden Befehle an das Orchestrierungssystem gesendet.

Ein neues Muster oder eine neue Komponente, die speziell mit GitOps eingeführt wurde, ist der GitOps-"Operator" – ein Mechanismus, der sich zwischen der Pipeline und dem Orchestrierungssystem befindet. Eine Pull-Anfrage startet die Pipeline, die dann den Operator auslöst. Der Operator untersucht den Zustand des Repositorys und den Beginn der Orchestrierung und synchronisiert diese. Der Operator ist die magische Komponente von GitOps.

Beispiele für GitOps


Stelle dir einmal vor, ein Team hat einen Leistungsengpass oder einen Anstieg des Datenverkehrs festgestellt und merkt, dass der Load Balancer nicht wie erwartet funktioniert. Die Teammitglieder schauen sich das GitOps-Repository an, das die Infrastrukturkonfiguration enthält, und suchen eine bestimmte Datei für die Konfiguration und Bereitstellung des Load Balancers. Sie können diese auf ihrer Online-Git-Hosting-Site reviewen. Nach einigem Reviewen und Diskutieren stellen sie fest, dass einige der Konfigurationswerte für den Load Balancer nicht optimal sind und angepasst werden müssen.

Ein Mitglied des Teams öffnet eine neue Pull-Anfrage zur Optimierung der Werte des Load Balancers. Die Pull-Anfrage wird von einem zweiten Teammitglied geprüft und genehmigt und in das Repository gemergt. Der Merge startet eine GitOps-Pipeline, die den GitOps-Operator auslöst. Der Operator erkennt, dass die Konfiguration des Load Balancers geändert wurde. Er bestätigt mit dem Systemorchestrierungstool, dass dies nicht mit dem Live-Zustand im Team-Cluster übereinstimmt.

Der Operator signalisiert dem Orchestrierungssystem, die Konfiguration des Load Balancers zu aktualisieren. Der Orchestrator erledigt den Rest und stellt automatisch den neu konfigurierten Load Balancer bereit. Das Team überwacht dann das gerade aktualisierte Live-System, um sicherzustellen, dass es zu einem fehlerfreien Zustand zurückkehrt. Dies ist ein ideales GitOps-Szenario. Zur Veranschaulichung des Nutzens von GitOps wollen wir dies noch etwas ausführen.

Angenommen, dass das Team nicht nur die Werte des Load Balancers etwas optimieren möchte, sondern die radikale Entscheidung trifft, einen völlig neuen Load Balancer-Typ bereitzustellen. Die Teammitglieder sind der Meinung, dass der aktuelle Load Balancer grundlegende Mängel aufweist, und möchten daher eine andere Option ausprobieren. Der Workflow ist der gleiche wie bei der Anpassung der Werte. Das Team erstellt eine Pull-Anfrage, die eine völlig neue Konfiguration für den Load Balancer einführt und die alte Konfiguration löscht. Sie wird genehmigt und über die Pipeline bereitgestellt.

Leider stellt das Team fest, dass dieser neue Load Balancer-Typ nicht mit einigen anderen Services in seinem Cluster kompatibel ist. Der neue Load Balancer verursacht kritische Datenverkehrsausfälle und stoppt Benutzervorgänge. Glücklicherweise kann das Team diese Änderungen am Load Balancer schnell rückgängig machen, da es über eine vollständige GitOps-Pipeline verfügt. Das Team stellt eine weitere Pull-Anfrage, die das Repository wieder auf den alten als funktionierend bekannten Load Balancer zurücksetzt. Dies wird wiederum von der GitOps-Pipeline erkannt und automatisch bereitgestellt. So kann die Infrastruktur schnell optimiert werden und das Team erzielt eine bessere Zuverlässigkeitsbewertung.

Zusammenfassung


GitOps ist ein unglaublich hilfreiches Workflow-Muster für die Verwaltung moderner Cloud-Infrastruktur. Obwohl sich die DevOps-Community hauptsächlich auf das Management von Kubernetes-Clustern konzentriert, finden auch GitOps-Lösungen Anwendung, die auf anderen Systemen veröffentlicht werden. GitOps kann einem Entwicklerteam viele Vorteile bieten, wie z. B. eine bessere Kommunikation, Sichtbarkeit, Stabilität und Systemzuverlässigkeit. Eine der Kernanforderungen für eine optimale GitOps-Erfahrung ist eine moderne gehostete Git-Plattform wie Bitbucket.


Diesen Artikel teilen
Nächstes Thema

Lesenswert

Füge diese Ressourcen deinen Lesezeichen hinzu, um mehr über DevOps-Teams und fortlaufende Updates zu DevOps bei Atlassian zu erfahren.

Mitarbeiter arbeiten mit unzähligen Tools zusammen

Bitbucket-Blog

Abbildung: DevOps

DevOps-Lernpfad

Demo Den: Feature-Demos mit Atlassian-Experten

So funktioniert Bitbucket Cloud mit Atlassian Open DevOps

Melde dich für unseren DevOps-Newsletter an

Thank you for signing up