© Liudmila Chernetska / 123RF.com

PipeCD will ArgoCD den Rang als CI/CD-Dirigent für Kubernetes ablaufen. Was PipeCD ausmacht, wie es im Detail funktioniert und womit ArgoCD-Umsteiger rechnen müssen, verrät dieser Artikel.

Linux-Container haben in den vergangenen Jahren in vielerlei Hinsicht die Art und Weise revolutioniert, mit der Entwickler und Administratoren Anwendungen ausrollen und betreiben. Im Schlepptau haben sie dabei meist Kubernetes. Im Grunde bildet es ein Rechenzentrum virtuell ab und stellt Funktionen wie Netz und Speicher dynamisch zur Verfügung. So lassen sich durch eine Flotte von Systemen betrieben Workloads orchestrieren.

Doch Kubernetes geht mit hoher Komplexität Hand in Hand. Schon die Sinfonie aus Pods, Services, Namespaces und Volumes treibt manchen K8s-Neuling in den Wahnsinn. Kommen dann noch Custom Resource Definitions und schier endlose YAML-Dateien hinzu, erreicht das Frustrationsniveau einen vorläufigen Höhepunkt.

Helferlein unterstützen

Ein Beispiel verdeutlicht schnell, worum es geht: Um einen Container mit einer Anwendung in einen Pod zu verpacken, ihn mit einem persistenten Speicherlaufwerk auszustatten und ihn von außen erreichbar zu machen, benötigen Sie mindestens vier eigenständige Kubernetes-Ressourcen. Das weiß man als sattelfester K8s-Jockey, aber noch nicht, wenn die eigene Reise in Sachen Container-Orchestrierung gerade erst begonnen hat.

Immerhin bieten sich unterschiedliche Werkzeuge an, die Neulingen wie erfahrenen Administratoren das Leben erleichtern. Paketmanager wie Helm sind dafür ebenso ein Beispiel wie ArgoCD [1]. Letzteres verspricht nicht nur, Anwendungen in Kubernetes auszurollen, sondern liefert obendrein ein umfassendes Lifecycle-Management mit. Continuous Integration, Continuous Development – zwei Schlagwörter, die im schnelllebigen Container-Kontext ohnehin Hochkonjunktur haben, und die ArgoCD (Abbildung 1) perfekt bedienen will.

Abbildung 1: ArgoCD gilt als Standardlösung für CI/CD mit Kubernetes, die aber bei vielen Entwicklern unbeliebt ist. PipeCD präsentiert sich als Alternative. Quelle: ArgoCD / ASL 2.0

Doch ArgoCD hat innerhalb der Community nicht nur Freunde. Kritiker lasten dem Werkzeug eine lange Mängelliste an. Ein zentraler Punkt ist dabei, wie ArgoCD den Paketmanager Helm benutzt. Auch der gilt in der Kubernetes-Szene als ein absolutes Standardwerkzeug. Er funktioniert im Prinzip für Container so wie RPM oder Dpkg für Linux-Pakete: Helm-Charts enthalten neben den Anweisungen, um einen Container in einer Plattform auszurollen, dessen Konfigurationsdaten sowie benötigtes Beiwerk. Das erlaubt es, Anwendungen in einem beliebigen K8s-Cluster unter Zuhilfenahme von Helm in kürzester Zeit auszurollen.

ArgoCD macht sich diese Funktion zwar zunutze, kann aber wegen seiner eigenen Architektur verschiedene Funktionen von Helm gar nicht anwenden. Durch seine Abläufe sorgt es beispielsweise dafür, dass die Rollback-Funktionen von Helm weitgehend brachliegen. Sie dienen eigentlich als Notbehelf, falls bei einem Update per Helm etwas schiefgeht. In ArgoCD aber lassen sie sich gar nicht einsetzen, weil die CI/CD-Lösung glaubt, es besser zu können.

Komplexität

Ein weiterer Kritikpunkt an ArgoCD ist, dass das Werkzeug mittlerweile selbst äußerst komplex ist. DeployKF [2], das dazu dient, die KI-Verwaltung Kubeflow [3] mittels ArgoCD auszurollen, belegt das eindrucksvoll. Denn deployKF besteht selbst aus Hunderttausenden Zeilen Code.

