GitOps geht auch ohne Kubernetes

Anja Kammer

“GitOps funktioniert nur mit Kubernetes als Betriebsplattform!“ Dieses Missverständnis von GitOps hält sich hartnäckig und ist vermutlich der Grund, weshalb es sich noch nicht als Standard-Workflow für Software-Delivery-Prozesse etabliert hat. Wer GitOps einsetzen möchte, findet nahezu ausschließlich Tooling, das Kubernetes voraussetzt. Im Kern gibt GitOps lediglich vor, dass ein Version Control System (VCS) wie Git als Schnittstelle für einen Software-Agent dient, der Deployment- und Betriebsaufgaben innerhalb einer Zielumgebung ausführt.

Die Vorteile von GitOps nutzen

Im Folgenden geht es daher zunächst darum, die Kernfunktionen eines GitOps-getriebenen Delivery-Prozesses zu identifizieren, um darauf aufbauend Strategien kennenzulernen, mit denen sich GitOps auch ohne Kubernetes umsetzen lässt. Wer sich mit GitOps beschäftigt, merkt schnell, dass das verfügbare Tooling Kubernetes als Betriebsplattform voraussetzt. Etablierte Werkzeuge von der Stange, mit denen sich GitOps außerhalb von Kubernetes einsetzen ließe, fehlen bisher noch.

Ein Grund dafür ist, dass zu der Zeit, als Weaveworks das GitOps-Konzept populär gemacht hat, Kubernetes bereits als de facto Standard für moderne Betriebsplattformen in der IT-Community anerkannt war. Es ist eine standardisierte Betriebsumgebung, die eine einfache Verwaltung der Ressourcen über eine API ermöglich. Daher ist es sinnvoll, neues Tooling auch bevorzugt für Kubernetes zu entwickeln. Allerdings sollte nicht jedes Softwaresystem mit Kubernetes betrieben werden, und die Gründe hierfür sind nicht technischer Natur.

Beispielsweise ist die Größe eines Unternehmens oder der IT-Abteilung ein entscheidender Faktor. Ein kleines Team könnte Schwierigkeiten haben, die Komplexität von Kubernetes zu bewältigen und nötiges Know-how aufzubauen. Selbst die bloße Verwendung und Konfiguration eines vom Cloud-Provider betriebenen Kubernetes-Clusters erweist sich in vielen Fällen schon als komplexe Herausforderung. Stattdessen ist es für kleinere Organisationen möglicherweise sinnvoller, auf stärker abstrahierte Plattform wie Heroku zurückzugreifen.

Dasselbe Prinzip lässt sich auf die Größe und Komplexität des zu betreibenden Softwaresystems anwenden. Wenn lediglich eine Handvoll Container deployt werden sollen, übersteigt die Komplexität des Betriebs von Kubernetes den Nutzen. Für große Systemlandschaften andererseits kann es sinnvoller sein, eine eigene Kubernetes-basierte Infrastruktur aufzubauen, da es langfristig kosteneffektiver sein kann, eigene Kompetenz aufzubauen und mehr Flexibilität bietet. Darüber hinaus gibt es auch Organisationen, die bereits mit ihrer bestehenden Betriebsplattform zufrieden sind oder aufgrund laufender Verträge an eine bestimmte Plattform gebunden sind.

Dennoch sollten die Organisationen, die Kubernetes nicht einsetzen können, von den Vorteilen profitieren können, die GitOps bietet[1]:

• Einfache und schnelle Fehlerbehebung
• Sichere Deployments
• Sich selbst dokumentierende Deployments
• Leichtere Personalbesetzung und schnelleres Onboarding

GitOps mit und ohne Kubernetes

Abbildung 1 zeigt eine stark vereinfachte Darstellung eines GitOps-Workflows mit Kubernetes. Im Zentrum des Workflow-Modells steht das Repository, das Änderungen an der Anwendung aufzeichnet. Eine Build-Pipeline wird von Aktivitäten im Repository getriggert, die die Anwendung aktualisiert.

