© FocalPoint/Shutterstock.com
CI/CD-Systeme für Kubernetes unter die Lupe genommen

Kubernetes und seine CI/CD-Generationen


Der neue Kubernetes-Cluster ist eingerichtet, die Softwarearchitektur ist ganz modern auf Basis von Microservices geplant, jetzt fehlt nur noch eine Continuous Integration oder Continuous Delivery (CI/CD) Pipeline. Diese ist schnell mit dem Jenkins gebaut, der schließlich schon seit Jahren einen guten Dienst verrichtet. Alles nur noch eine Kleinigkeit, oder? Aber ist das eigentlich eine gute Idee?

Die beschriebene Situation kann häufig beobachtet werden: Firmen brechen alte, schwerfällige Monolithen in Microservices auf und deployen diese auf Kubernetes. Dabei wird oft die alte CI/CD-Infrastruktur beibehalten. Diese passt jedoch nicht mehr wirklich zur neuen Realität: Zwar können mit aktuellen Jenkins-Versionen Pipelines beschrieben werden und Unit-Tests können auch in Bamboo ausschließlich in Containern ausgeführt werden – allerdings wurden diese Systeme ursprünglich mit einer komplett anderen Philosophie entwickelt und passen dementsprechend schlecht zu modernen Anforderungen. Eine Anpassung der alten Systeme gestaltet sich müßig: Maven- oder Java-Plug-ins sind unnötig, wenn zum Bauen von Applikationen einfach ein Docker-Container genutzt werden kann. Kubernetes-Deployments können mit Tools wie kubectl oder Helm in einem Container implementiert werden, statt dafür ein Plug-in für das CI/CD-System zu nutzen. Die Anforderungen an Funktionalitäten, die CI/CD-Systeme selbst zur Verfügung stellen müssen, sinken durch den Einsatz von Docker.

Ein weiterer Anachronismus in Zeiten von Configuration as Code ist die Konfiguration der Pipelines über eine grafische Benutzeroberfläche. Eine solche Konfiguration ist mühsam und die Fehlersuche gestaltet sich schwierig. Aktuelle Systeme nutzen deklarative, textuelle Beschreibungen von Pipelines. Diese können einfach in Versionsverwaltungssystemen hinterlegt werden, zusammen mit der eigentlichen Applikation. So konfigurierte Pipelines können schnell wiederhergestellt werden, sollte das CI/CD-System neu aufgesetzt werden. Die Benutzeroberflächen moderner Systeme bieten nur noch eine Sicht auf den Zustand von Pipelines und ermöglichen das manuelle Starten einzelner Schritte. Ganz neue Lösungen verzichten nicht nur auf das Konzept der Plug-ins, sondern versuchen noch mehr Kernfunktionalitäten von CI/CD-Systemen auszulagern. Kubernetes löst beispielsweise viele Aufgaben, die ehemals von jedem CI/CD-System selbst implementiert wurden. Dazu gehören zum Beispiel das Starten, Stoppen und Verwalten von Containern. Seit der Einführung des ersten populären CI-Systems CruiseControl im Jahr 2001 hat sich CI/CD mehrmals neu erfunden. Die neueste Generation von Systemen ist gerade dabei, Produktionsreife zu erlangen.

Drei Generationen von CI/CD-Systemen

Erste Generation: CI als Idee ist mit der agilen Bewegung Anfang der 2000er-Jahre populär geworden. In diesem Zusammenhang entstanden erste Tools wie CruiseControl. Anfangs waren diese Systeme noch recht einfach, entwickelten sich aber schnell zu sehr umfangreichen Lösungen weiter. Zu dieser ersten Generation von Systemen gehören Jenkins, Bamboo und TeamCity von JetBrains. Ein wesentliches Merkmal dieser Systeme ist, dass sie sämtliche Funktionalität selbst implementieren. Sie unterstützen Build-Tools verschiedener Programmiersprachen durch Plug-ins. Um Lasten zu verteilen, unterstützen viele Lösungen die Verteilung auf mehrere Hosts. Auf diesen laufen Agents, die jeweils bestimmte Schritte in einer Pipeline ausführen können. Das Managen ganzer Cluster, auf denen solche Agents laufen, ist oft Teil des CI/CD-Systems. Agents können spezifisch konfiguriert werden, um auch exotische Anforderungen zu erfüllen. Um diese Features zu bedienen, sind sehr umfangreiche und komplexe Weboberflächen nötig. Mit dem Aufkommen von Continuous Delivery wurde noch die Fähigkeit zur Verwaltung von Pipelines in die Tools eingebaut. Die erste Generation bietet also einen großen Funktionsumfang, ohne große Anforderungen an ihr Umfeld zu stellen. Dafür zahlt man allerdings einen hohen Preis: zunehmende Komplexität. Häufig muss deshalb die Konfiguration von einem Experten oder Expertenteam gepflegt werden.

Zweite Generation: Die Systeme der zweiten Generation entstanden unter anderem aus dem Wunsch, diese Komplexität zu verringern. Zwei technologische Trends halfen dabei, diesen Wunsch zu erfüllen. Mit Software as a Service (SaaS) wurde es möglich, den Betrieb und damit auch die Komplexität eines CI/CD-Systems vom Entwicklungsteam fernzuhalten. Dieses kann sich auf die Entwicklung von Software konzentrieren und beschreibt die Schritte zum Bauen der Software in einer Konfigurationsdatei. Die wird von einem System gelesen, interpretiert und in ein ausführbares Skript übersetzt, das anschließend ausgeführt wird. Die Strategie wird Configuration as Code genannt und ist eine zentrale Eigenschaft der zweiten Generation. Neu ist auch, dass das CI/CD-System nicht auf der firmeneigenen Infrastruktur betrieben werden muss. Travis CI [1] hat diese Philosophie für GitHub populär gemacht.

Der zweite große Trend bei diesen Systemen ist die konsequente Nutzung von Docker-Containern zum Bauen und Testen der Software. Dadurch wird das CI/CD-System nur noch zum Orchestrator; weder müssen Build-Umgebungen verwaltet, noch Technologien verschiedener Programmiersprachen direkt unterstützt werden.

Die Kombination dieser beiden Ansätze findet man in sehr vielen der aktuellen CI/CD-Systeme. Typische Vertreter der zweiten Generation sind Travis CI, Gitlab CI, Codeship und die Build-Systeme großer Cloudanbieter wie AWS, Google oder Azure. Einige dieser Systeme werden nicht nur als SaaS-Lösung angeboten, sondern können auch in der eigenen Infrastruktur betrieben werden. Auch diese Generation implementiert das Management der Build-Cluster durch Agenten oft selbst. Einige Systeme, wie zum Beispiel Gitlab CI, können bereits Agenten in Kubernetes-Clustern betreiben.

Dritte Generation: Die dritte Generation von CI/CD-Systemen ist noch stärker auf Kernfunktionalität reduziert und setzt konsequent auf Kubernetes als Laufzeitumgebung. Sie werden deshalb auch als Kubernetes-nativ bezeichnet. Oft gehen sie bei dieser Fokussierung noch weiter und setzen n...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Gewinner-Teams

Wir bieten Lizenz-Lösungen für Teams jeder Größe: Finden Sie heraus, welche Lösung am besten zu Ihnen passt.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang