GitOps – Continuous Deployment für Kubernetes

  • Deployments mittels kubectl und Helm sind schwer nachzuvollziehen
  • Ein zentrales State Repository beinhaltet den gewünschten Zustand des Systems
  • Mit GitOps können mehrere Umgebungen und Cluster verwaltet und synchron gehalten werden
  • Weave Flux ist die ausgereifteste Implementierung der Deployment-Automatisierung, die für GitOps notwendig ist

Mit dem Aufkommen der DevOps- und SRE-Bewegungen hat sich der Fokus beim Betrieb von Anwendungen weg von rein auf Überwachung spezialisierten Diensten hin zu Tools, die eigentlich von Entwicklern verwendet werden, verschoben.

Infrastructure as Code erlaubt es Systeme deklarativ zu beschreiben und in einem Versionskontrollsystem (VCS) zu verwalten. Agenten sorgen dafür, dass der gewünschte Zustand auf Basis der Fakten hergestellt wird und informieren über Erfolg und Misserfolg.

Auch für die Container-Orchestrierungslösung Kubernetes werden Ressourcen deklarativ festgehalten und das System ist dafür verantwortlich diesen Zustand zu erreichen und zu halten.

Der gewünschte Zustand muss Kubernetes jedoch manuell mitgeteilt werden. Dies ist für Testszenarien eine effektive und zufriedenstellende Lösung, ist aber in großen Systemen schwer nachzuvollziehen. Der Einsatz von Helm hat das ganze Vorgehen übersichtlicher gemacht. So ist es bereits möglich eine aktuelle Auflistung aller installierter Anwendungen und deren Version zu bekommen. Dennoch ist es weiterhin nicht bzw. sehr schwer nachvollziehbar zu welchem Zeitpunkt und durch wen die Installation erfolgt ist.

Mit GitOps hat sich in den letzten Jahren ein Vorgehen etabliert, das genau diese Probleme aufgreift und löst. Das Vorgehen beruht auf vier Grundprinzipien:

Das komplette System ist deklarativ beschrieben

Alle Ressourcen sind in Konfigurationsdateien festgehalten. Dies umfasst nicht nur Deployments, Services, etc., sondern auch beispielsweise Alerting-Regeln und Dashboard-Konfigurationen für Grafana.

Der gewünschte Zustand unterliegt der Versionskontrolle

Die Konfigurationsdateien werden in einem VCS verwaltet. Mittels dem für Entwickler wohlbekannten Workflow mit Pull Requests und Reviews können Änderungen am System begutachtet und abgenommen werden. Sollte eine Änderung Probleme bereiten, kann diese einfach mit den Mitteln des VCS zurückgerollt werden. Dadurch wird es auch leichter nachzuvollziehen welche Person zu welcher Uhrzeit eine Änderung am System ausgelöst hat.

Abgenommenen Änderungen am System werden automatisch ausgerollt

Sobald Änderungen am System abgenommen sind, werden diese automatisch ausgerollt. Agenten kümmern sich um den Abgleich mit dem VCS und propagieren die Änderungen an Kubernetes weiter. Dies hat einen enormen Sicherheitsvorteil, da die Zugangsdaten für den Cluster nicht mehr in einem Drittsystem gespeichert werden müssen.

Software-Agenten stellen die Korrektheit sicher und alarmieren bei Unterschieden

Die Software-Agenten informieren die Operations-Mitarbeiter wenn eine Änderung ausgerollt wird und alarmieren sobald der gewünschte Zustand aufgrund von Konfigurations- oder anderen Fehlern nicht erreicht werden kann.

Transformation zu GitOps

Eine gewöhnliche CI/CD Pipeline sieht nach dem Bauen und Testen der Anwendung ein Deployment vor. Bei GitOps wird das Deployment der Anwendung von Bauen und Testen entkoppelt. Dies ist notwendig, da bei GitOps der zentrale Part das State Repository ist. Dieses beinhaltet den gewünschten Zustand und Änderungen am System sind nur über Modifikation der Konfigurationsdateien in diesem Repository möglich.

CI / CD mit GitOps

 

Sobald eine neue Version einer Anwendung auf dem Cluster ausgerollt werden soll, muss nur die entsprechende Konfigurationsdatei für die Anwendung angepasst werden. Ist die Änderung abgenommen und gemerged, wird diese binnen weniger Minuten durch den State Sync ausgerollt.