Im Kubernetes-Cluster befindet sich der GitOps-Operator und die von diesem gemanagten Applikationen. Die Definition eines Operators im Kubernetes-Universum ist sehr spezifisch. Ein Operator ist speziell darauf ausgelegt, eine Anwendung oder einen Service innerhalb des Clusters zu verwalten und zu betreiben. Ein Operator kann dabei auch komplexe Aufgaben wie die Konfiguration von Load Balancern oder die Integration mit anderen Services übernehmen.

Der Operator hat also die Aufgabe, erst nach dem vollständigen Durchlaufen der Build-Pipeline, die Anwendung in die Betriebsumgebung, den Kubernetes-Cluster, zu deployen. Üblicherweise beschreibt dabei der Main-Branch die aktuell deployfähige Softwareversion, alternativ lassen sich Git-Tags verwenden. Einige Komponenten wie die Image-Registry fehlen in der Abbildung, sind aber selbstverständliche Bestandteile des Systems.

Das Repository enthält die gesamte Anwendungs- und Infrastrukturkonfiguration, mit deren Hilfe sich eine Anwendung jederzeit von Grund auf deployen und regelmäßig aktualisieren lässt. Der Build-Pipeline fällt dabei die Aufgabe zu, ebenfalls die Infrastrukturkonfiguration zu testen. Auch das Ausführen von Integrationstests ist so leicht umsetzbar. Das Repository kann zudem den eigentlichen Anwendungscode enthalten, um die Umgebungskonfiguration gemeinsam mit der Anwendung selbst zu versionieren.

Die Bezeichnung dieses Repositorys kann je nach Präferenz variieren, im Folgenden soll der Begriff Environment-Repository verdeutlichen, dass die enthaltene Anwendungs- und Infrastrukturkonfiguration idealerweise eine vollständige Betriebsumgebung mit all ihren nötigen Komponenten (z.B.: Web-Worker, Scheduler, Funktionen und Persistenz) abbildet.

Abbildung 2 zeigt einen GitOps-Prozess ohne Kubernetes. Gegenüber Abbildung 1 ändern sich lediglich die Bezeichnungen: Die allgemeine Betriebsumgebung ersetzt den Kubernetes-Cluster. Kubernetes lässt sich auch als eine Betriebsumgebung bezeichnen. Aus dem Operator wird ein generisches GitOps-Tool, meint aber im Prinzip dasselbe. Abbildung 2 spiegelt damit wider, dass die Konzepte aus dem Kubernetes-Universum auf andere Betriebsumgebungen übertragbar sind. Zu den beiden essenziellen Komponenten Operator und Betriebsumgebung folgen in den nächsten Abschnitten detaillierte Definitionen.

Operator – eine pragmatische Definition

Im Kubernetes-Universum ist das Operator-Konzept klar definiert. Den Operator kennzeichnen folgende Eigenschaften:

• Überwacht, verwaltet und steuert Ressourcen in einer Betriebsumgebung
• Agiert als intelligente Schicht, die diese Aufgaben anhand bestimmter Verhaltensregeln ausführt
• Ist ein Stück konfigurierbare Software, programmiert mit diesen Verhaltensregeln

Ein Operator lässt sich als ein Hintergrundprozess oder Agent betrachten. Ein Daemon ist solch ein Hintergrundprozess, der auf einem Linux-System läuft und bestimmte Aufgaben ausführt, während der Agent eine Softwarekomponente ist, die für das Überwachen, Verwalten oder Steuern eines bestimmten Systems oder Dienstes zuständig ist. Ein Agent lässt sich als eine Art Daemon betrachten, der speziell für die Aufgabe der Verwaltung oder Überwachung entwickelt wurde.

Ein Operator muss nicht zwingend ein Stück Software sein