Zugegeben, bei Kubeflow handelt es sich um ein komplexes Ungetüm, das etliche Dienste miteinander kombiniert. Inwiefern es eine Erleichterung sein soll, Kubeflow mittels deployKF auszurollen, wenn das fast noch schwieriger zu erlernen ist, als Kubeflow zu Fuß zu installieren, bleibt jedoch schleierhaft.

Zudem ist ArgoCD nur auf Kubernetes zugeschnitten: Alle Funktionen der Lösung kreisen um K8s herum, andere Deployment-Ziele unterstützt ArgoCD nicht. Administratoren brauchen deshalb zusätzliche Werkzeuge, wenn sie Workloads nicht nur in K8s ausrollen wollen, sondern zum Beispiel auch in AWS [4] oder in Amazons Kubernetes-Dienst Elastic Kubernetes Service (EKS) [5]. Außer mit ArgoCD hantiert der Admin oder Entwickler also mindestens noch mit einem weiteren Tool, beispielsweise mit Terraform.

PipeCD

Längst gibt es Alternativen zu ArgoCD. Zu einiger Bekanntheit ist FluxCD [6] gelangt, das deutlich schlanker als ArgoCD daherkommt, es in Sachen Funktionalität aber problemlos mit diesem aufnehmen kann. Zentrale Punkte wie die Möglichkeit, auch andere Plattformen als Kubernetes zu bespielen, fehlen in FluxCD allerdings ebenfalls.

Gerade in den vergangenen Monaten hat sich deshalb PipeCD [7] einen Namen gemacht. Die Software nimmt für sich in Anspruch, Pipelines für Continuous Integration und Continuous Development anzubieten, zum Teil mit deutlich größerem Funktionsumfang als die Konkurrenz, und dabei trotzdem leichtgewichtig und einfach zu bedienen zu sein.

Architektur

Auf den ersten Blick wirkt die PipeCD-Architektur (Abbildung 2) sogar etwas komplizierter als die von ArgoCD. Letzteres begnügt sich mit drei internen Komponenten. PipeCD dagegen fällt ein wenig umfangreicher aus: Außer aus der zentralen Intelligenz, dem PipeCD-Daemon, besteht die PipeCD-Control-Plane auch aus einem Data Store, einem File Store, einem Cache sowie einem Management-Interface namens pipecd-ops.

Abbildung 2: Die PipeCD-Architektur ist übersichtlich, zentrale Komponenten sind die Controlplane mit MySQL und Redis, der PipeCD-Daemon selbst sowie Piped-Instanzen, die Workloads ausführen. Quelle: PipeCD  / ASL 2.0

Den Datenspeicher implementiert PipeCD nicht selbst. Stattdessen setzt es für das Ablegen der eigenen Metadaten auf MySQL und für das Ablegen von Dateien auf einen S3-Speicher. Auf Wunsch rollt es MySQL und MinIO für S3 außerdem selbst aus. Generell ist das Setup von PipeCD in einem Kubernetes-Cluster gut zu meistern, da die Entwickler fertige Templates für Kubernetes mitliefern. Mittels »kubectl apply« lassen sie sich leicht anwenden. Im Anschluss läuft im Cluster bereits das Gros der für PipeCD notwendigen Dienste.

Allerdings braucht es noch eine Instanz von »piped«. Sie ist nicht mit dem PipeCD-Daemon selbst zu verwechseln. Stattdessen handelt es sich um eine Art Agent, der darauf wartet, dass PipeCD ihm Aufgaben zuteilt, die er daraufhin abarbeitet. Im Kubernetes-Kontext ergeben sich daraus interessante Effekte. Zunächst rollt der Administrator üblicherweise nur die Hauptdienste von PipeCD aus, nicht jedoch die Piped-Instanzen für die eigenen Entwickler. Darum müssen sie sich selbst kümmern.

Darüber hinaus führt die Architektur von PipeCD dazu, dass Piped-Instanzen nicht zwangsweise Kubernetes-spezifisch sein müssen. Ein zentrales Argument der PipeCD-Entwickler für ihre Lösung lautet dementsprechend, dass PipeCD anders als ArgoCD nicht Kubernetes-spezifisch ist. Stattdessen lässt sich Piped auch in einer virtuellen Instanz in der Google Compute Platform installieren oder als eigenständiger Dienst in einer klassischen virtuellen Maschine (VM) betreiben.

