GitOps (eBook)

1Was ist GitOps?

Hand aufs Herz: Wo schaust du zuerst nach, wenn du wissen möchtest, welche Anwendungen konkret in einem Environment deployt sind? Vielleicht findest du dich in einer der folgenden Antworten wieder:

• »Im Cluster selbst – wir deployen nur manuell … «
• »In den letzten Deploy-Pipelines vom CI-Server.«
• »In einem Git-Repo.«

GitOps kann dich in die Lage versetzen, die letzte der drei Antworten zu geben – und zwar mit sehr großer Zuversicht. Diese psychologische Sicherheit ist nur eines der Resultate von einem Deployment-Workflow auf GitOps-Basis.

In diesem Kapitel stellen wir GitOps ganz grundlegend vor. Dabei starten wir mit einer vagen Gegenüberstellung, um eine grundsätzliche Vorstellung von GitOps zu haben. Dann wollen wir die Hintergründe und Herausforderungen verstehen, aus denen GitOps entstand. Anschließend wenden wir uns den vier Prinzipien von OpenGitOps zu, die GitOps im Kern definieren.

1.1CIOps vs. GitOps

CIOps: Der CI-Server deployt in den Cluster.

Bei einer »klassisch« umgesetzten Pipeline für Continuous Deployment (CD) führt der CI-Server aktiv das Deployment in die Zielumgebung durch (Push-Prinzip). In Abb. 1–1 sehen wir ein Beispiel davon: Der CI-Server, in diesem Fall GitLab CI, verbindet sich mit einem Source Code Management (SCM), zum Beispiel GitHub. GitLab CI lädt ein Git-Repository herunter, das beispielsweise Kubernetes-Manifeste enthält. Anschließend verbindet es sich mit einem Kubernetes-Cluster (beispielsweise über eine Kubeconfig-Datei) und rollt diese Manifeste aus (beispielsweise mit einem kubectl apply). Dieses Verfahren bezeichnen wir als »CIOps1«, weil ausschließlich der CI-Server operativ tätig ist.

Punktuelle Rollouts ermöglichen massiven Drift.

CIOps hat sich jahrelang in der Praxis bewährt – aber es weist an kritischen Stellen entscheidende Mängel auf: Der Rollout wird nur punktuell ausgeführt. Dadurch entsteht ab der ersten Sekunde nach dem CI-geführten Rollout etwas, das alle Infrastruktur-Menschen fürchten: Drift – die Realität entfernt sich mit jedem Moment mehr vom ursprünglich definierten Wunschzustand. Danach manuell ausgeführte Änderungen bleiben intransparent bestehen. Solche Änderungen können aus Versehen passieren oder absichtlich, etwa durch Angreifende. Und genau dadurch entsteht das Problem, das wir am Anfang des Kapitels angerissen haben: Wer eine Woche lang keinen Commit auf das Repo macht, von dem aus die Pipeline getriggert wird, kann eine Woche lang manuelle Änderungen im Cluster machen, und es wird keinerlei automatisches Zurücksetzen auf den in Git definierten Zustand (Reconciliation) geschehen.

Abb. 1–1
Die »klassische« CIOps Pipeline

Der CI-Server braucht hochprivilegierten Zugriff auf den Cluster.

Außerdem haben wir gravierende Sicherheitsrisiken: Der CI-Server braucht privilegierten Zugriff auf die Zielumgebung. Meistens bekommt der CI-Server direkt administrativen Zugriff und kann dadurch in den falschen Händen viel Schaden anrichten. Das öffnet sehr gefährliche Einfallstore für Angreifer.

Der CI-Server braucht Sichtkontakt zum Cluster.

Ebenso ist ein Rollout nur dann möglich, wenn eine Netzwerkverbindung vom CI-Server zum Zielsystem besteht. Selbst wenn wir die Rollout-Pipeline im CI-Server automatisch alle 5 Minuten ausführen lassen, wird die Angleichung nur dann passieren, wenn der CI-Server den Cluster erreichen kann.

Außerdem ist in Enterprise-Umgebungen diese Verbindung zwischen Entwicklungsumgebung (CI-Server) und Betriebsumgebung (Kubernetes) aufgrund unterschiedlicher Sicherheitszonen oft eine Herausforderung. Dies kann die Verbindung unmöglich machen oder durch die Notwendigkeit von Firewall-Freischaltungen deutlich erschweren. Zwar unterliegen die umgekehrten Netzwerkverbindungen von der Betriebsumgebung auf die Entwicklungsumgebung (SCM) gegebenenfalls ähnlichen Problematiken. Unserer Erfahrung nach ist es aber meist einfacher, aus der produktiven Betriebsumgebung heraus, als in sie hineinzukommen. Mit GitOps ließe sich selbst dieses Problem lösen: Der GitOps-Operator könnte die Manifeste auch aus einer Open Container Initiative (OCI) Registry lesen, auf die Kubernetes aufgrund der Images ohnehin Zugriff braucht (siehe Abschnitt 4.13 auf Seite 90).

Kein Git-basiertes Löschen

Weiterhin sind wir ziemlich eingeschränkt, weil wir über das Git-Repo, von dem aus der CI-Server deployt, nur bestehende Ressourcen aktualisieren oder neue Ressourcen deployen können. Das Löschen von Ressourcen hingegen ist nicht von Haus aus über Commits möglich (beispielsweise durch das Löschen einer Manifest-Datei), nur über manuelles Eingreifen oder zusätzliche Pipelines.

Geringe Auditierbarkeit durch imperative Änderungen

Die Pipelines des CI-Servers ermöglichen imperative Änderungen an der Config. Typischerweise schreibt man hier den Tag des aktuellen Images in die Config. Gängig ist aber auch das Einfügen von Secrets aus dem Credentials-Store des CI-Servers, das Spezifizieren von Helm-Charts oder das Setzen von umgebungsspezifischen Parametern. Dies führt dazu, dass die tatsächlich an den Cluster übertragene Config nur transient auf dem CI-Server besteht. Damit sind Änderungen nicht einfach nachvollziehbar und Fehler schwerer zu finden.

GitOps: Der Operator im Cluster deployt.

Wie können wir diesen Problematiken begegnen? Kann es überhaupt einen anderen Weg geben? Mit GitOps können wir ganz anders vorgehen (siehe Abb. 1–2): Der CI-Server verschwindet bei einem Rollout grundsätzlich komplett aus dem Bild. Stattdessen gibt es einen Prozess innerhalb des Zielsystems, der ununterbrochen das relevante Git-Repository pullt und auf Änderungen überprüft (Pull-Prinzip). Dieser Prozess wird »GitOps-Operator« genannt; im Diagramm ist es Argo CD.

Abb. 1–2
Einfaches Deployment mittels GitOps

Damit können wir den eben genannten Schwierigkeiten bei CIOps sehr gut begegnen:

Selbstheilung durch Continuous Operations

• kontinuierliches Ausrollen: Wir verringern den Zeitraum drastisch, in dem Drift auftreten kann, weil die Manifeste im Git-Repository beständig gelesen und angewandt werden. Bei manuellen Änderungen sorgt der GitOps-Operator also für Selbstheilung. Prinzipiell implementiert GitOps das Deployment, insofern kann man es als Cloud-Native Continuous Deployment (oder Cloud-Native Continuous Delivery) verstehen. Als Fortführung des Gedankens von Continuous Deployment können wir an dieser Stelle auch von Continuous Operations sprechen.
• bessere Sicherheit: Da der GitOps-Operator im Cluster läuft, muss netzwerktechnisch gesehen kein administrativer Zugriff von außerhalb des Clusters mehr erfolgen.

  Außerdem zwingt uns die deklarative Natur von GitOps dazu dedizierte Werkzeuge zum Secrets Management zu verwenden, statt diese im CI-Server zu verwalten (siehe Kapitel 5 auf Seite 97). Dies reduziert das...