Es gibt die Rolle eines Operators, als menschliches Mitglied einer Operations-Abteilung. Ein menschlicher Operator ist ebenfalls für das Überwachen und Verwalten von Systemen verantwortlich, ob Software oder Hardware. Darum ist es wichtig, bezüglich der Definition von Operatoren nicht dogmatisch zu sein. GitOps sagt aus, dass ein Versionskontrollsystem wie Git als Schnittstelle für einen Operator dient, der wiederum Deployment- und Betriebsaufgaben innerhalb einer Zielumgebung ausführt. In Anbetracht dieser Konzepte lässt sich GitOps-Tooling, das innerhalb der Zielumgebung läuft, ebenfalls als Operator betrachten – zumal dieser Begriff nicht auf das Kubernetes-Universum beschränkt ist.

Daraus lässt sich ableiten, dass Organisationen, die nicht auf Kubernetes-natives GitOps-Tooling zurückgreifen können, eigene Operatoren bauen können. Dabei ist lediglich zu klären, welche Kernfunktionen implementiert sein müssen.

Kernfunktionen

Viele der vorhandenen Kubernetes-nativen GitOps-Tools haben zahlreiche nützliche Funktionen, die den Betrieb erleichtern. Einige davon sind jedoch für einen GitOps-getriebenen Workflow nicht notwendig. Das OpenGitOps-Projekt hat dazu Prinzipien definiert[2], aus denen sich die Kernfunktionen eines GitOps-Operators ableiten lassen.

Prinzip 1: Deklarativ

“Bei einem von GitOps verwalteten System sollte der gewünschte Zustand deklarativ ausgedrückt werden.” (OpenGitOps-Projekt – Principles)

Das erste Prinzip setzt eine deklarative Beschreibung des gewünschten Zustands (Desired State)[3] eines von GitOps verwalteten Systems voraus. Diese Zustandsbeschreibung lässt sich mit beliebigen Infrastructure-as-Code Tools erstellen, die oft auch für Anwendungskonfigurationen zum Einsatz kommen. Das verwendete GitOps-Tool beziehungsweise der Operator muss dann herausfinden, wie sich der vorhandene Zustand des Systems in den gewünschten überführen lässt und diese Transformation vornehmen. Darüber hinaus hängt die Umsetzung dieses Prinzips von der Definition der Infrastruktur- und Anwendungskomponenten ab. Dient beispielsweise Terraform als Deployment- und Provisioning-Tool, gilt das Prinzip bereits als erfüllt.

Prinzip 2: Versioniert und unveränderlich

“Der gewünschte Zustand wird auf eine Weise gespeichert, die Unveränderlichkeit und Versionierung erzwingt und eine vollständige Versionshistorie aufbewahrt.” (OpenGitOps-Projekt – Principles)

Um beim Terraform-Beispiel zu bleiben: das zweite Prinzip gilt als erfüllt, wenn die Terraform-Dateien im Environment-Repository abgelegt sind. Dabei ist jedoch das Neuschreiben der Git-Historie zu unterbinden, da sich ansonsten die Commit-Historie manipulieren lässt.

Es gilt zu beachten, dass dieses Prinzip nicht nur für die Produktivumgebung, sondern unter anderem auch für Dev- und Test-Umgebungen wichtig ist. Dies ermöglicht es, jederzeit auf frühere Versionen der Zustandsbeschreibung zurückzugreifen, was besonders bei der Fehlerbehebung und bei automatisierten Rollbacks hilfreich sein kann. Eine derartige Historie eröffnet eine lückenlose Nachvollziehbarkeit von Änderungen, die allerdings in der Praxis nur selten einen Anwendungszweck findet.

Prinzip 3: Pull-basiert

“Software-Agents ziehen die Beschreibung des gewünschten Zustands automatisch aus der Quelle.” (OpenGitOps-Projekt – Principles)

Während traditionelle CI/CD-Systeme (Continuous Integration / Continuous Delivery) einem Push-basierten Workflow folgen, bei dem der Deployment-Prozess Zugriff auf die Zielumgebung über ein Token, einen Schlüssel oder ein Zertifikat erhält, sieht das dritte Prinzip des OpenGitOps-Projekts ein Pull-basiertes (ziehen) Deployment vor. Push-basierte Workflows gelten als vulnerabel, denn sobald das CI/CD-System kompromittiert ist, lässt sich der Zugriff zur Zielumgebung ausnutzen. In der Regel verwalten zentrale Build-Server alle Secrets und Schlüssel für Anwendungen und Systeme eines gesamten Unternehmens. Wenn Angreifende in den Build-Server eindringen und diese Schlüssel und Secrets auslesen, können sie somit alle Systeme des Unternehmens kompromittieren.

Im Vergleich dazu stellt der Pull-basierte Ansatz von GitOps sicher, dass der Operator den Deployment-Prozess ausschließlich innerhalb der Zielumgebung ausführt. Das trägt zu erhöhter Sicherheit bei, da die Zielumgebung, beispielsweise die Produktionsumgebung, typischerweise besser geschützt ist als ein Build-Server, auf dem alle Secrets liegen. Abbildung 4 macht deutlich, dass es sich bei diesem Ansatz im Prinzip um das Verlagern der Deployment-Pipeline in die Zielumgebung handelt.

Ein pull-basierter Workflow lässt sich auf zwei Arten implementieren, mit Polling und Webhooks. Beim Polling holt der Operator im Takt weniger Minuten den Inhalt des Repositorys mit der Zustandsbeschreibung ab. Mit Webhooks schickt der Git-Provider (GitHub, GitLab etc.) eine Meldung an den Operator, sobald es im Repository eine Änderung gibt. Der Operator holt sich bei dieser Variante sofort nach dieser Meldung die Zustandsbeschreibung ab und passt gegebenenfalls die Zielumgebung an. Das hat den Vorteil, dass Entwicklungsteams bei einem Deployment nicht auf die Ausführung des nächsten Zyklus warten müssen, sondern innerhalb weniger Sekunden die Anpassung durch den Operator stattfindet.

Oft kommen beide Varianten, Polling und das Reagieren auf Webhooks, zum Einsatz. Das hat etwas mit dem nächsten Prinzip zu tun, dem kontinuierlichen Abgleich.

Prinzip 4: Kontinuierlicher Abgleich

“Software-Agents beobachten kontinuierlich den aktuellen Systemzustand und versuchen, den gewünschten Zustand herzustellen.” (OpenGitOps-Projekt – Principles)

Der kontinuierliche Abgleich (Reconciliation Loop)[4] stellt den anspruchsvollsten Teil des GitOps-Workflows dar. Hierbei geht es nicht nur darum, die Umgebung bei jeder Konfigurationsänderung entsprechend anzupassen, sondern auch, zu jeder Zeit den gewünschten Zustand zu erhalten. Konfigurationsänderungen, die manuell oder versehentlich passiert sind, werden so in einem regelmäßigen Zyklus wieder zurückgesetzt.

Es ist daher üblich, Personen oder Prozessen nicht zu erlauben, Ressourcen in der Betriebsumgebung zu verändern, die unter der Kontrolle des Operators stehen. Ein Nachteil dieser Vorgehensweise ist, dass sich beispielsweise Hotfixes nicht mehr bereitstellen lassen, sollte der Operator ausfallen. Am Beispiel von Terraform lässt sich dieses Prinzip leicht nachvollziehen. Terraform überschreibt den Zustand der Ressourcen, falls sie nicht der aktuellen Konfiguration entsprechen. Um das zu erreichen, gilt es, regelmäßig einen Ausführungsplan zu erzeugen und bei auftretenden Divergenzen anzuwenden.

Zusätzlich lässt sich eine Kopie der zuletzt gezogenen Zustandsbeschreibung für den Operator vorhalten, um die Umgebung jederzeit in den zuletzt bekannten Zustand zurückzuversetzen, auch wenn kein Zugriff auf das Quell-Repository möglich sein sollte.

Implementierung

Anhand der vier GitOps-Prinzipien sind die Kernfunktionen eines GitOps-Operators nun identifiziert:

