Trotz Plattformen wie Kubernetes, die die Container-Orchestrierung übernehmen, ist es nicht immer einfach, containerbasierte Anwendungen, die auf Clustersystemen oder in der Cloud ausgeführt werden, bereitzustellen und zu verwalten. GitOps ist ein Ansatz, der darauf abzielt, Erfahrungen und Werkzeuge aus der Entwicklerarbeit für den Betrieb von Applikationen zu verwenden. Dahinter stehen vier Grundprinzipien:

• Deklarative Beschreibung: Ressourcen werden in einer formellen Sprache in ihrem Soll-Zustand beschrieben.
• Automatisierung: Die Umsetzung der Beschreibungen aus dem Repository in die Laufzeitumgebung muss vollständig automatisiert erfolgen, reproduzierbar sein und zum gleichen Resultat führen, auch wenn sie mehrmals ausgeführt wird.
• «Single Source of Truth»: Ein Systemzustand muss ganzheitlich und eindeutig beschrieben sein. Es gilt eine einzige Quelle, die den Gesamtzustand des Systems zusammenfasst.
• Reconciliation: Softwareagenten gleichen den Ist-Zustand des Systems mit dem Soll-Zustand ab. Sobald Abweichungen auftreten, werden passende Aktionen ausgelöst.

GitOps als Betriebsmodell für Kubernetes

Um den Betrieb eines Softwaresystems zu gewährleisten, braucht es eine Lieferkette, mit der Versionen der Software geliefert werden, aber auch Konfigurationen angepasst werden können. Auf diese Weise wird eine Verbindung zwischen dem Continuous Delivery (CD) und dem eigentlichen Deployment und Betrieb der Applikation geschaffen. Kubernetes verfolgt den Ansatz, dass Ressourcen deklarativ beschrieben werden. Man beschreibt dafür den Zustand der laufenden Applikation (z. B. 3 Instanzen der Applikation X in Version Y mit je 2 CPUs und 500 MB RAM) und Kubernetes kümmert sich darum, dass die entsprechenden Komponenten gestartet werden. Damit sind die ersten beiden Grundprinzipien von GitOps durch Kubernetes selber bereits erfüllt.

Als «Single Source of Truth» wird in GitOps (wie der Name erahnen lässt) die Versionsverwaltung Git verwendet. Damit ist der jeweils gewünschte Systemzustand automatisch transparent, versioniert und nachvollziehbar an einem dedizierten Ort abgelegt. Nachvollziehbarkeit dient der Rückverfolgbarkeit von Änderungen, macht aber auch ein Rollback auf eine alte Version trivial. Ein grosser Vorteil von Git ist ausserdem, dass mit dem Branching-Konzept Änderungen mittels Pull-Requests reviewt werden können. Damit können Fehler in der Konfiguration erkannt werden, bevor sie auf das eigentliche System gelangen.

Das vierte (und wesentlichste) Grundprinzip von GitOps ist, den Laufzeit-Zustand auf dem Kubernetes-Cluster mit dem Soll-Zustand im Git-Repository abzugleichen. Dafür wird ein sogenannter GitOps-Operator verwendet, eine spezialisierte Softwarekomponente, die auf Kubernetes installiert wird und diese Aufgabe automatisiert übernimmt. PostFinance setzt dafür das Tool «Argo CD» ein.

Vorteile von GitOps

• Erhöhte Produktivität: Konsequente Automatisierung ermöglicht es dem Entwickler/Betrieb, sich auf die wesentliche Konfiguration zu fokussieren. Das automatische Ausrollen optimiert die Durchlaufzeiten.
• Shared Tooling: Entwickler und Betrieb verwenden mit Git gemeinsam ein sehr bewährtes Tool.
• Stabilität und Zuverlässigkeit: Alle Änderungen sind nachvollziehbar. Rollbacks sind trivial und dank einer deklarativen Beschreibung kann im Disaster-Fall in kurzer Zeit ein komplettes Recovery erreicht werden.
• Konsistenz und Standardisierung: GitOps ist ein Betriebsmodell und standardisiert den Deployment-Prozess

Warum wir GitOps in der IT für den Bereich Digital Commerce nutzen

Bei PostFinance haben wir den ersten grossen GitOps-Case in der IT für den Bereich Digital Commerce umgesetzt. Dies, weil wir auf die (on-premise) Kubernetes-Plattform migriert sind und eine Lösung gesucht haben, unsere höchstverfügbaren Systeme optimal betreiben zu können. Für das noch relativ junge GitOps haben wir uns entschieden, weil sich GitOps zum Standard entwickelt, um Applikationen auf solchen Clustern zu deployen. Im Digital Commerce sind wir seit letztem Herbst komplett auf diesem Stack.

Wir betreiben nun seit März 2020 unsere Kubernetes-Workloads via GitOps. Die Erfahrungen aus diesem Zeitraum sind durchwegs positiv. Zum einen schätzen wir die Einfachheit, neue Workloads (Features, Services usw.) auf die Systeme zu deployen. Das Vorgehen erleichtert es immens, Änderungen kontinuierlich und mit kurzer Durchlaufzeit durchzuführen. Zum andern können wir dennoch, auch in Anbetracht dieser Flut an Änderungen, auf zuverlässige Systeme zählen. Das Suchen von Konfigurationsunterschieden zwischen verschiedenen Umgebungen reduziert sich auf die Konfiguration im Git-Repository. Die Reconciliation des Operators hilft uns, rund um die Uhr die Kontrolle über die Systeme zu halten, indem wir ungewollte Zustände erkennen und standardisiert beheben.

Nicht zuletzt unterstehen wir im Bereich Digital Commerce strengen Regulationen in Bezug auf Nachvollziehbarkeit und «Segregation of Duties». Mit GitOps haben wir es geschafft, alle diese Vorgaben mit dem DevOps-Gedanken unter einen Hut zu bringen. Produktive Changes sind heute für uns nichts mehr als einfache Pull-Requests, die nach Review und Merge direkt und automatisiert in der Produktion landen.