Jenkins X integriert Kubernetes
Das Open-Source-Projekt verbindet das CI/CD-Werkzeug Jenkins mit Docker und Kubernetes. Es automatisiert den Build-Prozess und die Verteilung in ein Container-Cluster.
- Rainald Menge-Sonnentag
Das Team hinter Jenkins, einem Open-Source-Werkzeug für Continuous Integration und Continuous Delivery (CI/CD), hat ein neues Projekt mit dem Namen Jenkins X angekündigt, das sich bereits seit einigen Monaten in der Planung befindet. Es soll die Verbindung zwischen CI/CD und der Cloud vereinfachen. Dazu automatisiert es den Prozess der Containerisierung und Verteilung über Kubernetes.
Aufgrund der Plug-in-Architektur lässt sich Jenkins zwar bereits an Kubernetes anbinden, aber Jenkins X automatisiert die Integration. Entwickler legen in der Konfiguration die Zielplattform fest und müssen sich nicht um die einzelnen Zwischenschritte wie passende Docker-Images und YAML-Konfigurationen für Kubernetes kümmern.
Projekte und ihre Konfigurationen
(Bild: Jenkins)
Entwickler können mit jx import vorhandene Projekte importieren. Der Befehl automatisiert das Erstellen eines Git-Repositories bei Dienstleistern wie GitHub und erzeugt ein Dockerfile für das Docker Image, ein Helm Chart für den Kubernetes-Paketmanager sowie ein Jenkinsfile mit der Pipeline für den CI/CD-Prozess über Jenkins. Die ersten beiden Schritte lassen sich durch Angabe des Parameters --no-draft unterbinden. Zum Erstellen neuer Projekte dient der Befehl jx create. Eine Anleitung zeigt anhand eines Beispiels, wie Entwickler ein Spring-Boot-Projekt anlegen.
Die Konfigurationen in Form der Jenkinsfile, Dockerfile und Helm Charts legt das Werkzeug im Git-Repository ab, und Entwickler können sie ihren Bedürfnissen anpassen und so beispielsweise individuelle Tests in die CI/CD-Pipeline einbinden. Für den Build-Prozess kommen unterschiedliche Umgebungen (Environments) zum Einsatz. Standardmäßig gibt es Staging und Production Environments, aber Teams können ihre eigenen Umgebungen für individuelle Prozesse definieren.
Umgebungen für Staging und Produktion
Die Environments sind voneinander isoliert und haben jeweils einen eigenen Namespace in Kubernetes. Außerdem existiert für jede Umgebung ein Git-Repository zum Verwalten der Konfiguration und einer Liste der Anwendungen mit ihren Versionsnummern. Das Überführen der Merges kann entweder manuell oder automatisiert erfolgen. Standardmäßig ist für die Staging-Phase eine automatische und für die Produktionsphase die manuelle Promotion vorgesehen.
Wenn Entwickler das Projekt mit den Umgebungen aufgesetzt haben, startet jeder Pull Request die Continuous-Integration-Pipeline, um die Anwendung zu bauen und die angegebenen Tests durchzuführen. Anschließend verteilt das Tool die Anwendung in eine Preview-Umgebung.
Beim Merge eines Pull Request auf den Master Branch erzeugt Jenkins X eine neue semantische Versionsnummer und passt den Sourcecode entsprechend an. Anschließend erstellt es die passenden Artefakte wie Docker-Images und Helm Chart, um schließlich die neue Version auf das passende Environment zu verteilen.
Weitere Details lassen sich dem Blogbeitrag entnehmen. Derzeit ist Jenkins X als separates Projekt auf GitHub zu finden. Technisch baut es direkt auf Jenkins, das die CI/CD-Engine bildet. Das Team schlägt vor, Jenkins X als ein Unterprojekt einzubinden. (rme)