Der Aufbau des State Repositories ist bei der Transformation der zeitaufwändigste Part, ist aber dank der Custom Resource Definition für Helm Charts nicht kompliziert. Wird die Anwendung bisher direkt über kubectl installiert, können diese Dateien schlicht in das State Repository verschoben werden.

GitOps in der Praxis

Der Markt bietet derzeit eine gute Handvoll an Tools, die das Vorgehen nach GitOps umsetzen. Platzhirsch und derzeit beste Implementierung ist Weave Flux von Weaveworks. Die fehlenden Benachrichtigungen können über eine Drittsoftware nachinstalliert werden. Das kommerzielle Angebot Weave Cloud bietet die Benachrichtigungsfunktion out-of-the-Box an.

Vergleich der verfügbaren Tools auf Kompatibilität mit GitOps

 

Die Installation von Weave Flux erfolgt über Helm und ist das letzte manuelle Deployment vor dem Umstieg auf GitOps. Weave Flux benötigt keine weiteren Systeme.

Use-Cases für GitOps

Mehrere Umgebungen

GitOps ermöglicht es mehrere Umgebungen zu verwalten und synchron zu halten.
Abhängig von den konkreten Anforderungen können die Umgebungen in mehreren State Repositories oder separaten Verzeichnissen innerhalb eines State Repositories gehalten werden.

Auch ein Vorgehen bei dem die Änderungen von einem Branch zum nächsten Branch mittels Pull Requests durchgereicht werden ist möglich. Die Möglichkeiten unterscheiden sich dabei stark am Grad duplizierter Konfigurationsdateien.

Weave Flux kann entsprechend dem gewählten Szenario konfiguriert werden. Sollten die Umgebungen in separaten Verzeichnissen verwaltet werden, ist es sogar möglich einige Ressourcen, die sich nicht zwischen den Umgebungen unterscheiden, in einem gemeinsamen Ordner zu teilen.

Blue / Green Deployments

Im Rahmen eines Blue / Green-Deployments, um beispielsweise das aktuelle Cluster durch eine neuere Version zu ersetzen, kann GitOps sowohl dazu verwendet werden das neue Cluster initial zu bespielen, als auch beide Cluster bis zum Abschluss des Switches synchron zu halten.

Co-Located Cluster

Auch Co-Located Cluster, die beispielsweise für das Geschäft auf einem anderen Kontinent aufgebaut wurden, können mit GitOps synchron gehalten werden. Beide Cluster müssen dabei nur auf das gleiche State Repository zeigen.

Zusammenfassung

Durch die Entkoppelung von Build & Test und Deployment vereinfachen sich die Build-Pipelines um ein vielfaches, da Komplexität in diesen durch das Hinzufügen von Deployment-Steps entsteht. Durch die Verlagerung des Deployments in den Cluster und die Vereinheitlichung des Deployments-Prozesses wird diese Komplexität sogar gänzlich aufgehoben.

Das State Repository sorgt für maximale Transparenz. Mittels Commit-Log ist man stets in der Lage zu sehen, welche Person Änderungen am System vorgenommen hat. Zudem kann der Kreis der Personen und Systeme, die eine Berechtigung haben, Änderungen am Cluster durchzuführen, minimal gehalten werden.

Über Pull Requests und Reviews kann die Richtigkeit der Änderungen gewährleistet und ein geteiltes Wissen über die Changes geschaffen werden.

Wenn es darum geht mehrere Cluster oder Co-Located Cluster synchron zu halten hat man mit Flux ein mächtiges Werkzeug, das mit einfachen Mitteln bespielt werden kann, und dennoch enorm viel Arbeit abnimmt.

Praktisch hat sich bewährt ein gemeinsames State Repository für alle Umgebungen zu haben und die Umgebungen jeweils in einem separaten Ordner zu beschreiben.

Bei einem Blue / Green Szenario sollten die Änderungen für das derzeit nicht aktive Cluster in einem eigenen Branch durchgeführt werden und diese nach Abschluss der Migration in den Hauptzweig übernommen werden.

Die Automatisierungsfunktion von Flux sollte mit Bedacht eingesetzt werden, um zunächst einmal Vertrauen in den Mechanismus zu bekommen.

Die verwendeten Symbole sind unter CC BY 3.0 lizenziert.
Quelle: http://www.smashingmagazine.com/2014/12/17/freebie-responsive-mobile-icon-set-100-icons-png-psd