Terraform unterstützt das Werkzeug ebenfalls, wodurch sich die Auswahl möglicher Zielplattformen weiter vergrößert. Denn durch PipeCD hindurch wird so zudem ein Deployment in AWS möglich, bis hinunter auf Spezialressourcen wie EKS. Wo ArgoCD also lediglich die Kommunikation mit Kubernetes beherrscht, gibt sich PipeCD deutlich vielseitiger.

GitlessOps und GitOps

Ein weiterer zentraler Unterschied zwischen ArgoCD und PipeCD besteht darin, dass PipeCD explizit für die Nutzung von GitOps- und GitlessOps-Szenarien vorgesehen ist. Unter dem Begriff GitOps hat sich in der agilen IT der Grundsatz etabliert, den Entwicklungsstand einzelner Anwendungen oder Umgebungen in Git zu pflegen und direkt aus Git heraus automatisiert auszurollen. Ändert ein Entwickler oder Administrator etwas im Git, reagiert das genutzte CI-System und passt das laufende Deployment automatisch und mit möglichst geringer Service-Unterbrechung an. Danach ist die laufende Version der Software samt Konfiguration wieder identisch mit den im Git hinterlegten Daten.

ArgoCD jedoch funktioniert im Hinblick auf die Integration von Git-Verzeichnissen relativ statisch. Ein einzelner Dienst kümmert sich darum, dass Änderungen in angeschlossenen Git-Verzeichnissen nicht unbemerkt bleiben. Änderungen am Deployment nimmt innerhalb von ArgoCD aber eine andere Komponente vor, die der ausführende Administrator oder Entwickler separat bedienen muss.

PipeCD zeigt sich hier universeller: Ein einmal angeschlossenes Git-Verzeichnis überwacht der PipeCD-Daemon selbst. Änderungen führen dazu, dass sich implizit die für das jeweilige Verzeichnis definierte Pipeline in Gang setzt und die nötigen Änderungen ihren Weg in die Produktion finden.

Dabei beherrscht PipeCD nicht nur GitOps [8], sondern auch GitlessOps [9]. Zunächst wirkt das wie Haarspalterei, denn GitlessOps und GitOps unterscheidet vor allem, dass letzteres nicht unmittelbar auf das ursprüngliche Git-Verzeichnis zurückgreift, sondern ausschließlich auf Artefakte, die sich aus Änderungen im Git ergeben – zum Beispiel aktualisierte Container-Abbilder. Im täglichen Handling ist das aber aus Sicht von Administratoren und Entwicklern eine gewaltige Differenz.

Möchten Sie eine Lösung wie ArgoCD an ein Git-Verzeichnis anschließen, müssen sie zwangsläufig mit Credentials und der Benutzerverwaltung der verwendeten Git-Lösung hantieren. Das birgt Sicherheitsrisiken. Zudem benötigen Sie die Git-Integration der genutzten CI/CD-Anwendung, was deren Handhabung verkompliziert. Haben Sie stattdessen die Möglichkeit, beispielsweise aus GitLab oder GitHub heraus bei Änderungen automatisiert neue Artefakte zu erstellen und in ein privates oder öffentliches Verzeichnis hochzuladen, muss CI/CD nur das Artefaktverzeichnis überwachen.

Auf die eigentlichen Git-Verzeichnisse für die Entwicklung benötigt es keinen Zugriff. Sie müssen sich also höchstens mit Zugangsdaten für den Zugriff auf die Artefakte befassen. Eindringlinge gelangen dementsprechend beim erfolgreichen Einbruch nicht bis zum eigentlichen Git-Verzeichnis. Praktischerweise besitzt PipeCD zudem eine eigene Verwaltung für Credentials. Sie tauchen also nirgendwo im Klartext auf, sind über eine Variable aus Pipelines heraus zu referenzieren und liegen sicher in einem internen Tresor in PipeCD.

Aller Anfang

Nachdem Sie die PipeCD-Dienste im Cluster installiert haben, richten Sie zunächst »piped« ein. Dazu müssen Sie den PipeCD-Hauptserver über eine Service-Definition in Kubernetes oder einem passenden Äquivalent – etwa einem Loadbalancer – von außen erreichbar machen. Ab Werk ist ein Beispielprojekt (Abbildung 3) angelegt, das Sie nach Geschmack beliebig erweitern.

