Mit Serverless Jenkins X starten

In diesem Beitrag schaue ich mir die Version von Jenkins X mit Tekton genauer an, um euch einen Eindruck davon zu vermitteln, wie der allgemeine Ablauf für Entwicklung, Build, Test und Deployment mit Jenkins X aussieht. Wie fühlt es sich an, euren Code mit einem Produkt aus der Jenkins-Community in Produktion zu bringen, in dem kaum Jenkins steckt?

Voraussichtliche Zeit, um alle Schritte dieser Anleitung durchzugehen: 60–90 Minuten. Lesezeit: 15 Minuten.

Zu den einzelnen Abschnitten dieses Blogs:

• Über Jenkins X und Tekton

• Benötigte Tools

• Jenkins X einrichten

• Eine neue Anwendung erstellen

• Einen Tunnel erstellen und Webhooks aktualisieren

• Die bisherige Einrichtung verstehen

• Eine kleine Funktion implementieren und deployen

• Abschließende Gedanken

Über Jenkins X und Tekton

Das Jenkins-X-Projekt gibt es seit fast zwei Jahren. Etwa einen Monat nach seinem ersten Geburtstag veröffentlichte das Team die neue Jenkins X Pipeline Engine auf Basis von Tekton.

Jenkins X ist im Grunde der coolere Cousin von Jenkins: eine lang erwartete Cloud Native-Alternative aus der Jenkins-Community. Es verfolgt einen klaren Ansatz und ist stark von den im Buch „Accelerate“ beschriebenen Praktiken inspiriert – DevOps-Praktiken, die nachweislich die Leistungsfähigkeit von Softwareunternehmen nachhaltig steigern.

Je nachdem, welche Version ihr bei der Installation auf einem Kubernetes-Cluster auswählt, verwendet ihr entweder die Version mit einem statischen Jenkins Master oder die neuen serverlosen Jenkins X Pipelines, die Tekton anstelle von „Jenkins als zugrunde liegende CI/CD-Engine nutzen, um eine moderne, hochverfügbare Cloud Native-Architektur bereitzustellen“

Im Wesentlichen ist Tekton eine Sammlung von Kubernetes Custom Resource Definitions (CRDs), mit denen sich CI/CD-Pipelines in Kubernetes deklarieren lassen. Mehr dazu erfahrt ihr in der offiziellen Dokumentation. Dieses Wissen ist jedoch keine Voraussetzung, um diesem Beitrag folgen zu können.

Benötigte Tools

• Jenkins X, Option „Serverless Jenkins X Pipelines with Tekton“

• Tekton

• Minikube

• Ngrok

• GitHub

Jenkins X einrichten

Hinweis: Die standardmäßige Jenkins-X-Einrichtung, der wir in diesem Beitrag folgen, erfordert ein GitHub-Konto. Es wird verwendet, um einige Repositories zu erstellen – eines für jede Umgebung sowie eines für das Entwicklungsprojekt – und Webhooks von ihnen zu den Tekton-Ressourcen einzurichten, die im lokalen Kubernetes-Cluster laufen.

Der erste Schritt besteht darin, die Jenkins X CLI auf eurem lokalen Rechner zu installieren. Je nachdem, welches Betriebssystem ihr verwendet, gibt es dafür mehrere Möglichkeiten. Da ich macOS nutze und brew installiert habe, werde ich dafür brew verwenden:

brew tap jenkins-x/jx brew install jx

Nachdem jx installiert ist, installieren wir Jenkins X in einem Kubernetes-Cluster. Wenn ihr keinen ungenutzten Kubernetes-Cluster zur Hand habt, bleibt entspannt und verwendet Minikube – eine einfache Alternative, die einen Kubernetes-Cluster mit einem einzelnen Node auf eurem Computer ausführt. Glücklicherweise bietet Jenkins X einen speziellen Befehl für die Installation in Minikube. Er installiert sogar Minikube und alle Abhängigkeiten, falls ihr sie noch nicht habt.

