Drei Fragen und Antworten: So klappt's mit dem individuellen GitOps-Prozess
Richtig implementiert, nimmt GitOps Admins eine Menge Arbeit ab. Wie man die besten Werkzeuge findet und den eigenen Prozess festlegt, zeigt unser Interview.
Wer seine Kubernetes-Umgebung auf GitOps umstellt, benötigt einen passenden Operator. Vor allem Argo CD und Flux stehen zur Auswahl. Außerdem gilt es, den firmeneigenen GitOps-Prozess zu entwerfen. Worauf es dabei ankommt, erklärt iX-Titelautor Johannes Schnatterer im Interview.
Die GitOps-Operatoren Argo CD und Flux bieten ähnliche Funktionen. Lassen sie sich dennoch irgendwie grundsätzlich unterscheiden? Was kann den Ausschlag für das eine oder das andere Tool geben?
Es gibt tatsächlich sehr viele kleine Unterschiede. Die meisten werden für viele aber nicht relevant sein. Eine Faustformel ist, dass Argo CD sich eher an Endanwender richtet und Flux einfacher in andere Produkte integrierbar ist. Wie der Artikel zeigt, bieten beide aber auch Möglichkeiten, genau umgekehrt eingesetzt zu werden.
Meiner Erfahrung nach ist bei Argo CD häufig relevant, dass es von Haus aus ein UI sowie Templating-Funktionalitäten (ApplicationSets) mitbringt. Flux fühlt sich für viele leichtgewichtiger und mehr Kubernetes-nativ an, ist einfacher zu installieren und zu aktualisieren und bietet bessere UX für Helm. Außerdem bietet es Innovationen beim Support von OCI-Registries und Terraform.
Einige dieser Punkte sind allerdings relativierbar. Beispielsweise gibt es mit Argo CD core eine leichtgewichtigere Konfiguration von Argo CD und für Flux bietet Weaveworks verschiedene UIs an.
Welche weiteren Schritte sind beim Entwurf des eigenen GitOps-Prozesses notwendig?
Zur Auswahl des passenden Operators ist die Kenntnis der Anforderungen notwendig, beispielsweise will man Anwendungen oder Infrastruktur deployen? Welche Kommunikationsstrukturen hat man in seiner Einrichtung? Wie viele Teams, Projekte, Abteilungen beziehungsweise Anwendungen hat man? Welche Infrastruktur, beispielsweise Kubernetes-Cluster, hat man oder will man haben? Welche Environments oder Stages hat man? Und wie sieht der Übergang zwischen ihnen aus (Promotion)? Will man kurzlebige Preview Environments auf Basis von Pull Requests realisieren? Diese Überlegungen helfen bei der Auswahl des Operators und der Überwindung des GitOps-Chasm, der Abbildung der echten Welt auf die Infrastruktur.
Gibt es dafür Hilfen oder muss sich jeder selbst überlegen, wie er seinen GitOps-Prozess gestaltet?
Generell gibt es absichtlich keinen Standard für den einen GitOps-Prozess, weil dieser nach Conways Law abhängig von den Kommunikationsstrukturen einer Organisation ist. Aus der Erfahrung lassen sich jedoch einige wiederkehrende Patterns erkennen. Außer der Entscheidung für einen Operator steht die Strukturierung der Repositories, Promotion zwischen den Environments, Anzahl der Operator und Verdrahtung der Operator an.
Herr Schnatterer, vielen Dank für die Antworten! Den detaillierten Vergleich zwischen Argo CD und Flux liefert ein Titelartikel in der neuen iX, ein weiterer stellt praktische GitOps-Patterns vor. Außerdem wirft das September-Heft, das ab sofort erhältlich ist, einen genauen Blick auf Microsofts Cloud-GAU und das Forensik-Tool Velociraptor.
In der Serie "Drei Fragen und Antworten" will die iX die heutigen Herausforderungen der IT auf den Punkt bringen – egal ob es sich um den Blick des Anwenders vorm PC, die Sicht des Managers oder den Alltag eines Administrators handelt. Haben Sie Anregungen aus Ihrer tagtäglichen Praxis oder der Ihrer Nutzer? Wessen Tipps zu welchem Thema würden Sie gerne kurz und knackig lesen? Dann schreiben Sie uns gerne oder hinterlassen Sie einen Kommentar im Forum.
(jvo)