• Deklarativ
• Versioniert und unveränderlich
• Pull-basiert
• Kontinuierlicher Abgleich

Das Umsetzen dieser Prinzipien erfordert keine speziellen Tools, allerdings gibt es bereits Systeme, die in der Lage sind, mit Automatisierungsprozessen umzugehen. Mithilfe einer Workflow-Engine, die über Webhooks angesprochen wird, lassen sich beliebige Prozesse wie etwa das Terraform CLI ausführen. Eine Workflow-Engine bildet im Prinzip die Grundform eines CI/CD-Systems.

Deswegen erfüllen CI/CD-Systeme in der Praxis oft schon alle Anforderungen:

• Lauschen auf Webhooks für Git-Aktionen
• Ziehen von Repository-Inhalten
• Ausführen von Prozessen
• Rückmelden des Ergebnisses (optional)

Aus diesem Grund ist es vollkommen valide, einen GitOps-Operator mithilfe eines CI/CD-Systems zu implementieren, das innerhalb der Zielumgebung läuft. Eine weitere Möglichkeit, einen GitOps-Operator zu implementieren, ist der Einsatz spezialisierter Tools wie Atlantis für das Verwalten von Terraform-Ressourcen. Das unter Apache-2.0-Lizenz verfügbare Atlantis ist ein Server, der auf Webhooks reagiert und Terraform-Kommandos daraus liest. Neben Git-Provider-Webhooks lassen sich auch Slack-Webhooks verwenden, mit denen es möglich ist, Deployments nicht durch das Beobachten des Git-Repositorys auszulösen, sondern durch Chat-Nachrichten. Das wiederum entspricht nicht den GitOps-Prinzipien. Chat-Plattform-Webhooks lassen sich besser dafür nutzen, mehr Einblick in das System durch Statusabfragen zu erlangen. Diese Statusabfragen sind im Slack-Kanal leicht für viele Personen einsehbar.

Obwohl Atlantis auf den ersten Blick einfach zu bedienen ist, stellt das Implementieren des kontinuierlichen Abgleichs eine gewisse Hürde dar. Glücklicherweise bietet Atlantis eine API, über die sich der Prozess von außen steuern lässt. Das kann per einfachem Cron-Skript oder über eine zeitgesteuerte Funktion erfolgen.

Im Prinzip lassen sich alle erforderlichen Funktionen eines GitOps-Workflows mit Git, einem Infrastrukturautomatisierungswerkzeug der Wahl und ein wenig Glue-Code implementieren.

Nice-to-Have-Features

GitOps-Tools stehen gelegentlich dafür in der Kritik, dass ihnen essenzielle Features wie zum Beispiel Secrets Management fehlen. Hintergrund dieser Einschätzung ist die Annahme, dass GitOps-Tools per se darauf ausgelegt seien, CI/CD-Systeme zu ersetzen und daher auch die gleichen Funktionen anbieten sollten.

Secrets Management

Gerade weil CI/CD-Systeme oftmals Laufzeit-Secrets beinhalten, zählen sie mittlerweile zu den kritischen Einfallstoren innerhalb der Software Supply Chain. Ein prominentes Beispiel dafür ist der Vorfall bei Travis CI, bei dem sieben Tage lang alle Secrets offen lagen. Vergleichbare Sicherheitslücken sind auch bei anderen CI/CD-Providern möglich, wie weitere Vorfälle in der Vergangenheit gezeigt haben.

Auch das bereits angesprochene Prinzip des pull-basierten Workflows von GitOps zeigt, dass Zugänge zur Betriebsumgebung nicht in CI/CD-Systeme abgelegt sein sollten. Deshalb ist es unabhängig von GitOps wichtig, eine Secrets-Management-Strategie zu implementieren, da es sich um einen sensiblen Faktor handelt. Es gibt unterschiedliche Ansätze, Secrets bereitzustellen. Zum einen gibt es Secrets-Vaults wie HashiCorp Vault, die erst in der Zielumgebung benötigte Secrets bereitstellen, basierend auf Berechtigungen und Referenzen. Zum anderen entschlüsseln Tools wie etwa Bitnami Sealed Secrets, zuvor verschlüsselte Secrets erst in der Zielumgebung wieder.