Zum Zeitpunkt der Erstellung dieses Artikels ist Kubernetes 1.16 gerade erschienen. Offenbar verwenden die von Jenkins X genutzten Deployment-Ressourcen die nicht unterstützte API-Gruppe extensions/v1beta1. Daher empfehle ich, die zu installierende Kubernetes-Version explizit anzugeben, bis dieses Problem behoben ist:

jx create cluster minikube --kubernetes-version=v1.15.4

Wenn jx nach Arbeitsspeicher, CPU und Festplattengröße fragt, empfehle ich außerdem die folgenden Einstellungen statt der Standardwerte, damit ausreichend Ressourcen für alles vorhanden sind:

? memory (MB) 8192 ? cpu (cores) 6 ? disk-size (MB) 150GB ? Select driver: hyperkit

Wählt Serverless Jenkins X Pipelines with Tekton, wenn ihr einen Jenkins-Installationstyp auswählen sollt. Im weiteren Verlauf müsst ihr in eurem GitHub-Account einen API-Token einrichten und ihn bei der Installation angeben. Der Installationsprozess kann etwas dauern, da viele Docker-Images heruntergeladen werden müssen. Daher empfehle ich, die Installation über eine schnelle Internetverbindung durchzuführen.

Hinweis: Wenn ihr Hyperkit verwendet und beim Ausführen des obigen Befehls mit einem VPN verbunden seid, schlägt der Vorgang aufgrund eines erneut aufgetretenen Bugs in Minikube höchstwahrscheinlich fehl. Trennt die VPN-Verbindung und versucht es erneut (löscht den Minikube-Cluster, .minikube und .jx), dann sollte alles problemlos funktionieren. —

Wenn ihr eine Ausgabe wie die folgende seht, wurde die Einrichtung erfolgreich abgeschlossen und Jenkins X läuft in eurem lokalen Cluster:

Jenkins X installation completed successfully	********************************************************	     NOTE: Your admin password is: q0DVn0ylXXEn_MVH5x3-	********************************************************Your Kubernetes context is now set to the namespace: jxTo switch back to your original namespace use: jx namespace defaultOr to use this context/namespace in just one terminal use: jx shellFor help on switching contexts see: https://jenkins-x.io/developing/kube-context/To import existing projects into Jenkins:       jx importTo create a new Spring Boot microservice:       jx create spring -d web -d actuatorTo create a new microservice from a quickstart: jx create quickstartContext "minikube" modified.NAME              HOSTS                                    ADDRESS        PORTS   AGEchartmuseum       chartmuseum.jx.192.168.64.8.nip.io       192.168.64.8   80      92sdeck              deck.jx.192.168.64.8.nip.io              192.168.64.8   80      92sdocker-registry   docker-registry.jx.192.168.64.8.nip.io   192.168.64.8   80      91shook              hook.jx.192.168.64.8.nip.io              192.168.64.8   80      92snexus             nexus.jx.192.168.64.8.nip.io             192.168.64.8   80      91stide              tide.jx.192.168.64.8.nip.io              192.168.64.8   80      92s

Beachtet die Hosts am Ende. Das sind spezielle URLs, die den großartigen Service nip.io nutzen. Er löst DNS-Anfragen in diesem Format grundsätzlich auf die IP-Adresse auf, die in der URL enthalten ist. Im Folgenden bezeichnen wir diese Einträge als Cluster-Ingresses. In meinem Fall ist 192.168.64.8 die lokale IP-Adresse des Minikube-Clusters. Alle diese DNS-Einträge sind als Ingress-Regeln konfiguriert, die auf die einzelnen Services in meinem lokalen Minikube-Cluster verweisen.