Abbildung 3: PipeCD vereinfacht das Ausrollen von Anwendungen und kommt mit einem vorgefertigten Fundus an Beispielen für Blue/Green- und Canary-Deployments daher. Quelle: PipeCD / ASL 2.0

Darüber hinaus ist PipeCD mandantenfähig und beherrscht die Benutzerauthentifizierung mittels LDAP oder Single-Sign-on. Eine PipeCD-Daemon-Instanz kann also problemlos viele Benutzer mit ihren Projekten beherbergen. Jedes Projekt verlangt allerdings eine eigene »piped«-Instanz. Deren Setup fällt vergleichsweise leicht: In der PipeCD-GUI gibt es eine eigene Seite für verfügbare »piped«-Instanzen. Dort legen Sie einen neuen Eintrag an und erhalten eine vorläufige Projekt-ID sowie einen Schlüssel zur Anmeldung von »piped« an PipeCD.

Der folgende Schritt ist etwas komplizierter, da er davon abhängt, wo die Instanz laufen soll. Handelt es sich um Kubernetes, liegt PipeCD zumindest eine fertige Ressourcendefinition bei. Darin ersetzen Sie die Projekt-ID und den Anmeldeschlüssel für »piped« durch die Werte aus dem Webinterface. Danach schließt sich ein »kubectl -f apply« auf die Datei an, und wenig später erscheint die »piped«-Instanz (Abbildung 4) in PipeCD.

Sie lässt sich nun ohne einen weiteren Kommandozeilenausflug verwalten und gegebenenfalls per Mausklick aktualisieren. Möchten Sie die Instanz stattdessen woanders ansiedeln, sind auch die nötigen Schritte andere. Was aber identisch bleibt: In der Zielinstanz müssen Sie die Projekt-ID und den Schlüssel zur Anmeldung von Piped anpassen.

Abbildung 4: Ohne »piped« funktioniert PipeCD nicht, die Lösung macht Setup und Wartung des nötigen Diensts jedoch leicht. Quelle: PipeCD / ASL 2.0

Sobald ein lauffähiger »piped« existiert, stehen dem Benutzer die meisten PipeCD-Funktionen zur Verfügung: Pipelines lassen sich anlegen, Git-Verzeichnisse in diese integrieren und Deployment-Strategien ausrollen. Alle diese Aufgaben erledigt der Benutzer bei Kubernetes-Setups in Form von Kubernetes-Ressourcendefinitionen.

Klug implementiert

Jetzt beginnt die eigentliche Arbeit mit PipeCD. Dabei legen die PipeCD-Entwickler großen Wert darauf, möglichst viele Optionen zu eröffnen. In der Dokumentation ist beispielsweise ausgiebig die Rede von Blue/Green Deployments und Canary Deployments. Wer selbst nicht regelmäßig Anwendungen entwickelt, fängt mit derlei Begriffen wenig an, doch später dazu mehr. Für den Moment genügt es zu wissen, dass beide Begriffe sich auf die Art und Weise beziehen, wie eine CI/CD-Lösung aktualisierte Konfigurationen und aktualisierte Anwendungen ausrollt. Blue/Green Deployments und Canary Deployments [10] stehen dabei für zwei unterschiedliche Ansätze.

Die meisten Administratoren dürften am eigenen Leibe erfahren haben, dass beim Update von Software mitunter einiges schiefläuft. Klassische Deployment-Ansätze basieren auf Long-Time-Support-Software und gehen davon aus, dass sich die produktive Umgebung im laufenden Betrieb praktisch gar nicht verändert. Updates gibt es ausschließlich im Rahmen von lange angekündigten Downtimes, während derer der Dienst gar nicht zur Verfügung steht.

Bevor ein Softwareupdate im Rahmen eines solchen Wartungsfensters erfolgt, testet das entwickelnde Unternehmen die neue Version eines Werkzeugs auf Herz und Nieren. Das Modell hat sich in den vergangenen Jahren allerdings als nur bedingt funktionstüchtig erwiesen. Es verlangsamt die Entwicklung massiv. Außerdem führen große, monolithische Updates dazu, dass sich Fehler und Bugs nicht sofort einer eindeutigen Ursache zuordnen lassen. Daran ändert alles Testen nichts – stellt sich nach dem Einspielen eines großen Updates heraus, dass eine elementare Funktion nicht mehr korrekt arbeitet, startet mindestens eine hektische Fehlersuche. Schlimmstenfalls steht der Rollback auf die alte Version auf dem Programm. Oft genug ist der jedoch ein Ding der Unmöglichkeit.

Die agile Softwareentwicklung hat deswegen das Motto “Release early, release often” zum obersten Prinzip erhoben. Wer neue Versionen seiner Software mit kleinen Änderungen inkrementell freigibt, merkt schnell, wenn etwas nicht funktioniert, und greift dann sofort ein. Der Nachteil: Die Produktion verändert sich kontinuierlich. CI/CD-Werkzeuge dienen vor allem dazu, die Änderungen zu verwalten und zu vereinfachen.

Blau, Grün, Kanarienvögel

Hier kommen nun die beiden erwähnten Deployment-Ansätze ins Spiel. Bei Deployments nach dem Blue/Green-Prinzip laufen im Grunde ständig zwei Versionen einer Umgebung. Einerseits die aktuell produktive Umgebung und andererseits die neuere Version, die Entwickler und Admins gerade vorbereiten.

PipeCD unterstützt das Deployment-Szenario ab Werk. Sind alle Arbeiten und die erforderlichen Tests abgeschlossen, schaltet man in PipeCD die neue Version in den Live-Betrieb und behält die alte Version als Fallback. Das klappt auch dank der Flexibilität, die Kubernetes bietet, mit wenigen Kommandozeilenbefehlen.

Entpuppt sich die neue Version der Software als fehlerfrei, ersetzt der zuständige Entwickler die bisherige Umgebung durch einen Klon der dann produktiven Anwendung. Gleichzeitig hat er eine neue Grundlage für weitere Entwicklungen. Läuft etwas noch nicht wunschgemäß, ist der Rollback (Abbildung 5) schnell initiiert.

Abbildung 5: Rolle rückwärts: Geht ein Deployment schief, kann PipeCD auf Wunsch automatisch einen Rollback auf eine bekanntermaßen funktionierende Version vornehmen. Quelle: PipeCD / ASL 2.0

Canary-Deployments funktionieren nach einem anderen Schema. Zwar laufen ebenfalls zwei Versionen der Software, die alte und die neue, aber parallel im Live-Betrieb. Über die Werkzeuge der beherbergenden Plattform gibt der Entwickler vor, dass die neuen Features nur bei einem kleinen Teil der Benutzer ankommen. Sie sind die Kanarienvögel, quasi eine Art unfreiwilliges Versuchskaninchen. Treten Fehler oder Probleme auf, so die Annahme, wird sich einer der Canary-Nutzer beschweren. Dann wäre das Problem durch ein Update der Canary-Version zu beheben. Das wiederholt sich so lange, bis die neue Version für die Canary-Anwender perfekt funktioniert.

Anschließend erfolgt die Umstellung, sodass alle Benutzer die neue Version ausgerollt bekommen. Sofern keine weiteren Probleme mehr auftauchen, steht die Dekommissionierung der alten Umgebung an, und der Zyklus beginnt von vorn. Kommt es nach der Umstellung doch zu Schwierigkeiten, rollt man zurück, und die Verbesserungen werden erneut zunächst für eine Canary-Gruppe umgesetzt.

Keiner der beiden Ansätze lässt sich als pauschal besser oder schlechter als der andere bezeichnen. Eine große Rolle spielen dabei die persönlichen Vorlieben der Admins und Entwickler. PipeCD-Sicht unterstützt, wie erwähnt, beide Modelle vollumfänglich. Es genügt, in PipeCD die Pipeline für eine Anwendung mit den entsprechenden Parametern zu versehen. Den Rest regelt PipeCD ausgehend von den angeschlossenen »piped«-Instanzen automatisch.

Wissen, was los ist

Ganz gleich, ob sich ein Entwickler für Blue/Green-Deployments oder für den Canary-Ansatz entscheidet: Er muss die neue Version einer Software nach dem Rollout penibel überwachen. In einer CI/CD-Umgebung geht das nur, wenn das Monitoring eng mit dem eigentlichen Deployment-Werkzeug verzahnt ist. Den PipeCD-Entwicklern ist das klar, weswegen sie ihre Lösung ab Werk mit Trending- und Analyse-Werkzeugen ausgestattet haben. Sie decken nahezu jeden Aspekt der Themen Monitoring, Alerting und Trending ab.

