Ist GitOps der nächste neue Trend in DevOps?

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.

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.

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.

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.

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.