New Adventures in ArgoCD: Automatisieren des Automatisierens
ArgoCD ist ein wunderbares CICD Tool, um Git-basierte Kubernetes Deployments zu erleichtern. Helm ist eine mit gutem Grunde verbreitete Lösung, um komplexe Kubernetes Deployments zu vereinfachen und an den eigenen Bedarf anpassen zu können. Es wird sogar von Argo per se unterstützt. Man kann sich nichts Besseres wünschen als eine Kombination der beiden. Oder?
Im Prinzip ja, aber …
Bei einem Kunden wurde die Verwaltung der Kubernetes-Umgebung von den alten Shell-Script-basierten Deployments auf ArgoCD umgestellt. Mit gutem Recht, die neue Lösung hat viele Vorteile. Klare Berechtigungen, geheimgehaltene Secrets, GitOps an sich – ja, diese Transparenz spricht für sich.
Ein guter Helm Chart kümmert sich um vieles, von Pods über ConfigMaps zu Ingress Rules. Er wird bereitgestellt und in Kürze ist eine komplexe Anwendung funktionsfähig. Traumhaft, ohne Zweifel.
Das hat aber ziemlich wenig Wert, wenn die Logik der verwendeten Quellen sich drastisch ändert, und manuell bzw. über Argo nicht dasselbe ausgerollt wird. Und eben das war in unserem Fall das Problem. Hat man mit Helm-Befehlen die Anwendung in Frage ausgerollt, hat alles wunderbar geklappt. Wollte man das Gleiche mithilfe von ArgoCD erledigen, war das Resultat katastrophal. Unlogische Namen, leere Verknüpfungen, nicht existierende Pods und damit eine Anwendung, die einfach nicht funktionierte.
Automatisiertes Ausrollen einer automatisierten Automatisationslösung: Jenkins in Kubernetes
Die Anwendung war übrigens Jenkins, an sich schon eine gut verbreitete Automatisierungslösung. Es könnte erstmal überraschend klingen, dass statt den üblichen Kubernetes-Lösungen auf so eine klassische Lösung gesetzt wird. Jede Woche werden Automatisierungsplattforme in der Cloud neu erfunden, warum dann also Jenkins?
Na ja, eigentlich einfach: Das Programm funktioniert, ist äußerst robust und entwickelt sich mit der Zeit. Es ist auch im Kubernetes-Umfeld ein legitimer Spieler, der sich durch die unendlichen Plug-ins wunderbar integrieren lässt, automatisch mit Git umgehen kann und den man deklarativ einrichten kann. Jenkins ist nicht veraltet. Jenkins ist erfahren. Insbesonders bei einem Unternehmen im Enterpriseumfeld bietet es Vorteile, insbesondere dank der Integrationsfähigkeit.
Natürlich unter der Annahme, dass die Anwendung erfolgreich bereitgestellt wird, und damit sind wir wieder beim Kernpunkt.
Die Helm Charts
In unserem Fall wurde ein Upgrade vorgestellt: die neueste Version von Jenkins, auch im Erscheinungsbild modernisiert. Wichtiger ist aber, dass es auch unter der Haube aufgefrischt wurde.
Mit sehr schön und sorgfältig geschriebenen Helm Charts sogar. Und das war eben das Problem. Die Charts waren nicht mehr hundertprozentig mit der alten Logik kompatibel (es hat sich zum Beispiel geändert, wo die deklarativen Plug-in-Einstellungen eingebunden sind), aber auch eher für klassische Helm-Szenarien gedacht. (Ungefähr) dieser Code
helm install -f myvalues.yaml myjenkins ./jenkins
hat die Charts wunderbar in eine Anwendung umgewandelt, keine Frage.
Das Problem war aber, dass die ganze Chart-Logik für eine manuelle Installation konzipiert war. Und Argo ist nur so schlau, wie alle Rechner im Allgemeinen: Es tut eben das, worum es gebeten wird. In diesem Fall: Nimm die Helm Charts und rolle sie aus. Stelle keine Fragen, führe keine Interaktion durch, rolle sie einfach aus (wenn man ständig eingreifen muss, geht es nicht mehr um Automatisierung, oder?). Hier mein Repo, ich möchte mich innerhalb von fünf Minuten in Jenkins unter myjenkins.mynamespace.mycompany.com anmelden können. Möglichst mit Admin-Rechten. Mit allen meinen vordefinierten Pipelines und Jobs und Quellen eingerichtet. Es ist möglich und auch nicht besonders kompliziert.
So ist dann unser eigentliches Projekt entstanden: Es ging darum, die Charts so anzupassen, dass die oben beschriebene Aufgabe wirklich durchgeführt wird. Der wichtigste Unterschied zwischen der klassischen Helm-Logik und einer Kombination von Helm und Argo, den wir hier erkannt haben: Für ArgoCD muss alles möglichst explizit konfiguriert werden, damit das Programm unseren Wunsch tatsächlich erfüllt. In den Charts und Values müssen alle kleinen Details sorgfältig eingerichtet werden – unter den Rahmenbedingungen, dass die umgebungsabhängigen Parameter umgebungsabhängig bleiben und die ursprüngliche Logik der Charts nicht komplett neu geschrieben wird. Es wird ja von demselben Team in Zukunft weitere Updates geben, die hier auch eingepflegt werden sollen. Immer wieder alles neu schreiben wäre alles, außer effektiv.
Dementsprechend haben wir die Helm-Manifeste Schritt für Schritt verglichen: die überlappenden Einstellungen bereinigt und vereinheitlicht, die Mount Points der Ressourcen angepasst, gegebenenfalls die Konfigurationen neu geschrieben. Wir sind dabei so nah an den urpsrünglichen Quellen geblieben wie möglich.
Und es ist uns gelungen: Nach zahlreichen Versuchen und Tests konnten wir Jenkins so zur Verfügung stellen, wie es gebraucht wurde – basierend auf der Jenkins-Version, die uns gegeben wurde.
Wir erlauben uns an dieser Stelle etwas Stolz: Unsere Arbeit war erfolgreich, Jenkins tut, was es tun soll. Mit dem Hinzufügen eines vorbereiteten Git Repository kann Jenkins in unserem Name Space über ArgoCD bereitgestellt werden. Hier mein Repository, ich kann mich innerhalb von fünf Minuten in Jenkins unter myjenkins.mynamespace.mycompany.com anmelden. Mit Admin-Rechten. Und all meine vordefinierten Pipelines und Jobs und Quellen sind eingerichtet.
Bei ähnlichem Bedarf helfen wir gerne dabei, die zwei unterschiedlichen Automatisierungslösungen unter ein Dach zu bringen – dann müssen User nur noch loslegen.
Weiterführendes zu diesem Thema können Sie im Artikel meiner Kollegen Jan Bundesmann und Pascal Fries auf heise.de erfahren (Paywall).
Gergely Szalay
Neueste Artikel von Gergely Szalay (alle ansehen)
- New Adventures in ArgoCD: Automatisieren des Automatisierens - 13. Juni 2023
- Git zieht um - 20. Dezember 2022
- Kubeflow at Home: KI und Kubernetes außerhalb von Google & Co - 25. Januar 2022
