GitOps Kochbuch

Kapitel 1. Einführung

Diese Arbeit wurde mithilfe von KI übersetzt. Wir freuen uns über dein Feedback und deine Kommentare: [e-mail]

Mit dem Aufkommen von Praktiken wie Infrastructure as Code (IaC) hat die Softwareentwicklung die Grenzen der Plattformen, auf denen du Anwendungen ausführen kannst, verschoben. Dies geschieht immer häufiger mit programmierbaren, API-gesteuerten Plattformen wie Public Clouds und Open-Source-Infrastrukturlösungen. Während sich Entwickler/innen vor einigen Jahren nur auf den Quellcode der Anwendung konzentrierten, haben sie heute auch die Möglichkeit, die Infrastruktur zu programmieren, auf der ihre Anwendung laufen wird. Das gibt ihnen die Kontrolle und ermöglicht eine Automatisierung, die die Vorlaufzeit erheblich verkürzt.

Ein gutes Beispiel ist Kubernetes, eine beliebte Open-Source-Plattform zur Orchestrierung von Container-Workloads und der De-facto-Standard für den Betrieb von Produktionsanwendungen in öffentlichen oder privaten Clouds. Die Offenheit und Erweiterbarkeit der Plattform ermöglicht eine Automatisierung, die die Risiken bei der Bereitstellung reduziert und die Servicequalität erhöht. Darüber hinaus wird dieses leistungsstarke Paradigma durch einen anderen, zunehmend beliebten Ansatz namens GitOps erweitert.

1.1 Was ist GitOps?

GitOps ist eine Methodik und Praxis, die Git-Repositories als eine einzige Quelle der Wahrheit nutzt, um Infrastruktur als Code zu liefern. GitOps greift die Säulen und Ansätze der DevOps-Kultur auf und bietet einen Rahmen, um mit der Umsetzung der Ergebnisse zu beginnen. Die Beziehung zwischen DevOps und GitOps ist eng, denn GitOps hat sich als beliebtes Mittel zur Umsetzung und Verbesserung von DevOps, Platform Engineering und SRE etabliert.

GitOps ist ein agnostischer Ansatz, und ein GitOps-Framework kann mit Tools wie Git, Kubernetes und CI/CD-Lösungen aufgebaut werden. Die drei Hauptsäulen von GitOps sind:

• Git ist die einzige Quelle der Wahrheit

• Alles als Code behandeln

• Operationen werden über Git-Workflows durchgeführt

Es gibt eine aktive Community rund um GitOps, und die GitOps Working Group definiert eine Reihe von GitOps-Prinzipien (derzeit in Version 1.0.0), die unter OpenGitOps verfügbar sind:

Deklarativ

Für ein von GitOps verwaltetes System muss der gewünschte Zustand deklarativ ausgedrückt werden.

Versioniert und unveränderlich

Der gewünschte Zustand wird so gespeichert, dass Unveränderlichkeit und Versionierung gewährleistet sind und eine vollständige Versionshistorie aufbewahrt wird.

Automatisch abgezogen

Software-Agenten ziehen automatisch die gewünschten Zustandserklärungen aus der Quelle.

Kontinuierlich versöhnt

Software-Agenten beobachten kontinuierlich den aktuellen Systemzustand und versuchen, den gewünschten Zustand herzustellen.

1.2 Warum GitOps?

GitOps nutzt die gängigen Git-basierten Workflows, mit denen Entwickler vertraut sind, und erweitert die bestehenden Prozesse von der Anwendungsentwicklung bis hin zur Bereitstellung, dem App-Lifecycle-Management und der Infrastrukturkonfiguration.

Jede Änderung während des gesamten Lebenszyklus der Anwendung wird im Git-Repository nachverfolgt und ist nachvollziehbar. Dieser Ansatz ist sowohl für die Entwickler als auch für die Betriebsteams von Vorteil, da er die Fähigkeit verbessert, Probleme schnell zu verfolgen und zu reproduzieren, was die allgemeine Sicherheit erhöht. Ein wichtiger Punkt ist, das Risiko unerwünschter Änderungen (Drift) zu verringern und sie zu korrigieren, bevor sie in die Produktion gehen.

Hier ist eine Zusammenfassung der Vorteile der Einführung von GitOps in vier Schlüsselaspekten:

Standard Arbeitsablauf

Vertraute Tools und Git-Workflows aus der Anwendungsentwicklung nutzen

Verbesserte Sicherheit

Überprüfe Änderungen im Voraus, erkenne Konfigurationsabweichungen und ergreife Maßnahmen

Sichtbarkeit und Prüfung

Erfasse und verfolge jede Änderung an Clustern durch den Git-Verlauf

Multicluster-Konsistenz

Zuverlässige und konsistente Konfiguration mehrerer Umgebungen und mehrerer Kubernetes-Cluster sowie Bereitstellung

1.3 Kubernetes CI/CD

Continuous Integration (CI) und Continuous Delivery (CD) sind Methoden, mit denen Apps häufig ausgeliefert werden, indem die Phasen der App-Entwicklung automatisiert werden. CI/CD-Pipelines sind einer der häufigsten Anwendungsfälle für GitOps.

In einer typischen CI/CD-Pipeline durchläuft der eingereichte Code den CI-Prozess, während der CD-Prozess Anforderungen wie Sicherheit, Infrastruktur als Code oder andere für das Anwendungsframework festgelegte Grenzen überprüft und anwendet. Alle Code-Änderungen werden nachverfolgt, was Aktualisierungen erleichtert und gleichzeitig eine Versionskontrolle ermöglicht, falls ein Rollback erforderlich ist. CD ist die Domäne von GitOps und arbeitet mit dem CI-Teil zusammen, um Anwendungen in verschiedenen Umgebungen bereitzustellen, wie du in Abbildung 1-1 sehen kannst.