Hinweis: In manchen Fällen ist der Service nip.io von eurem Netzwerk aus möglicherweise nicht erreichbar. Dann funktionieren die Domainnamen in den Cluster-Ingresses nicht. Eine mögliche Ursache dafür, dass diese Einträge lokal nicht aufgelöst werden, sind aktivierte DNS-Rebinding-Prüfungen auf eurem Router. Diese verwerfen grundsätzlich alle DNS-Antworten, die private IP-Adressen zurückgeben. Ruft die Deck-URL eurer Installation auf, in meinem Fall http://deck.jx.192.168.64.8.nip.io. Wenn ihr keinen einfachen Login-Dialog seht, funktioniert entweder nip.io bei euch nicht oder es gibt ein Problem mit eurem deck-Pod. Wenn euer Pod fehlerfrei läuft, solltet ihr entweder die Router-Einstellungen prüfen und nach Einstellungen für DNS-Rebinding-Prüfungen suchen oder für alle Hosts aus euren Cluster-Ingresses einen Eintrag in /etc/hosts hinzufügen. Wenn ihr euch für /etc/hosts entscheidet, beachtet, dass im weiteren Verlauf noch weitere Hosts hinzukommen.

Wenn ihr die erstellten Namespaces auflistet, seht ihr höchstwahrscheinlich eine Liste wie diese:

$ k get nsNAME              STATUS   AGEdefault           Active   26mjx                Active   24mjx-production     Active   18mjx-staging        Active   18mkube-node-lease   Active   26mkube-public       Active   26mkube-system       Active   26m

Die Namespaces jx-production und jx-staging entsprechen den Umgebungen production beziehungsweise staging, die Jenkins X standardmäßig erstellt. Während der Installation wurde außerdem in eurem GitHub-Account eine Reihe privater Repositories erstellt, die diesen Umgebungen entsprechen:

Ich gehe etwas später noch genauer auf diese Umgebungen und Repositories ein. Jetzt erstellen wir zunächst ein Projekt zur Entwicklung!

Eine neue Anwendung erstellen

Jenkins X bietet eine breite Auswahl an Anwendungsvorlagen, mit denen ihr einfach loslegen könnt. Falls euch dennoch Vorlagen fehlen, könnt ihr eigene beitragen, indem ihr einen PR erstellt. Für diese Anleitung habe ich react-quickstart gewählt. Mit dem folgenden Befehl könnt ihr das Gleiche tun:

jx create quickstart -f react-quickstart

Ich habe das Projekt react-quickstart-jenkinsx genannt und jx angewiesen, ein Repository in meinem konfigurierten GitHub-Account zu erstellen. Zu diesem Zeitpunkt wurde die erste Pipeline bereits für euch ausgelöst. Ich empfehle euch, euch kurz Zeit zu nehmen und jx get activity -f <repo_name> -w auszuführen. Ersetzt dabei repo_name durch den Namen des Repositories, den ihr beim Befehl jx create quickstart angegeben habt.

Ihr seht alle Schritte, die in der aktuellen Pipeline ausgeführt werden, und bekommt einen Eindruck davon, was Jenkins X automatisch für euch eingerichtet hat. Haltet euch damit aber nicht zu lange auf. Da wir den Cluster lokal ausführen, müssen wir zunächst einige Dinge korrigieren, bevor die Pipeline abgeschlossen werden kann.

Einen Tunnel erstellen und Webhooks aktualisieren

Ihr habt wahrscheinlich Creating GitHub webhook in der Konsolenausgabe gesehen und schnell bemerkt, dass die URL für den Hook auf eine private IP-Adresse verweist. Diese ist von GitHub aus nicht erreichbar. Das bedeutet, dass die Webhooks in euren Repositories derzeit nicht funktionieren. Beheben wir das!

Eine einfache Möglichkeit dafür ist ngrok.io. Erstellt also auf der Website einen kostenlosen Account. Im nächsten Schritt richtet ihr ihn ein:

Folgt den Schritten 1 bis 3. Danach könnt ihr loslegen.

Wir möchten hier einen Tunnel von unserem lokalen Computer zu einer externen URL öffnen – allerdings nicht auf irgendeine Weise. Ngrok soll außerdem einen Host-Rewrite durchführen, weil die Ingress-Regeln in unserem Cluster darauf angewiesen sind, um zwischen den verschiedenen Services zu unterscheiden, auf die wir zugreifen möchten. Das alles lässt sich mit dem folgenden Befehl erledigen. Dabei ist <hook_host> der Hook-Host aus den Cluster-Ingresses:

ngrok http -host-header=rewrite <hook_host>:80

Als Nächstes solltet ihr eine ähnliche Ausgabe wie unten sehen, da der Tunnel nun bereit ist. Beachtet die Einträge unter Forwarding:

Nachdem die externe URL nun erreichbar ist, müssen wir die Webhooks in den GitHub-Repos aktualisieren. Geht dazu in jedem Repo – dem Staging-Repo, dem Produktions-Repo und dem für das Projekt selbst erstellten Repo – auf die Seite Settings -> Webhooks. Bearbeitet den bestehenden Webhook in jedem Repo und ändert das Feld Payload URL, sodass es statt der nip.io-URL die ngrok.io-URL verwendet. Nehmt mein Produktions-Repo als Beispiel:

Klickt unten auf der Seite auf Update webhook. Sobald die Änderung gespeichert ist, klappt den neuesten Eintrag im Bereich Recent Deliveries per Klick auf und löst dann Redeliver aus. Wenn alles geklappt hat, sollte neben der erneut zugestellten Auslieferung ein grüner Haken erscheinen. Stellt nun sicher, dass alle drei Repos den aktualisierten Webhook haben und die jeweils neueste Auslieferung grün markiert ist.

Die bisherige Einrichtung verstehen

Nachdem wir alle Webhooks aktualisiert und erneut zugestellt haben, sollten mehrere Pipelines gestartet sein. Wenn alles gut läuft, zeigt die Ausgabe von jx get activities alle bisher ausgeführten Pipelines und ihre Schritte an.

