© Mallari/Shutterstock.com
Continuous Deployment mit GitOps

Vertraute Werkzeuge nutzen


GitOps ermöglicht einen entwicklungszentrierten Betrieb von Anwendungen und deren benötigter Infrastruktur durch die Verwendung von Tools, mit denen Entwicklungsteams bereits vertraut sind, einschließlich Git und Continuous-Deployment-Tools.

Im Zentrum von GitOps steht ein spezielles Code-Repository, ein sogenanntes Umgebungs-Repository, das ein Dependency-Manifest für alle Anwendungen und der aktuell in der Zielumgebung gewünschten Infrastruktur enthält. Ein automatisierter Prozess, Operator genannt, überwacht die tatsächliche Zielumgebung und passt sie an den beschriebenen Zustand im Repository an. Soll eine neue Anwendung deployt oder eine bestehende Anwendung aktualisiert werden, muss nur das Umgebungs-Repository aktualisiert werden – alles andere erledigt der Operator.

Komponenten

Umgebungs-Repository: Einer der Kerngedanken von GitOps ist es, Entwicklungsteams die Möglichkeit zu geben, die ihnen vertrauten Werkzeuge für den Betrieb der Infrastruktur zu nutzen. Eine deklarative Beschreibung der Anwendungen und Infrastruktur (z. B. Message Broker, Service Mesh, Monitoringtool) wird daher zentral als Single Source of Truth in einem Code-Repository gesammelt. Etabliert hat sich die Verwendung von Git, daher auch der Name GitOps. Im Prinzip kann aber jedes Versionskontrollsystem verwendet werden.

Zielumgebung: In Frage kommt jede Betriebsplattform, die sich deklarativ beobachten und als Environment as Code [2] beschreiben lässt. Allerdings erleichtert die Verwendung von Kubernetes als Zielumgebung die Auswahl eines GitOps-Operators. Selbstgebaute Operatoren können hier natürlich Abhilfe schaffen. Üblicherweise bilden unterschiedliche Kubernetes-Cluster die verschiedenen Umgebungen (Dev, Staging, Prod etc.) ab.

Deployment-Operator: Die Wahl eines GitOps-Operators hängt maßgeblich von der Zielumgebung ab. Populäre Operatoren für Kubernetes sind Flux und Argo CD. Es gibt aber auch CI/CD-Systeme, die die Philosophie von GitOps auch auf Continuous Integration übertragen und somit nicht nur den Deployment-Prozess in die Zielumgebung heben, sondern auch das Testen von Anwendungen. Zu diesen GitOps-CI/CD-Systemen gehören Tekton und Jenkins X.

Continuous Integration Pipeline: GitOps-Operatoren übernehmen das Deployment, aber nicht immer das Testen und Bauen von Anwendungen. Da der Operator die gesamte Arbeit des Deployments von Anwendungen übernimmt, wird die CI/CD Pipeline zu einer reinen CI Pipeline.

GitOps-Workflow

Code-Repositories sind zentrale Elemente bei einem GitOps-Deployment-Prozess. Es gibt zwei Arten von Repositories: Anwendungs-Repository und Umgebungs-Repository. Anwendungs-Repositories enthalten den Code der Anwendung und ggf. die Manifeste für das Deployment der Anwendung. Das Umgebungs-Repository enthält ein Manifest, das die aktuell gewünschte Infrastruktur der Zielumgebung durch Dependencies beschreibt. Solch ein Dependency-Manifest wird bei der Verwendung von Helm „Umbrella Chart“ genannt. Eine andere Option wäre es, die Deployment-Manifeste der Anwendungen direkt im Umgebungs-Repository zu verwalten, sodass es auch keine Deployment-Manifeste in den Anwendungs-Repositories selbst gibt.

Es gibt zwei Strategien, um Deployments umzusetzen: Push-basierte und Pull-basierte Deployments. Der Unterschied zwischen den beiden Deployment-Strategien besteht d...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Gewinner-Teams

Wir bieten Lizenz-Lösungen für Teams jeder Größe: Finden Sie heraus, welche Lösung am besten zu Ihnen passt.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang