GitOps: Continuous Delivery für Infrastructure as Code

Der Einsatz von Infrastructure as Code hat sich längst als Best Practice zur Verwaltung von Cloud Ressourcen erwiesen, wie in einem anderen Blogbeitrag der HSLU ausführlich dargelegt wurde. Unsachgemäss verwendet gehen aber zahlreiche Vorteile von IaC verloren, das GitOps-Pattern kann hingegen unterstützend wirken.

Zu den Hauptvorteilen von Infrastructure as Code (IaC) gehören die schnelle, konsistente und nachvollziehbare Bereitstellung von Ressourcen. Aber Hand aufs Herz, vermutlich jede Person welche automatisierte Prozesse zur Provisionierung von Ressourcen einsetzt, hat diese Ressourcen auch schon im Nachhinein wieder von Hand verändert. Gerade bei komplexen, umständlichen Pipelines oder Prozessen welche den Code applizieren sollen wird durch manuelle Änderungen zwar Zeit gespart, Konsistenz und Nachvollziehbarkeit gehen aber definitiv verloren…

Das GitOps-Pattern zeichnet sich im Kern durch folgende Punkte aus:

  • Git Repository als Source of Truth (deklarierter Soll-Zustand)
  • Überwachung der provisionierten Ressourcen (effektiver Ist-Zustand)
  • Fortlaufende Konsolidierung zwischen Ist- und Soll-Zustand

Durch die fortlaufende Überwachung und Konsolidierung zwischen deklariertem Soll-Zustand und effektivem Ist-Zustand unterscheidet dabei das GitOps-Pattern von traditionellen Automatisierungs-Pipelines, welche oft nach dem Fire and Forget-Prinzip den gewünschten Zustand nur einmalig initial herstellen.

GitOps Workflow (Quelle: Simon Murer)
GitOps Workflow (Quelle: Simon Murer)

Dieser GitOps-Workflow von kontinuierlicher Überwachung und Konsolidierung wird durch den Einsatz eines GitOps Operators erreicht, wobei FluxCD, ArgoCD und Jenxins X zu den Bekanntesten gehören.

Improved Infrastructure as Code 

Ein solches Pattern verstärkt die Vorteile von IaC: Ressourcen werden noch schneller erstellt beziehungsweise verändert (Anwenden des Codes erfolgt nach einchecken im GIT automatisch durch den Operator), eine noch höhere Konsistenz wird erreicht (jede Abweichung vom Soll-Zustand wird erkannt und korrigiert) und die Nachvollziehbarkeit ist noch besser (Änderungen sind nur noch am GIT-Repo vorzunehmen und dort zentral abgebildet).

GitOps ist dabei prädestiniert für den Einsatz mit Kubernetes, da dessen Controller– und Operator-Patterns eine sehr unkomplizierte Implementation dieses Workflows erlauben. Selbst simple Ressourcen lassen sich dadurch mit geringstem Aufwand in dieses Pattern integrieren.

Der Einsatz des GitOps-Patterns ist dabei aber keinesfalls nur auf Kubernetes beschränkt, entsprechende Controling Loops können mit etwas Kreativität auch problemlos für andere Systeme gebaut werden. In der Praxis hat sich allerdings gezeigt, dass ohne ein bestehendes Controller-Pattern auf der darunterliegenden Infrastruktur der Aufwand aufgrund der gesteigerten Komplexität relativ hoch ist.

With great power comes great responsibility

GitOps bietet wie jede Technologie auch Herausforderungen im Bereich der Sicherheit: 

  1. GIT Zugriffssteuerung: Es ist essentiell, dass nur autorisierte Personen Änderungen an der Konfiguration vornehmen, da diese re-deployments welche die Systemverfügbarkeit beeinträchtigen nach sich ziehen können. Entsprechende Merge- und Approval-Prozesse können ungewollte Deployments verhindern.
  2. Secrets: Keys, Tokens und ähnlich sensitive Ressourcen gehören nicht in ein Code Repository und sollten erst während des Deployment der effektiven Ressourcen injected werden. Tools wie SealedSecrets oder Hashicorp Vault können hier Abhilfe schaffen.
  3. Konfiguration des GitOps Operators : Eine durchdachte Konfiguration des GitOps Operators ist unablässig, da dieser in der Regel erhöhte Berechtigungen bedingt, um die verwalteten Systeme zu konfigurieren. Gerade in Multi-Tenant Umgebung ist ein sauberes Berechtigungskonzept und dessen korrekte implementation zentral um ungewollte Priviliege Escalations zu verhindern.

Unter Berücksichtung dieser Sicherheitsaspekte kann GitOps ein sehr effizientes Pattern bei der Verwendung von IaC sein, allem voran im Kubernetes-Umfeld aufgrund des geringen Implementationsaufwands.

Weiterführende Informationen finden sich auf der Webseite der OpenGitOps Working Group.

Beitrag teilen

Simon Murer

Simon Murer bloggt aus dem Unterricht des CAS Cloud and Platform Manager.

Alle Beiträge ansehen von Simon Murer →

Schreibe einen Kommentar