Rollback-Mechanismen

Ein entscheidender Vorteil des GitOps-Ansatzes ist, dass sich Rollbacks von Entwicklungsseite so einfach ausführen lassen wie ein ‘git revert’-Kommando. Schlägt jedoch ein Deployment fehl, kann es zu Abweichungen zwischen der Beschreibung des gewünschten Zustands im Environment-Repository und dem aktuellen Zustand der Zielumgebung kommen.

Selbst im Kubernetes-Kontext existiert kein automatischer Rollback-Mechanismus. Stattdessen bleibt das fehlerhafte Deployment hängen und startet immer wieder erneut, bis es erfolgreich ist. Das ist eine Design-Entscheidung, die trotz ihrer Einfachheit sehr resilient ist.

Dringend zu empfehlen ist daher, im Falle eines fehlgeschlagenen Deployments einen Alarm auszulösen, damit Entwicklungsteams manuell im Environment-Repository die fehlerhaften Konfigurationen korrigieren können. Dadurch wird der GitOps-Operator befähigt, die Zustandsbeschreibung erneut einzulesen und auszuführen.

Grafische Benutzungsoberflächen

Zwar zählen grafische Benutzungsoberflächen nicht zu den Kernfunktionalitäten von GitOps-Tools, dennoch finden jene Werkzeuge, die eine anbieten, besonders viel Anklang bei Nutzenden. Diese Oberflächen locken mit einer anschaulichen Visualisierung der System-Topologie und stellen Knöpfe bereit, um unter anderem ein Deployment manuell anzustoßen. Solche Funktionen lassen sich allerdings auch mit dedizierten Werkzeugen bereitstellen, wobei das manuelle Anstoßen eines Deployments nur ein Git-Commit entfernt ist.

Das Implementieren aller bisher beschriebenen Nice-to-Have-Features sowie weiterer Funktionalitäten kann hilfreich sein, ist aber keineswegs notwendig. Tatsächlich ist es der Unix-Philosophie zufolge oft von Vorteil, solche Aufgaben auf spezialisierte, eigenständige Tools auszulagern. Die Unix-Philosophie propagiert das Entwickeln kleiner, modularer Komponenten, die leicht integrierbar sind und jeweils einen einzigen Zweck erfüllen. Das Motto ist: “Do one thing and do it well”.

Bereits ausgereifte Tools für die erweiterten Anforderungen des GitOps-Workflows sollten demnach als eigenständige Komponenten zum Einsatz kommen. Es ist nicht notwendig, dass ein einzelnes GitOps-Tool Aufgaben übernimmt, die nicht zur Kernfunktionalität gehören.

Für GitOps geeignete Betriebsumgebungen

Nachdem die Kernfunktionalitäten eines GitOps-Operators geklärt sind, gilt es nun noch, die Betriebsumgebung zu definieren. Sie umfasst alle Komponenten und Anwendungen, die der Operator verwaltet. Handelt es sich um eine einzelne Virtual Machine (VM), lässt sich der Operator als Daemon betreiben. Die Betriebsumgebung kann aber auch als Cluster mehrerer Maschinen vorliegen, in dem der Operator als eine von vielen Workloads läuft. In beiden Fällen benötigt der Operator die Berechtigung, Workloads zu modifizieren, die sich innerhalb der Betriebsumgebung selbst befinden.

Oft wird vergessen, dass solch eine Betriebsumgebung aber auch die Gesamtheit aller Ressourcen in einer abgeschlossenen Cloud-Umgebung sein kann. Der Operator kann dabei als Funktion oder als VM innerhalb der Umgebung laufen und Zugriff auf die API des Cloud-Providers haben. In diesem Szenario kann es herausfordernd sein, den Überblick über die verschiedenen Dienste, Ressourcen und Deployments zu behalten, die der Operator verwaltet. Es bietet sich daher an, konkrete Berechtigungsgrenzen festzulegen. Die großen Cloud-Provider arbeiten dazu mit dem Konzept der Landing Zones.[5] [6] [7]