Handelt es sich beispielsweise um Anwendungen mit ReST-Schnittstelle, überwacht PipeCD bei entsprechender Anweisung eingehende wie ausgehende Anfragen, misst deren Dauer von Anfang bis Ende und zeichnet ihren Umfang auf. Würde nach dem Deployment einer neuen Version einer Anwendung die Zeit pro Request massiv ansteigen, sähe der Entwickler das in PipeCD sofort.

@L.Auch die Verfügbarkeit der mit PipeCD ausgerollten Dienste beobachtet die Software minutiös. Ist ein Dienst nach einem Update offline, schlägt PipeCD Alarm. Darüber hinaus trägt es die Logmeldungen eines Deployments zusammen. Dazu bezieht es sie beispielsweise aus den Kubernetes-Logs der jeweiligen Pods. Weil Anwendungen in Kubernetes-Containern üblicherweise nach stdout oder stderr loggen, tauchen die Meldungen in den Logs der Container auf und durch das Log Harvesting von PipeCD letztlich ebenfalls in dessen GUI.

Innerhalb derer finden sich diese Details komfortabel stets pro Deployment und an einer Stelle. Der Zustand einer Anwendung lässt sich so praktisch in Echtzeit visualisieren. Dazu greift PipeCD auch auf die Monitoring-Daten zurück, die es auf Basis der konfigurierten Pipelines automatisch sammelt. Will der Administrator das Spiel auf die Spitze treiben, kann er in PipeCD sogar Kriterien anhand der gesammelten Metrikdaten für einen automatischen Rollback definieren.

Artefakte bauen

Wie erwähnt, versteht sich PipeCD auch als Lösung für GitlessOps. Dazu passt, dass sich direkt aus der Anwendung heraus Artefakte, also das Ergebnis eines automatisierten Build- oder CI/CD-Prozesses, in eine Pipeline integrieren lassen. Wer möchte, kann mit Git-Verzeichnissen arbeiten – oder nutzt in der Definition der eigenen Pipeline vor allem Artefakte. Das verlagert einen Teil der anstehenden Arbeit an eine andere Stelle und außerhalb des Einflussbereichs von PipeCD.

Wer Artefakte zum Beispiel direkt aus GitLab oder GitHub heraus baut, muss dort eigene CI/CD-Pipelines einrichten. Der Mühe Lohn sind aber eine zuverlässige Trennung von Git-Commits und der produktiv laufenden Software, eine deutliche höhere Plattformsicherheit durch Wegfall der Querverstrebung zwischen Git und Deployment-Plattform und eine klarere Trennung der Verantwortlichkeiten der einzelnen Dienste.

Fazit: Valide Alternative

ArgoCD gilt heute als Standard-Lösung für CI/CD mit Kubernetes. Platzhirsch zu sein, heißt aber eben nicht automatisch, die besten Lösungen für die gängigen Probleme der Entwicklung von Container-Anwendungen zu bieten. Wer sich mit dem De-facto-Standard nicht so recht anfreunden kann, findet in PipeCD eine valide Alternative. Vieles spricht dafür: Das Werkzeug kommt deutlich schlanker und mit weniger Overhead daher als ArgoCD. An zahlreichen Stellen nutzt und kombiniert es Tools, statt einen Teil ihrer Funktionalitäten durch eigenes Bastelwerk zu demolieren.

PipeCD eignet sich hervorragend für Workloads, die auf Sicherheit, umfassende Metrikdaten und die Wahl zwischen GitOps und GitlessOps setzen. Anders als die Konkurrenten ArgoCD und Flux unterstützt es außerdem andere Zielplattformen als Kubernetes, obgleich letzteres die gewohnte Umgebung für PipeCD sein und bleiben dürfte. In Sachen Multifunktionalität schlägt es die unmittelbare Konkurrenz damit um Längen. Wer dabei ist, eine CI/CD-Umgebung zu planen oder umzusetzen, sollte PipeCD als Alternative zu ArgoCD und Co. jedenfalls auf dem Schirm haben. (jcb/csi)