Abbildung 1-1. Kontinuierliche Integration und kontinuierliche Lieferung

Mit Kubernetes ist es einfach, eine clusterinterne CI/CD-Pipeline zu implementieren. Du kannst das Container-Image, das deine Anwendung repräsentiert, von einer KI-Software erstellen lassen und es in einer Container-Image-Registry speichern. Danach kann ein Git-Workflow, z. B. ein Pull-Request, die Kubernetes-Manifeste ändern, die den Einsatz deiner Anwendungen darstellen, und eine CD-Synchronisationsschleife starten, wie in Abbildung 1-2 dargestellt.

Abbildung 1-2. Modell der Anwendungsbereitstellung

Dieses Kochbuch zeigt praktische Rezepte für die Umsetzung dieses Modells auf Kubernetes als CI/CD- und GitOps-Plattform.

1.4 App-Bereitstellung mit GitOps auf Kubernetes

Da GitOps ein agnostischer, plattformunabhängiger Ansatz ist, kann das Anwendungsbereitstellungsmodell auf Kubernetes entweder im Cluster oder im Multicluster sein. Ein externes GitOps-Tool kann Kubernetes nur als Zielplattform für die Bereitstellung von Anwendungen nutzen. Bei In-Cluster-Ansätzen wird eine GitOps-Engine innerhalb von Kubernetes ausgeführt, um Apps zu verteilen und Manifeste in einem oder mehreren Kubernetes-Clustern zu synchronisieren.

Die GitOps-Engine kümmert sich um den CD-Teil der CI/CD-Pipeline und führt eine GitOps Schleife durch, die aus vier Hauptaktionen besteht, wie in Abbildung 1-3 dargestellt:

Bereitstellen

Setze die Manifeste aus Git ein.

Monitor

Überwache entweder das Git Repo oder den Zustand des Clusters.

Drift erkennen

Erkenne jede Abweichung von dem, was in Git beschrieben ist und was im Cluster vorhanden ist.

Maßnahmen ergreifen

Führe eine Aktion durch, die das widerspiegelt, was in Git steht (Rollback oder Drei-Wege-Diff). Git ist die Quelle der Wahrheit, und jede Änderung wird über einen Git-Workflow durchgeführt.

Abbildung 1-3. GitOps-Schleife

In Kubernetes werden bei der Anwendungsbereitstellung mit dem GitOps-Ansatz mindestens zwei Git-Repositories verwendet: eines für den Quellcode der App und eines für die Kubernetes-Manifeste, die die Bereitstellung der App beschreiben (Deployment, Service usw.).

Abbildung 1-4 veranschaulicht die Struktur eines GitOps Projekts auf Kubernetes.

Abbildung 1-4. Kubernetes GitOps-Schleife

Die folgende Liste gibt einen Überblick über die Elemente des Workflows:

1. App-Quellcode-Repository

2. CI-Pipeline zur Erstellung eines Container-Images

3. Container-Image-Register

4. Kubernetes Manifeste Repository

5. Die GitOps-Engine synchronisiert Manifeste mit einem oder mehreren Clustern und erkennt Drifts

1.5 DevOps und Agilität

GitOps ist ein entwicklerzentrierter Ansatz für die kontinuierliche Bereitstellung und den Betrieb der Infrastruktur sowie ein Entwicklungsworkflow durch Git zur Automatisierung von Prozessen. So wie DevOps eine Ergänzung zur agilen Softwareentwicklung ist, ist GitOps eine Ergänzung zu DevOps für die Automatisierung der Infrastruktur und das Application Lifecycle Management. Wie du in Abbildung 1-5 sehen kannst, ist es ein Entwicklungsworkflow für die Automatisierung von Abläufen.

Einer der wichtigsten Aspekte der agilen Methodik ist die Reduzierung der Vorlaufzeit, die abstrakter als die Zeit zwischen der Identifizierung einer Anforderung und ihrer Erfüllung beschrieben wird.

Abbildung 1-5. GitOps Entwicklungszyklus

Diese Zeit zu verkürzen ist von grundlegender Bedeutung und erfordert einen Kulturwandel in IT-Organisationen. Wenn die Anwendungen in Betrieb sind, erhalten die Entwickler eine Feedbackschleife, um ihren Code zu überarbeiten und zu verbessern und ihre Projekte zum Erfolg zu führen. Ähnlich wie DevOps erfordert auch GitOps eine kulturelle Anpassung der Geschäftsprozesse. Jeder Vorgang, wie z. B. die Bereitstellung von Anwendungen oder die Änderung der Infrastruktur, ist nur durch Git-Workflows möglich. Und das bedeutet manchmal einen Kulturwandel.

Die Rede "Teaching Elephants to Dance (and Fly!) " von Burr Sutter gibt eine klare Vorstellung von dem Kontext. Der Elefant ist, wo deine Organisation heute steht. Es gibt Phasen des Wandels zwischen traditionellen und modernen Umgebungen, die von GitOps-Tools unterstützt werden. Einige Unternehmen haben den Luxus, bei Null anzufangen, aber für viele Unternehmen besteht die Herausforderung darin, ihrem schwerfälligen Elefanten beizubringen, wie eine anmutige Ballerina zu tanzen.