Die in Abbildung 5 gezeigten Beispiele für Betriebsumgebungen (VM, Cluster, Cloud Landing Zone) sind im GitOps-Kontext vollkommen valide, denn sie entsprechen der Beschreibung einer Betriebsumgebung (bzw. Laufzeitumgebung) des OpenGitOps-Projekts:

1. Die Laufzeitumgebungen bestehen aus den zu verwaltenden Ressourcen.
2. Die Management-Agents laufen innerhalb jeder Laufzeitumgebung.
3. Es gibt Richtlinien zur Kontrolle des Zugriffs und der Verwaltung von Repos, Deploys und Runtimes.

Im Übrigen gehört ein GitOps-konformes Pull-basiertes Deployment für stark abstrahierte Plattformen wie Heroku und Netlify zur Standardfunktionalität. Damit ist also die Betriebsumgebung definiert durch ein Projekt bei einer dieser Plattformen.

Isolation

GitOps eröffnet eine sichere Möglichkeit, Anwendungen zu deployen, weil der zentrale Build-Server wegfällt, der alle möglichen Applikationen einer gesamten Organisation verwaltet. Sicherheit bietet GitOps dadurch, dass der Operator innerhalb einer spezifischen Betriebsumgebung lebt, in der auch die Anwendungen selbst verwaltet werden. Was darüber hinaus allerdings noch sichergestellt werden muss, ist Isolation.

Um den Operator von Ressourcen zu isolieren, die nicht verwaltet werden sollen, und das System vor Angriffen durch die Manipulationen der Infrastrukturkonfiguration zu schützen, sind zwei Fragen zu beantworten:

• Soll ein Operator pro Team, Domain oder Applikation zum Einsatz kommen?
• Gilt es innerhalb dieser Dimensionen noch zusätzlich pro Stage (Dev, Staging, Prod) zu unterscheiden?

Sind diese Fragen beantwortet, geht es darum, die Resource Boundary zu definieren[8]. Sie gibt an, welche Ressourcen der Operator konkret verwalten darf. Eine Applikation, die als Self-Contained System (SCS)[9] konzipiert ist, kann aus mehreren Komponenten bestehen, wie etwa Web-Applikationen, Scheduler, Funktionen und S3 Buckets.

Doch sollten auch Daten, Netzwerkkonfiguration, Quotas und Berechtigungskonfigurationen (IAM) von der Resource Boundary eingeschlossen werden? Im Hinblick auf die Sicherheit macht es einen großen Unterschied, ob der Operator lediglich die Berechtigungen für ein S3 Bucket setzen darf oder auch in der Lage ist, neue Benutzungskonten zu erstellen. Überlegungen dazu sind aus Sicherheitsgründen essenziell, vor allem, wenn die Betriebsumgebung eine vollständige Cloud-Umgebung ist.

Fazit: Da hilft nur selbst bauen

Es gibt Organisationen und Softwareprojekte, für die das Betreiben ihrer Anwendungen in Kubernetes keine Option ist. In diesen Fällen kann ein selbst gebauter GitOps-Operator Abhilfe schaffen. Dabei können Workflow-Engines und vorhandenes Deployment und Provisioning-Tooling als Grundlage dienen. In Kombination mit einer geeigneten Ressourcenisolation über die Einschränkung der Operator-Berechtigungen kann ein GitOps-Workflow auch in erweiterten Betriebsumgebungen wie Cloud Landing Zones umgesetzt werden.

Vielen Dank an meine Kollegen Eberhard Wolff, Joachim Praetorius, Lucas Dohmen, Michael Vitz, Sascha Selzer und Theo Pack für das Feedback zu einer früheren Version des Artikels.

Quellen