Dieselben Pipelines könnt ihr über das Prow-Dashboard visualisieren, das über die in den Cluster-Ingresses angezeigte Deck-URL erreichbar ist (bei mir lautet sie http://deck.jx.192.168.64.18.nip.io/). Möglicherweise werdet ihr nach Benutzername und Passwort gefragt: Verwendet admin als Benutzername. Das Passwort wird in der Konsolenausgabe des Befehls jx create cluster angezeigt.

Dies sind alle bisher ausgeführten Pipelines: eine für den master-Branch unseres Projekts, eine für den ersten PR des Staging-Repositories und eine für den master-Branch desselben Repositories. Sicher fragt ihr euch an dieser Stelle, wie all diese Pipelines entstanden sind und was oder wer sie erstellt hat. Das versuche ich im Folgenden zu erklären. Die folgenden Diagramme zeigen stark vereinfacht, was passiert. Im Mittelpunkt stehen dabei die Änderungen an den Repositories und den Namespace-Umgebungen im Cluster.

Einen Cluster mit installiertem Jenkins X erstellt

Wenn wir einen neuen Cluster mit Jenkins X erstellen, erzeugt die CLI alle benötigten Ressourcen. Dazu gehört ein neuer lokaler Cluster mit Minikube und mehreren Namespaces, darunter je einer für die Staging- und die Produktionsumgebung. Zu diesem Zeitpunkt sind beide leer. Weitere Namespaces werden ebenfalls erstellt, hier aber nicht gezeigt. Dazu gehört der Namespace jx, der alle benötigten Tools enthält, damit Jenkins X und Pipelines im Cluster ausgeführt werden können.

jx create cluster erstellt außerdem zwei neue Repositories in GitHub: eines für die Staging-Umgebung und eines für die Produktionsumgebung. Die Repository-Namen werden im folgenden Format generiert: environment-$prefix-$environmentName. Der $prefix wird normalerweise zufällig generiert, ihr könnt ihn jedoch mit dem Argument --default-environment-prefix für den Befehl jx create cluster festlegen.

Bisher wurden keine Pipelines ausgeführt; die gesamte Einrichtung wurde von der CLI vorgenommen.

Eine neue Anwendung mit einem bereitgestellten Quickstart erstellt

Im nächsten Schritt habe ich eine neue Anwendung erstellt, die ich mit Jenkins X entwickeln möchte. Dafür habe ich eine der Quickstart-Vorlagen verwendet, um eine neue ReactJS-Anwendung zu erstellen. Auch das erfolgt über die Jenkins-X-CLI.

1. Lokal wird ein neues Repository erstellt und in den konfigurierten GitHub-Account gepusht. Der Inhalt des Repositories basiert auf den Dateien der Quickstart-Vorlage (jeder Quickstart ist ein Repository in diesem Projekt) sowie auf dem Build Pack, das zu den im Projekt verwendeten Technologien passt. Für dieses Projekt wurde das javascriptBuild Pack ausgewählt. Es kopiert einige seiner Dateien, etwa das Dockerfile, in das Projekt, um den ersten Commit zu erstellen. Das Dockerfile wird verwendet, um die Anwendung in allen Umgebungen auszuführen.

2. Mit dem ersten Commit im Anwendungs-Repo startet eine erste Pipeline, die die Anwendung baut und ein Dockerfile für diese Version der Anwendung erstellt. Da alle Commits in den master-Branch des Anwendungs-Repositories standardmäßig automatisch nach Staging übernommen werden, erstellt sie außerdem einen neuen Branch und PR im Staging-Repository, um Version 0.0.1 in Staging bereitzustellen. Diese erste Pipeline wartet dann, bis die Promotion-Builds abgeschlossen sind oder ein Timeout eintritt – je nachdem, was zuerst passiert.

3. Der neue Promotion-PR im Staging-Repo löst eine weitere Pipeline aus, die das Helm-Chart für das Deployment nach Staging vorbereitet und im chart-museum des Clusters veröffentlicht. Anschließend führt diese zweite Pipeline den PR mit dem master-Branch des Staging-Repositories zusammen. Dadurch wird die erste Pipeline fortgesetzt und ein weiterer Build ausgelöst, um die Anwendung in Staging bereitzustellen.

Lokal wird ein neues Repository erstellt und in den konfigurierten GitHub-Account gepusht. Der Inhalt des Repositories basiert auf den Dateien der Quickstart-Vorlage (jeder Quickstart ist ein Repository in diesem Projekt) sowie auf dem Build Pack, das zu den im Projekt verwendeten Technologien passt. Für dieses Projekt wurde das javascriptBuild Pack ausgewählt. Es kopiert einige seiner Dateien, etwa das Dockerfile, in das Projekt, um den ersten Commit zu erstellen. Das Dockerfile wird verwendet, um die Anwendung in allen Umgebungen auszuführen.

Mit dem ersten Commit im Anwendungs-Repo startet eine erste Pipeline, die die Anwendung baut und ein Dockerfile für diese Version der Anwendung erstellt. Da alle Commits in den master-Branch des Anwendungs-Repositories standardmäßig automatisch nach Staging übernommen werden, erstellt sie außerdem einen neuen Branch und PR im Staging-Repository, um Version 0.0.1 in Staging bereitzustellen. Diese erste Pipeline wartet dann, bis die Promotion-Builds abgeschlossen sind oder ein Timeout eintritt – je nachdem, was zuerst passiert.

Die neue Promote-PR im Staging-Repository löst eine weitere Pipeline aus. Diese bereitet das Helm Chart für das Deployment nach Staging vor und veröffentlicht es im chart-museum des Clusters. Anschließend führt diese zweite Pipeline die PR mit dem master-Branch des Staging-Repositorys zusammen. Dadurch wird die erste Pipeline freigegeben und ein weiterer Build ausgelöst, der die Anwendung nach Staging deployt.

Am Ende dieses Schritts läuft die Anwendung in der Staging-Umgebung. Mit dem Befehl jx get applications können wir ihre URL einfach ermitteln.

Ein kleines Feature implementieren und deployen

Jetzt, da etwas klarer ist, wie das funktioniert, versuchen wir, einige Features in unserer React-App zu implementieren, und sehen uns an, wie wir Jenkins X nutzen können, um diese Features in die Produktion zu bringen.

Ich werde eine kleine Änderung an der Hauptkomponente unseres Projekts vornehmen und auf der Seite eine neue Textzeile hinzufügen: Added a tiny, but important change to our project.

Anschließend erstelle ich einen neuen Branch namens new-feature und pushe ihn ins Remote-Repository. Danach erstelle ich von diesem Branch eine PR nach master und warte, bis eine neue Pipeline startet. Um den Fortschritt dieser Pipeline und die enthaltenen Schritte zu sehen, führe ich folgenden Befehl aus:

jx get activities -f react-quickstart-jenkinsx/PR-1 -w

Wie ihr vielleicht schon vermutet habt, löst jeder Push in einen Branch mit einer Pull Request eine neue Pipeline aus. Der Name der Pipeline hat dabei folgendes Format: <repo-owner>/<repo-name>/PR-<pull-request-number>

Wenn eure Pipeline erfolgreich abgeschlossen wird, sollte die Ausgabe so aussehen:

alexchiri/react-quickstart-jenkinsx/PR-1 #1                2m51s    2m41s Succeeded  meta pipeline                                            2m51s      20s Succeeded    Credential Initializer 5ftfw                           2m51s       0s Succeeded    Working Dir Initializer 8v64t                          2m51s       1s Succeeded    Place Tools                                            2m50s       1s Succeeded    Git Source Meta Alexchiri React Quickstart Ch8zz       2m49s       6s Succeeded https://github.com/alexchiri/react-quickstart-jenkinsx.git    Git Merge                                              2m43s       3s Succeeded    Merge Pull Refs                                        2m40s       2s Succeeded    Create Effective Pipeline                              2m38s       5s Succeeded    Create Tekton Crds                                     2m33s       2s Succeeded  from build pack                                          2m28s    2m18s Succeeded    Credential Initializer Tsg4g                           2m28s       0s Succeeded    Working Dir Initializer N72vt                          2m28s       1s Succeeded    Place Tools                                            2m27s       1s Succeeded    Git Source Alexchiri React Quickstart Jenk Ndg74       2m26s       7s Succeeded https://github.com/alexchiri/react-quickstart-jenkinsx.git    Git Merge                                              2m19s       3s Succeeded    Build Npmrc                                            2m16s       2s Succeeded    Build Npm Install                                      2m14s      38s Succeeded    Build Npm Test                                         1m36s       4s Succeeded    Build Container Build                                  1m32s      24s Succeeded    Postbuild Post Build                                    1m8s       1s Succeeded    Promote Make Preview                                    1m7s      18s Succeeded    Promote Jx Preview                                       49s      39s Succeeded  Preview                                                    31s           https://github.com/alexchiri/react-quickstart-jenkinsx/pull/1    Preview Application                                      31s           http://react-quickstart-jenkinsx.jx-alexchiri-react-quickstart-jenkinsx-pr-1.192.168.64.18.nip.io

Beachtet den letzten Schritt der Pipeline: Es wurde sogar eine Preview-Umgebung erstellt, in der wir die Änderungen in einer temporären Umgebung ausprobieren können. Außerdem habe ich einen Kommentar zu meiner PR erhalten – von einem Jenkins-X-Bot mit meinen Zugangsdaten erstellt – mit der URL zur Preview-Umgebung:

(Screenshot)

Wenn wir der URL folgen, sehen wir das von uns implementierte Feature in Aktion:

Mir gefällt, wie die Implementierung aussieht. Der nächste Schritt besteht also darin, die Pull Request zusammenzuführen und dieses Feature nach Staging zu übertragen. Dafür muss ich die Pull Request zusammenführen und die Pipelines den Rest erledigen lassen.

Hinweis: Vorgesehen ist, die Pull Request zu mergen, indem ihr sie in GitHub freigebt – mit Befehlen, die der Bot erkennt, etwa /lgtm – und die Pipelines das Zusammenführen übernehmen lasst. Dafür bräuchte ich jedoch einen weiteren GitHub-Benutzer, den ich als Reviewer hinzufügen und mit dem ich die Pull Request freigeben könnte. Da normalerweise ein Team an einem Projekt arbeitet, gibt es mehrere Benutzer, die es besitzen und Pull Requests prüfen. Um diese Benutzer zu konfigurieren, bearbeitet einfach die Datei OWNERS im Projekt-Repository.

Kurz nach dem Merge startet eine neue Pipeline, die die Änderungen in die Umgebung staging releast – genauso wie Version 0.0.1 anfangs nach Staging releast wurde, als der erste Commit in das Repository react-quickstart-jenkinsx erfolgte.

Wenn ihr euch jetzt anseht, welche Previews noch laufen – mit jx get previews –, werdet ihr feststellen, dass die für unsere erste Pull Request erstellte Preview-Umgebung weiterhin läuft, obwohl unsere PR zusammengeführt wurde. Ihr könnt entweder den Jenkins-X-Cronjob abwarten, der sie alle drei Stunden löscht, oder sie manuell über die CLI löschen:

jx delete preview

Wir haben also ein neues Feature in unserem Projekt implementiert, es in einer Preview-Umgebung getestet und anschließend in die Staging-Umgebung übertragen. Nehmen wir an, wir haben weitere Tests in Staging durchgeführt und sind mit den Ergebnissen zufrieden. Wie übertragen wir es nun in die Produktion?

Wir verwenden einfach den Befehl promote:

jx promote react-quickstart-jenkinsx --version 0.0.2 --env production

Wie ihr sicher schon vermutet habt, löst dies zwei neue Builds aus: einen, um im Produktions-Repository eine Pull Request mit der neuen Version zu erstellen, und einen weiteren, um sie zusammenzuführen und in die Produktionsumgebung zu deployen. Danach können wir über die Produktions-URL auf unsere Anwendung mit dem neuen Feature zugreifen. Welche Anwendungen ihr verwaltet und welche URLs sie in den jeweiligen Umgebungen haben, könnt ihr jederzeit mit jx get applications anzeigen. Die Ausgabe sieht dann etwa so aus:

APPLICATION               STAGING PODS URL                                                              PRODUCTION PODS URLreact-quickstart-jenkinsx 0.0.2   1/1  http://react-quickstart-jenkinsx.jx-staging.192.168.64.18.nip.io 0.0.2      1/1  http://react-quickstart-jenkinsx.jx-production.192.168.64.18.nip.io

Verwendet die Produktions-URL. Sobald die Pipeline abgeschlossen ist, seht ihr dort dieselben deployten Änderungen. Unten findet ihr eine vereinfachte Darstellung dessen, was bei der Übertragung in die Produktion passiert ist:

Hinweis: Wenn ihr eure Umgebung bereinigen und Jenkins X aus dem Minikube-Cluster entfernen möchtet, könnt ihr den Befehl jx uninstall verwenden und den Anweisungen der CLI folgen. Jenkins X wird im Handumdrehen aus dem Cluster entfernt.

Ein paar abschließende Gedanken

Diese Einführung kratzt nur an der Oberfläche. Es gibt viele großartige Add-ons – etwa Prometheus für das Monitoring oder KNative und Gloo für ein besseres Management von Anwendungen und Ressourcen – sowie Features wie Dev Pods, über die wir noch nicht gesprochen haben.

Sicherlich werden noch weitere hinzukommen, und in den kommenden Jahren werden wir viel mehr über diese und Jenkins X hören.

Derzeit fühlt sich Jenkins X noch wie ein Produkt in einer frühen Phase an. Es wird intensiv weiterentwickelt, und die Dokumentation könnte deutlich verbessert werden – insbesondere für Benutzer, die nicht die Standardkonfiguration und -einstellungen verwenden.

Dennoch verspricht es, ein sehr leistungsstarkes Tool zu werden, das gesunde Gewohnheiten und Arbeitsweisen in Teams ermöglicht. Dabei setzt es zeitnah Best Practices für CI/CD um.