© FocalPoint/Shutterstock.com
Entwickler Magazin
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?

Daniel Bornkessel, Anja Kammer, Jörg Müller


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 ...

Entwickler Magazin
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?

Daniel Bornkessel, Anja Kammer, Jörg Müller


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 ...

Neugierig geworden?


   
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang