TOC

Webinar-Reihe: Kubernetes Package Management mit Helm und CI / CD mit Jenkins X

Einführung

Um Fehler zu reduzieren und die Komplexität bei der Bereitstellung einer Anwendung zu organisieren, müssen CI / CD-Systeme zuverlässige Tools für die Paketverwaltung / -bereitstellung und Pipelines mit automatisierten Tests enthalten. In modernen Produktionsumgebungen kann die zunehmende Komplexität der cloudbasierten Infrastruktur Probleme bei der Zusammenstellung einer zuverlässigen CI / CD-Umgebung verursachen. Zwei Kubernetes-spezifische Tools, die zur Lösung dieses Problems entwickelt wurden, sind der Paketmanager Helm und das Pipeline-Automatisierungstool Jenkins X.

Helm ist ein Paketmanager, der speziell für Kubernetes entwickelt wurde und von der Cloud Native Computing Foundation (CNCF) in Zusammenarbeit mit Microsoft, Google, Bitnami und der Helm-Community verwaltet wird. Auf hohem Niveau werden die gleichen Ziele wie bei Linux-Systempaketmanagern wie APT oder YUM erreicht: die Installation von Anwendungen und Abhängigkeiten hinter den Kulissen zu verwalten und die Komplexität vor dem Benutzer zu verbergen. Bei Kubernetes ist diese Art der Verwaltung jedoch noch wichtiger: Die Installation von Anwendungen erfordert die komplexe und langwierige Orchestrierung von YAML-Dateien, und das Aktualisieren oder Zurücksetzen von Releases kann von schwierig bis unmöglich sein. Um dieses Problem zu lösen, wird Helm über Kubernetes ausgeführt und paketiert Anwendungen in vorkonfigurierte Ressourcen namens charts, die der Benutzer mit einfachen Befehlen verwalten kann, um die Freigabe und Verwaltung von Anwendungen benutzerfreundlicher zu gestalten.

Jenkins X ist ein CI / CD-Tool zur Automatisierung von Produktionspipelines und -umgebungen für Kubernetes. Mithilfe von Docker-Images, Helm-Diagrammen und der Jenkins-Pipeline-Engine kann Jenkins X Releases und Versionen automatisch verwalten und Anwendungen zwischen Umgebungen auf GitHub bewerben.

In diesem zweiten Artikel der *CI/CD with Kubernetes * series erhalten Sie eine Vorschau dieser beiden Tools:

  • Kubernetes-Pakete mit Helm verwalten, erstellen und bereitstellen.

  • Aufbau einer CI / CD-Pipeline mit Jenkins X.

Obwohl eine Vielzahl von Kubernetes-Plattformen Helm und Jenkins X verwenden können, führen Sie in diesem Lernprogramm einen simulierten Kubernetes-Cluster aus, der in Ihrer lokalen Umgebung eingerichtet ist. Dazu verwenden Sie Minikube, ein Programm, mit dem Sie Kubernetes-Tools auf Ihrem eigenen Computer ausprobieren können, ohne einen echten Kubernetes-Cluster einrichten zu müssen.

Am Ende dieses Lernprogramms erhalten Sie grundlegende Informationen darüber, wie Sie mit diesen Kubernetes-Tools ein CI / CD-System für Ihre Cloud-Anwendung implementieren können.

Voraussetzungen

Um diesem Tutorial zu folgen, benötigen Sie:

  • Ein Ubuntu 16.04 Server mit 16 GB RAM oder mehr. Da dieses Tutorial nur zu Demonstrationszwecken gedacht ist, werden Befehle vom Root-Konto aus ausgeführt. * Beachten Sie, dass die uneingeschränkten Berechtigungen dieses Kontos nicht den bewährten Methoden für die Produktion entsprechen und sich auf Ihr System auswirken können. * Aus diesem Grund wird empfohlen, die folgenden Schritte in einer Testumgebung wie einer virtuellen Maschine oder einem https: / / www.digitalocean.com/products/droplets/[DigitalOcean Droplet].

  • Ein GitHub-Konto und https://github.com/settings/tokens/new?scopes=repo,read:user,read:org,user:email,write:repo_hook,delete_repo [ GitHub-API-Token]. Stellen Sie sicher, dass Sie dieses API-Token aufzeichnen, damit Sie es im Jenkins X-Teil dieses Lernprogramms eingeben können.

  • Vertrautheit mit Kubernetes-Konzepten. Weitere Informationen finden Sie im Artikel Einführung in Kubernetes.

Schritt 1 - Erstellen eines lokalen Kubernetes-Clusters mit Minikube

Bevor Sie Minikube einrichten, müssen Sie dessen Abhängigkeiten installieren, einschließlich des Kubernetes-Befehlszeilentools kubectl, das bidirektionale Datenübertragungsrelay socat und das Containerprogramm Docker.

Stellen Sie zunächst sicher, dass der Paketmanager Ihres Systems über HTTPS mit "+ apt-transport-https +" auf Pakete zugreifen kann:

apt-get update
apt-get install apt-transport-https

Fügen Sie anschließend den GPG-Schlüssel für das offizielle Google-Repository zu Ihrem System hinzu, um sicherzustellen, dass der Kubectl-Download gültig ist:

curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | apt-key add -

Nachdem Sie den GPG-Schlüssel hinzugefügt haben, erstellen Sie die Datei "+ / etc / apt / sources.list.d / kubernetes.list +", indem Sie sie in Ihrem Texteditor öffnen:

nano /etc/apt/sources.list.d/kubernetes.list

Sobald diese Datei geöffnet ist, fügen Sie die folgende Zeile hinzu:

/etc/apt/sources.list.d/kubernetes.list

deb http://apt.kubernetes.io/ kubernetes-xenial main

Dies zeigt Ihrem System die Quelle für das Herunterladen von kubectl. Sobald Sie die Zeile hinzugefügt haben, speichern und schließen Sie die Datei. Mit dem Nano-Texteditor können Sie dies tun, indem Sie "+ STRG + X " drücken, " y " eingeben und " ENTER +" drücken.

Aktualisieren Sie abschließend die Quellliste für APT und installieren Sie "+ kubectl ", " socat " und " docker.io +":

apt-get update
apt-get install -y kubectl socat docker.io

Nachdem Sie kubectl installiert haben, können Sie mit installing Minikube fortfahren. Verwenden Sie zuerst "+ curl +", um die Binärdatei des Programms herunterzuladen:

curl -Lo minikube https://storage.googleapis.com/minikube/releases//minikube-linux-amd64

Ändern Sie als Nächstes die Zugriffsberechtigungen der soeben heruntergeladenen Datei, damit Ihr System sie ausführen kann:

chmod +x minikube

Kopieren Sie abschließend die Datei + minikube + in den ausführbaren Pfad unter + / usr / local / bin / + und entfernen Sie die Originaldatei aus Ihrem Home-Verzeichnis:

cp minikube /usr/local/bin/
rm minikube

Wenn Minikube auf Ihrem Computer installiert ist, können Sie das Programm jetzt starten. Verwenden Sie den folgenden Befehl, um einen Minikube Kubernetes-Cluster zu erstellen:

minikube start --vm-driver none

Das Flag "+ - vm-driver none +" weist Minikube an, Kubernetes auf dem lokalen Host unter Verwendung von Containern anstelle einer virtuellen Maschine auszuführen. Wenn Sie Minikube auf diese Weise ausführen, müssen Sie keinen VM-Treiber herunterladen, sondern der Kubernetes-API-Server wird unsicher als Root ausgeführt.

Nachdem Sie Minikube gestartet haben, überprüfen Sie, ob Ihr Cluster mit dem folgenden Befehl ausgeführt wird:

minikube status

Sie erhalten die folgende Ausgabe mit Ihrer IP-Adresse anstelle von "++":

minikube: Running
cluster: Running
kubectl: Correctly Configured: pointing to minikube-vm at

Nachdem Sie Ihren simulierten Kubernetes-Cluster mit Minikube eingerichtet haben, können Sie Erfahrungen mit der Kubernetes-Paketverwaltung sammeln, indem Sie den Helm-Paketmanager auf Ihrem Cluster installieren und konfigurieren.

Schritt 2 - Einrichten des Helm Package Managers in Ihrem Cluster

Um die Installation von Anwendungen auf Ihrem Kubernetes-Cluster zu koordinieren, installieren Sie jetzt den Helm-Paketmanager. Helm besteht aus einem "+ helm " - Client, der außerhalb des Clusters ausgeführt wird, und einem " tiller +" - Server, der Anwendungsversionen innerhalb des Clusters verwaltet. Sie müssen beide installieren und konfigurieren, um Helm erfolgreich auf Ihrem Cluster auszuführen.

Um die Helm-Binärdateien zu install herunterzuladen, verwenden Sie zuerst + curl +, um die folgenden https://raw.githubusercontent.com/helm herunterzuladen / helm / master / scripts / holt [Installationsskript] aus dem offiziellen Helm GitHub-Repository in eine neue Datei mit dem Namen "+ get_helm.sh +":

curl https://raw.githubusercontent.com/kubernetes/helm/master/scripts/get > get_helm.sh

Da für dieses Skript Root-Zugriff erforderlich ist, ändern Sie die Berechtigung von "+ get_helm.sh +", damit der Eigentümer der Datei (in diesem Fall "root") sie lesen, schreiben und ausführen kann:

chmod 700 get_helm.sh

Führen Sie nun das Skript aus:

./get_helm.sh

Wenn das Skript beendet ist, haben Sie "+ helm " unter " / usr / local / bin / helm " und " tiller " unter " / usr / local / bin / tiller +" installiert.

Obwohl + tiller + jetzt installiert ist, verfügt es noch nicht über die richtigen Rollen und Berechtigungen, um auf die erforderlichen Ressourcen in Ihrem Kubernetes-Cluster zuzugreifen. Um diese Rollen und Berechtigungen "+ tiller " zuzuweisen, müssen Sie ein https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/[_service account_] mit dem Namen " tiller " erstellen `. In Kubernetes stellt ein Dienstkonto eine Identität für Prozesse dar, die in einem Pod ausgeführt werden. Nachdem ein Prozess über ein Dienstkonto authentifiziert wurde, kann er den API-Server kontaktieren und auf Clusterressourcen zugreifen. Wenn einem Pod kein bestimmtes Dienstkonto zugewiesen ist, wird das Standarddienstkonto verwendet. Sie müssen auch eine https://kubernetes.io/docs/reference/access-authn-authz/rbac/[_Role-Based access control_] (RBAC) -Regel erstellen, die das Dienstkonto " tiller +" autorisiert.

In der RBAC-API von Kubernetes enthält eine Rolle Regeln, die eine Reihe von Berechtigungen festlegen. Eine Rolle kann mit einem Gültigkeitsbereich von "+ Namespace " oder " Cluster " definiert werden und nur den Zugriff auf Ressourcen in einem einzigen Namespace gewähren. ` ClusterRole ` kann die gleichen Berechtigungen auf der Ebene eines Clusters erstellen und Zugriff auf Ressourcen mit Cluster-Bereich wie Knoten und Ressourcen mit Namespaces wie Pods gewähren. Um dem Dienstkonto " tiller " die richtige Rolle zuzuweisen, erstellen Sie eine YAML-Datei mit dem Namen " rbac_helm.yaml +" und öffnen Sie sie in Ihrem Texteditor:

nano rbac_helm.yaml

Fügen Sie der Datei die folgenden Zeilen hinzu, um das Dienstkonto "+ Pinne +" zu konfigurieren:

rbac_helm.yaml

apiVersion: v1
kind: ServiceAccount
metadata:
 name: tiller
 namespace: kube-system
---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
 name: tiller
roleRef:
 apiGroup: rbac.authorization.k8s.io
 kind: ClusterRole
 name: cluster-admin
subjects:
 - kind: ServiceAccount
   name: tiller
   namespace: kube-system

 - kind: User
   name: "admin"
   apiGroup: rbac.authorization.k8s.io

 - kind: User
   name: "kubelet"
   apiGroup: rbac.authorization.k8s.io

 - kind: Group
   name: system:serviceaccounts
   apiGroup: rbac.authorization.k8s.io

In der vorhergehenden Datei ermöglicht "+ ServiceAccount " den " Tiller " - Prozessen den Zugriff auf den Apiserver als authentifiziertes Dienstkonto. " ClusterRole " gewährt einer Rolle bestimmte Berechtigungen, und " ClusterRoleBinding " weist diese Rolle einer Liste von " Themen " zu, einschließlich des Dienstkontos " Pinne ", der Benutzer " Admin " und " Kubelet " und die Gruppe " system: serviceaccounts +".

Stellen Sie als nächstes die Konfiguration in + rbac_helm.yaml + mit dem folgenden Befehl bereit:

kubectl apply -f rbac_helm.yaml

Wenn die Konfiguration "+ Pinne " implementiert ist, können Sie Helm jetzt mit dem Flag " - Dienstkonto +" initialisieren, um das soeben eingerichtete Dienstkonto zu verwenden:

helm init --service-account tiller

Sie erhalten die folgende Ausgabe, die eine erfolgreiche Initialisierung darstellt:

OutputCreating /root/.helm
Creating /root/.helm/repository
Creating /root/.helm/repository/cache
Creating /root/.helm/repository/local
Creating /root/.helm/plugins
Creating /root/.helm/starters
Creating /root/.helm/cache/archive
Creating /root/.helm/repository/repositories.yaml
Adding stable repo with URL: https://kubernetes-charts.storage.googleapis.com
Adding local repo with URL: http://127.0.0.1:8879/charts
$HELM_HOME has been configured at /root/.helm.

Tiller (the Helm server-side component) has been installed into your Kubernetes Cluster.

Please note: by default, Tiller is deployed with an insecure 'allow unauthenticated users' policy.
To prevent this, run `helm init` with the --tiller-tls-verify flag.
For more information on securing your installation see: https://docs.helm.sh/using_helm/#securing-your-helm-installation
Happy Helming!

Dadurch wird im Namespace "+ kube-system" ein "+ tiller" -Pod erstellt. Außerdem wird das Standard-Repository "+ .helm " in Ihrem " $ HOME " - Verzeichnis erstellt und das Standard-Repository für stabile Helm-Diagramme unter " https://kubernetes-charts.storage.googleapis.com " und das lokale Helm-Repository unter "" konfiguriert + http: //127.0.0.1: 8879 / charts +.

Geben Sie den folgenden Befehl ein, um sicherzustellen, dass der Pod "+ tiller" im Namespace "+ kube-system" ausgeführt wird:

kubectl --namespace kube-system get pods

In Ihrer Pod-Liste wird "+ tiller-deploy +" angezeigt, wie in der folgenden Ausgabe dargestellt:

OutputNAME                                    READY   STATUS    RESTARTS   AGE
etcd-minikube                           1/1     Running   0          2h
kube-addon-manager-minikube             1/1     Running   0          2h
kube-apiserver-minikube                 1/1     Running   0          2h
kube-controller-manager-minikube        1/1     Running   0          2h
kube-dns-86f4d74b45-rjql8               3/3     Running   0          2h
kube-proxy-dv268                        1/1     Running   0          2h
kube-scheduler-minikube                 1/1     Running   0          2h
kubernetes-dashboard-5498ccf677-wktkl   1/1     Running   0          2h
storage-provisioner                     1/1     Running   0          2h

Lautet der Status des Pods "+ Tiller " " Running +", kann er Kubernetes-Anwendungen jetzt im Auftrag von Helm von Ihrem Cluster aus verwalten.

Um sicherzustellen, dass die gesamte Helm-Anwendung funktioniert, durchsuchen Sie die Helm-Paket-Repositorys nach einer Anwendung wie MongoDB:

helm search mongodb

In der Ausgabe sehen Sie eine Liste möglicher Anwendungen, die zu Ihrem Suchbegriff passen:

OutputNAME                                    CHART VERSION   APP VERSION     DESCRIPTION
stable/mongodb                          5.4.0           4.0.6           NoSQL document-oriented database that stores JSON-like do...
stable/mongodb-replicaset               3.9.0           3.6             NoSQL document-oriented database that stores JSON-like do...
stable/prometheus-mongodb-exporter      1.0.0           v0.6.1          A Prometheus exporter for MongoDB metrics
stable/unifi                            0.3.1           5.9.29          Ubiquiti Network's Unifi Controller

Nachdem Sie Helm auf Ihrem Kubernetes-Cluster installiert haben, können Sie mehr über den Paketmanager erfahren, indem Sie ein Beispiel-Helmdiagramm erstellen und eine Anwendung daraus bereitstellen.

Schritt 3 - Erstellen eines Diagramms und Bereitstellen einer Anwendung mit Helm

Im Helm-Paketmanager heißen einzelne Pakete charts. Innerhalb eines Diagramms definiert eine Reihe von Dateien eine Anwendung, deren Komplexität von einem Pod zu einer strukturierten Full-Stack-Anwendung variieren kann. Sie können Diagramme aus den Helm-Repositorys herunterladen oder mit dem Befehl + helm create + Ihre eigenen erstellen.

Um die Fähigkeiten von Helm zu testen, erstellen Sie ein neues Helm-Diagramm mit dem Namen "+ demo +" mit dem folgenden Befehl:

helm create demo

In Ihrem Home-Verzeichnis finden Sie ein neues Verzeichnis mit dem Namen "+ demo +", in dem Sie Ihre eigenen Diagrammvorlagen erstellen und bearbeiten können.

Wechseln Sie in das Verzeichnis "+ demo " und verwenden Sie " ls +", um den Inhalt aufzulisten:

cd demo
ls

Sie finden die folgenden Dateien und Verzeichnisse in + demo +:

demo

charts  Chart.yaml  templates  values.yaml

Öffnen Sie mit Ihrem Texteditor die Datei + Chart.yaml +:

nano Chart.yaml

Im Inneren finden Sie folgende Inhalte:

demo / Chart.yaml

apiVersion: v1
appVersion: "1.0"
description: A Helm chart for Kubernetes
name: demo
version: 0.1.0

In dieser + Chart.yaml + Datei finden Sie Felder wie + apiVersion +, die immer + v1 + sein müssen, eine + Beschreibung +, die zusätzliche Informationen darüber gibt, was + demo + ist, der + Name + `des Charts und die + version + `Nummer, die Helm als Release-Marker verwendet. Wenn Sie mit der Prüfung der Datei fertig sind, schließen Sie Ihren Texteditor.

Öffnen Sie als nächstes die Datei + values.yaml +:

nano values.yaml

In dieser Datei finden Sie folgende Inhalte:

demo / values.yaml

# Default values for demo.
# This is a YAML-formatted file.
# Declare variables to be passed into your templates.

replicaCount: 1

image:
 repository: nginx
 tag: stable
 pullPolicy: IfNotPresent

nameOverride: ""
fullnameOverride: ""

service:
 type: ClusterIP
 port: 80

ingress:
 enabled: false
 annotations: {}
   # kubernetes.io/ingress.class: nginx
   # kubernetes.io/tls-acme: "true"
 paths: []
 hosts:
   - chart-example.local
 tls: []
 #  - secretName: chart-example-tls
 #    hosts:
 #      - chart-example.local

resources: {}
 # We usually recommend not to specify default resources and to leave this as a conscious
 # choice for the user. This also increases chances charts run on environments with little
 # resources, such as Minikube. If you do want to specify resources, uncomment the following
 # lines, adjust them as necessary, and remove the curly braces after 'resources:'.
 # limits:
 #  cpu: 100m
 #  memory: 128Mi
 # requests:
 #  cpu: 100m
 #  memory: 128Mi

nodeSelector: {}

tolerations: []

affinity: {}

Durch Ändern des Inhalts von + values.yaml + können Diagrammentwickler Standardwerte für die im Diagramm definierte Anwendung bereitstellen und die Anzahl der Replikate, die Image-Basis, den Ingress-Zugriff, die geheime Verwaltung und vieles mehr steuern. Diagrammbenutzer können ihre eigenen Werte für diese Parameter mit einer benutzerdefinierten YAML-Datei angeben, indem sie "+ helm install " verwenden. Wenn ein Benutzer benutzerdefinierte Werte angibt, überschreiben diese Werte die Werte in der Datei ` values.yaml +` des Diagramms.

Schließen Sie die Datei "+ values.yaml" und listen Sie den Inhalt des Verzeichnisses "+ templates" mit dem folgenden Befehl auf:

ls templates

Hier finden Sie Vorlagen für verschiedene Dateien, mit denen Sie verschiedene Aspekte Ihres Diagramms steuern können:

Vorlagen

deployment.yaml  _helpers.tpl  ingress.yaml  NOTES.txt  service.yaml  tests

Nachdem Sie das "+ Demo " - Diagramm erkundet haben, können Sie mit der Installation des Helm-Diagramms experimentieren, indem Sie " Demo +" installieren. Kehren Sie mit dem folgenden Befehl in Ihr Ausgangsverzeichnis zurück:

cd

Installieren Sie die "+ Demo" -Helm-Tabelle unter dem Namen "+ web" mit "+ helm install":

helm install --name  ./demo

Sie erhalten folgende Ausgabe:

OutputNAME:   web
LAST DEPLOYED: Wed Feb 20 20:59:48 2019
NAMESPACE: default
STATUS: DEPLOYED

RESOURCES:
==> v1/Service
NAME      TYPE       CLUSTER-IP     EXTERNAL-IP  PORT(S)  AGE
web-demo  ClusterIP  10.100.76.231  <none>       80/TCP   0s

==> v1/Deployment
NAME      DESIRED  CURRENT  UP-TO-DATE  AVAILABLE  AGE
web-demo  1        0        0           0          0s

==> v1/Pod(related)
NAME                       READY  STATUS             RESTARTS  AGE
web-demo-5758d98fdd-x4mjs  0/1    ContainerCreating  0         0s


NOTES:
1. Get the application URL by running these commands:
 export POD_NAME=$(kubectl get pods --namespace default -l "app.kubernetes.io/name=demo,app.kubernetes.io/instance=web" -o jsonpath="{.items[0].metadata.name}")
 echo "Visit http://127.0.0.1:8080 to use your application"
 kubectl port-forward $POD_NAME 8080:80

In dieser Ausgabe finden Sie den "+ STATUS" Ihrer Anwendung sowie eine Liste der relevanten Ressourcen in Ihrem Cluster.

Listen Sie als Nächstes die Bereitstellungen auf, die mit dem Befehl + demo + Helm erstellt wurden:

kubectl get deploy

Dies führt zu einer Ausgabe, in der Ihre aktiven Bereitstellungen aufgelistet sind:

OutputNAME       DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
web-demo   1         1         1            1           4m

Wenn Sie Ihre Pods mit dem Befehl "+ kubectl get pods " auflisten, werden die Pods angezeigt, auf denen Ihre " web +" - Anwendung ausgeführt wird. Dies sieht folgendermaßen aus:

OutputNAME                        READY   STATUS    RESTARTS   AGE
web-demo-5758d98fdd-nbkqd   1/1     Running   0          4m

Öffnen Sie "+ demo / values.yaml " in Ihrem Texteditor und ändern Sie " replicaCount: " in " 3 " und " image: tag", um zu veranschaulichen, wie Änderungen im Helm-Diagramm verschiedene Versionen Ihrer Anwendung freigeben können : + von + stable + bis + latest + `. Im folgenden Codeblock finden Sie, wie die YAML-Datei nach dem Ändern aussehen soll, wobei die Änderungen hervorgehoben sind:

demo / values.yaml

# Default values for demo.
# This is a YAML-formatted file.
# Declare variables to be passed into your templates.

replicaCount:

image:
 repository: nginx
 tag:
 pullPolicy: IfNotPresent

nameOverride: ""
fullnameOverride: ""

service:
 type: ClusterIP
 port: 80
. . .

Speichern und schließen Sie die Datei.

Bevor Sie diese neue Version Ihrer "+ web +" - Anwendung bereitstellen, listen Sie Ihre Helm-Versionen mit dem folgenden Befehl so auf, wie sie jetzt sind:

helm list

Sie erhalten die folgende Ausgabe mit der zuvor erstellten Bereitstellung:

OutputNAME    REVISION        UPDATED                         STATUS          CHART           APP VERSION     NAMESPACE

Beachten Sie, dass "+ REVISION " als " 1 " aufgeführt ist, was darauf hinweist, dass dies die erste Revision der " web +" - Anwendung ist.

Aktualisieren Sie die Anwendung mit dem folgenden Befehl, um die Anwendung "+ web " mit den neuesten Änderungen an " demo / values.yaml +" bereitzustellen:

helm upgrade web ./demo

Listen Sie nun die Helm-Releases erneut auf:

helm list

Sie erhalten folgende Ausgabe:

OutputNAME    REVISION        UPDATED                         STATUS          CHART           APP VERSION     NAMESPACE
web                    Wed Feb 20 21:18:12 2019        DEPLOYED        demo-0.1.0      1.0             default

Beachten Sie, dass sich "+ REVISION " in " 2 +" geändert hat, was darauf hinweist, dass dies die zweite Revision ist.

Verwenden Sie Folgendes, um den Verlauf der Helm-Versionen für "+ web +" zu ermitteln:

helm history web

Daraufhin werden beide Revisionen der Anwendung "+ web +" angezeigt:

Ausgabe

REVISION        UPDATED                         STATUS          CHART           DESCRIPTION
1               Wed Feb 20 20:59:48 2019        SUPERSEDED      demo-0.1.0      Install complete
2               Wed Feb 20 21:18:12 2019        DEPLOYED        demo-0.1.0      Upgrade complete

Geben Sie den folgenden Befehl ein, um ein Rollback Ihrer Anwendung auf die Revision "+ 1 +" durchzuführen:

helm rollback web 1

Dies wird die folgende Ausgabe ergeben:

OutputRollback was a success! Happy Helming!

Rufen Sie nun die Versionsgeschichte von Helm auf:

helm history web

Sie erhalten folgende Liste:

OutputREVISION        UPDATED                         STATUS          CHART           DESCRIPTION
1               Wed Feb 20 20:59:48 2019        SUPERSEDED      demo-0.1.0      Install complete
2               Wed Feb 20 21:18:12 2019        SUPERSEDED      demo-0.1.0      Upgrade complete
3               Wed Feb 20 21:28:48 2019                demo-0.1.0      Rollback to 1

Durch Zurücksetzen der Anwendung "+ web " haben Sie eine dritte Revision erstellt, die dieselben Einstellungen wie die Revision " 1 " hat. Denken Sie daran, dass Sie immer feststellen können, welche Revision aktiv ist, indem Sie das Element " DEPLOYED " unter " STATUS +" suchen.

Um sich auf den nächsten Abschnitt vorzubereiten, bereinigen Sie Ihren Testbereich, indem Sie Ihre "+ web" -Version mit dem Befehl "+ helm delete" löschen:

helm delete web

Sehen Sie sich den Versionsverlauf von Helm noch einmal an:

helm history web

Sie erhalten folgende Ausgabe:

OutputREVISION        UPDATED                         STATUS          CHART           DESCRIPTION
1               Wed Feb 20 20:59:48 2019        SUPERSEDED      demo-0.1.0      Install complete
2               Wed Feb 20 21:18:12 2019        SUPERSEDED      demo-0.1.0      Upgrade complete
3               Wed Feb 20 21:28:48 2019                 demo-0.1.0      Deletion complete

Das "+ STATUS " für " REVISION 3 " wurde in " DELETED " geändert und zeigt an, dass Ihre implementierte Instanz von " web " gelöscht wurde. Dadurch wird die Version zwar gelöscht, aber nicht aus dem Speicher gelöscht. Um die Freigabe vollständig zu löschen, führen Sie den Befehl " helm delete" mit dem Flag "+ - purge" aus.

helm delete web --purge

In diesem Schritt haben Sie Anwendungsversionen auf Kubernetes mit dem Helm verwaltet. Wenn Sie Helm weiter studieren möchten, lesen Sie unsere Eine Einführung in Helm, the Package Manager for Kubernetes oder lesen Sie die offizielle Helm documentation.

Als Nächstes richten Sie das Pipeline-Automatisierungstool Jenkins X ein und testen es, indem Sie die CLI + jx + verwenden, um einen CI / CD-fähigen Kubernetes-Cluster zu erstellen.

Schritt 4 - Einrichten der Jenkins X-Umgebung

Mit Jenkins X können Sie Ihren Kubernetes-Cluster von Grund auf mit eingebauten Pipeline-Automatisierungs- und CI / CD-Lösungen erstellen. Durch die Installation des CLI-Tools + jx + können Sie Anwendungsversionen, Docker-Images und Helm-Diagramme effizient verwalten und Ihre Anwendungen in verschiedenen Umgebungen in GitHub automatisch bewerben.

Da Sie + jx + verwenden, um Ihren Cluster zu erstellen, müssen Sie zuerst den Minikube-Cluster löschen, den Sie bereits haben. Verwenden Sie dazu den folgenden Befehl:

minikube delete

Dadurch wird der lokal simulierte Kubernete-Cluster gelöscht, die Standardverzeichnisse, die bei der Erstinstallation von Minikube erstellt wurden, werden jedoch nicht gelöscht. Verwenden Sie die folgenden Befehle, um diese von Ihrem Computer zu entfernen:

rm -rf ~/.kube
rm -rf ~/.minikube
rm -rf /etc/kubernetes/*
rm -rf /var/lib/minikube/*

Sobald Sie Minikube vollständig von Ihrem Computer gelöscht haben, können Sie mit der Installation der Jenkins X-Binärdatei fortfahren.

Laden Sie zuerst die komprimierte + jx + - Datei aus dem offiziellen Jenkins X GitHub-Repository mit dem Befehl + curl + herunter und dekomprimieren Sie sie mit dem Befehl + tar +:

curl -L https://github.com/jenkins-x/jx/releases/download/v1.3.781/jx-linux-amd64.tar.gz | tar xzv

Verschieben Sie als nächstes die heruntergeladene + js-Datei in den ausführbaren Pfad unter` + / usr / local / bin`:

mv jx /usr/local/bin

Jenkins X wird mit einer Docker-Registrierung geliefert, die in Ihrem Kubernetes-Cluster ausgeführt wird. Da dies ein internes Element ist, können Sicherheitsmaßnahmen wie selbstsignierte Zertifikate Probleme für das Programm verursachen. Um dies zu beheben, stellen Sie Docker so ein, dass unsichere Registrierungen für den lokalen IP-Bereich verwendet werden. Erstellen Sie dazu die Datei "+ /etc/docker/daemon.json" und öffnen Sie diese in Ihrem Texteditor:

nano /etc/docker/daemon.json

Fügen Sie der Datei den folgenden Inhalt hinzu:

/etc/docker/daemon.json

{
 "insecure-registries" : ["0.0.0.0/0"]
}

Speichern und schließen Sie die Datei. Starten Sie den Docker-Dienst mit dem folgenden Befehl neu, damit diese Änderungen wirksam werden:

systemctl restart docker

Verwenden Sie den folgenden Befehl, um zu überprüfen, ob Sie Docker mit unsicheren Registrierungen konfiguriert haben:

docker info

Am Ende der Ausgabe sollte die folgende hervorgehobene Zeile angezeigt werden:

OutputContainers: 0
Running: 0
Paused: 0
Stopped: 0
Images: 15
Server Version: 18.06.1-ce
Storage Driver: overlay2
Backing Filesystem: extfs
Supports d_type: true
Native Overlay Diff: true

. . .

Registry: https://index.docker.io/v1/
Labels:
Experimental: false
Insecure Registries:

127.0.0.0/8
Live Restore Enabled: false

Nachdem Sie Jenkins X heruntergeladen und die Docker-Registrierung konfiguriert haben, erstellen Sie mit dem CLI-Tool + jx + einen Minikube Kubernetes-Cluster mit CI / CD-Funktionen:

jx create cluster minikube --cpu=5 --default-admin-password=admin --vm-driver=none --memory=13314

Hier erstellen Sie mit Minikube einen Kubernetes-Cluster mit dem Flag "+ - cpu = 5 ", um 5 CPUs festzulegen, und " - memory = 13314 ", um Ihrem Cluster 13314 MB Arbeitsspeicher zu geben. Da es sich bei Jenkins X um ein robustes, aber umfangreiches Programm handelt, stellen diese Spezifikationen sicher, dass Jenkins X bei dieser Demonstration problemlos funktioniert. Außerdem verwenden Sie " - default-admin-password = admin ", um das Jenkins X-Kennwort als " admin " festzulegen, und " - vm-driver = none +", um den Cluster wie in "" lokal einzurichten Schritt 1.

Während Jenkins X Ihren Cluster hochfährt, erhalten Sie während des gesamten Vorgangs verschiedene Eingabeaufforderungen, mit denen Sie die Parameter für Ihren Cluster festlegen und festlegen können, wie er mit GitHub kommuniziert, um Ihre Produktionsumgebungen zu verwalten.

Zunächst erhalten Sie die folgende Eingabeaufforderung:

Output? disk-size (MB) 150GB

Drücken Sie "+ ENTER", um fortzufahren. Als nächstes werden Sie aufgefordert, den Namen, den Sie mit git verwenden möchten, die E-Mail-Adresse, die Sie mit git verwenden möchten, und Ihren GitHub-Benutzernamen einzugeben. Geben Sie diese bei entsprechender Aufforderung ein und drücken Sie "+ ENTER".

Als Nächstes fordert Jenkins X Sie auf, Ihr GitHub-API-Token einzugeben:

OutputTo be able to create a repository on GitHub we need an API Token
Please click this URL

Then COPY the token and enter in into the form below:

? API Token:

Geben Sie Ihr Token hier ein oder erstellen Sie ein neues Token mit den entsprechenden Berechtigungen unter Verwendung der im vorhergehenden Codeblock hervorgehobenen URL.

Als nächstes wird Jenkins X fragen:

Output? Do you wish to use GitHub as the pipelines Git server: (Y/n)

? Do you wish to use  as the pipelines Git user for GitHub server: (Y/n)

Geben Sie für beide Fragen "+ Y +" ein.

Danach werden Sie von Jenkins X aufgefordert, die folgenden Fragen zu beantworten:

Output? Select Jenkins installation type:   [Use arrows to move, type to filter]
>Static Master Jenkins
 Serverless Jenkins

? Pick workload build pack:   [Use arrows to move, type to filter]
> Kubernetes Workloads: Automated CI+CD with GitOps Promotion
 Library Workloads: CI+Release but no CD

Wählen Sie "+ Static Master Jenkins " und " Kubernetes Workloads: Automated CI + CD with GitOps Promotion +" für letzteres. Wenn Sie aufgefordert werden, eine Organisation für Ihr Umgebungs-Repository auszuwählen, wählen Sie Ihren GitHub-Benutzernamen.

Schließlich erhalten Sie die folgende Ausgabe, die die erfolgreiche Installation überprüft und Ihr Jenkins X-Administratorkennwort angibt.

OutputCreating GitHub webhook for /environment-horsehelix-production for url http://jenkins.jx..nip.io/github-webhook/

Jenkins X installation completed successfully


       ********************************************************

            NOTE: Your admin password is:

       ********************************************************



Your Kubernetes context is now set to the namespace: jx
To switch back to your original namespace use: jx namespace default
For help on switching contexts see: https://jenkins-x.io/developing/kube-context/

To import existing projects into Jenkins:       jx import
To create a new Spring Boot microservice:       jx create spring -d web -d actuator
To create a new microservice from a quickstart: jx create quickstart

Verwenden Sie als Nächstes den Befehl + js get, um eine Liste von URLs zu erhalten, die Informationen zu Ihrer Anwendung enthalten:

jx get urls

Dieser Befehl liefert eine Liste ähnlich der folgenden:

Name                      URL
jenkins                   http://jenkins.jx..nip.io
jenkins-x-chartmuseum     http://chartmuseum.jx..nip.io
jenkins-x-docker-registry http://docker-registry.jx..nip.io
jenkins-x-monocular-api   http://monocular.jx..nip.io
jenkins-x-monocular-ui    http://monocular.jx..nip.io
nexus                     http://nexus.jx..nip.io

Mithilfe der URLs können Sie Jenkins X-Daten zu Ihrer CI / CD-Umgebung über eine Benutzeroberfläche anzeigen, indem Sie die Adresse in Ihren Browser eingeben und Ihren Benutzernamen und Ihr Kennwort eingeben. In diesem Fall ist dies für beide "admin".

Um sicherzustellen, dass die Dienstkonten in den Namespaces "+ jx ", " jx-staging " und " jx-production +" über Administratorrechte verfügen, ändern Sie als Nächstes Ihre RBAC-Richtlinien mit den folgenden Befehlen:

kubectl create clusterrolebinding jx-staging1 --clusterrole=cluster-admin --user=admin --user=expose --group=system:serviceaccounts --serviceaccount=jx-staging:expose --namespace=jx-staging
kubectl create clusterrolebinding jx-staging2 --clusterrole=cluster-admin --user=admin --user=expose --group=system:serviceaccounts --serviceaccount=jx-staging:default --namespace=jx-staging
kubectl create clusterrolebinding jx-production1 --clusterrole=cluster-admin --user=admin --user=expose --group=system:serviceaccounts --serviceaccount=jx-production:expose --namespace=jx-productions
kubectl create clusterrolebinding jx-production2 --clusterrole=cluster-admin --user=admin --user=expose --group=system:serviceaccounts --serviceaccount=jx-production:default --namespace=jx-productions
kubectl create clusterrolebinding jx-binding1 --clusterrole=cluster-admin --user=admin --user=expose --group=system:serviceaccounts --serviceaccount=jx:expose --namespace=jx
kubectl create clusterrolebinding jx-binding2 --clusterrole=cluster-admin --user=admin --user=expose --group=system:serviceaccounts --serviceaccount=jx:default --namespace=jx

Nachdem Sie Ihren lokalen Kubernetes-Cluster mit integrierter Jenkins X-Funktionalität erstellt haben, können Sie eine Anwendung auf der Plattform erstellen, um deren CI / CD-Funktionen zu testen und eine Jenkins X-Pipeline zu testen.

Schritt 5 - Erstellen einer Testanwendung in Ihrer Jenkins X-Umgebung

Mit Ihrer Jenkins X-Umgebung, die in Ihrem Kubernetes-Cluster eingerichtet ist, verfügen Sie jetzt über eine CI / CD-Infrastruktur, mit der Sie eine Test-Pipeline automatisieren können. In diesem Schritt probieren Sie dies aus, indem Sie eine Testanwendung in einer funktionierenden Jenkins X-Pipeline einrichten.

Zu Demonstrationszwecken wird in diesem Tutorial eine Beispiel-RSVP-Anwendung verwendet, die vom CloudYuga -Team erstellt wurde. Sie finden diese Anwendung zusammen mit anderen Webinar-Materialien unter DO-Community GitHub repository.

Klonen Sie zunächst die Beispielanwendung aus dem Repository mit dem folgenden Befehl:

git clone https://github.com/do-community/rsvpapp.git

Nachdem Sie das Repository geklont haben, wechseln Sie in das Verzeichnis "+ rsvpapp +" und entfernen Sie die Git-Dateien:

cd rsvpapp
rm -r .git/

Um ein Git-Repository und ein Jenkins X-Projekt für eine neue Anwendung zu initialisieren, können Sie "+ jx create " verwenden, um von vorne zu beginnen, oder " jx import +", um eine vorhandene Anwendung aus einem lokalen Projekt oder einem Git-Repository zu importieren. Importieren Sie für dieses Lernprogramm die RSVP-Beispielanwendung, indem Sie den folgenden Befehl im Basisverzeichnis der Anwendung ausführen:

jx import

Jenkins X fragt Sie nach Ihrem GitHub-Benutzernamen, ob Sie git, eine Bestätigungsnachricht, Ihre Organisation und den Namen für Ihr Repository initialisieren möchten. Beantworten Sie die Frage mit "Ja", um Git zu initialisieren, und geben Sie dann die restlichen Eingabeaufforderungen mit Ihren individuellen GitHub-Informationen und -Einstellungen an. Wenn Jenkins X die Anwendung importiert, werden Helm-Diagramme und eine Jenkins-Datei im Basisverzeichnis Ihrer Anwendung erstellt. Sie können diese Diagramme und die Jenkins-Datei gemäß Ihren Anforderungen ändern.

Da die RSVP-Beispielanwendung auf dem Port "+ 5000 " ihres Containers ausgeführt wird, ändern Sie Ihre Datei " charts / rsvpapp / values.yaml " entsprechend. Öffnen Sie die Datei ` charts / rsvpapp / values.yaml +` in Ihrem Texteditor:

nano charts/rsvpapp/values.yaml

In dieser + values.yaml + Datei setzen Sie + service: internalPort: + auf + 5000 +. Nachdem Sie diese Änderung vorgenommen haben, sollte Ihre Datei folgendermaßen aussehen:

charts / rsvpapp / values.yaml

# Default values for python.
# This is a YAML-formatted file.
# Declare variables to be passed into your templates.
replicaCount: 1
image:
 repository: draft
 tag: dev
 pullPolicy: IfNotPresent
service:
 name: rsvpapp
 type: ClusterIP
 externalPort: 80
 internalPort:
 annotations:
   fabric8.io/expose: "true"
   fabric8.io/ingress.annotations: "kubernetes.io/ingress.class: nginx"
resources:
 limits:
   cpu: 100m
   memory: 128Mi
 requests:
   cpu: 100m
   memory: 128Mi
ingress:
 enabled: false

Speichern und schließen Sie Ihre Datei.

Als nächstes ändern Sie das + charts / preview / requirements.yaml + so, dass es zu Ihrer Anwendung passt. + requirements.yaml + ist eine YAML-Datei, in der Entwickler Diagrammabhängigkeiten zusammen mit dem Speicherort des Diagramms und der gewünschten Version deklarieren können. Da unsere Beispielanwendung MongoDB für Datenbankzwecke verwendet, müssen Sie die Datei "+ charts / preview / requirements.yaml +" ändern, um MongoDB als Abhängigkeit aufzulisten. Öffnen Sie die Datei in Ihrem Texteditor mit dem folgenden Befehl:

nano charts/preview/requirements.yaml

Bearbeiten Sie die Datei, indem Sie den Eintrag + mongodb-replicaset + nach dem Eintrag + alias: cleanup + hinzufügen, wie im folgenden Codeblock hervorgehoben:

charts / preview / requirements.yaml

# !! File must end with empty line !!
dependencies:
- alias: expose
 name: exposecontroller
 repository: http://chartmuseum.jenkins-x.io
 version: 2.3.92
- alias: cleanup
 name: exposecontroller
 repository: http://chartmuseum.jenkins-x.io
 version: 2.3.92




 # !! "alias: preview" must be last entry in dependencies array !!
 # !! Place custom dependencies above !!
- alias: preview
 name: rsvpapp
 repository: file://../rsvpapp

Hier haben Sie das Diagramm "+ mongodb-replicaset " als Abhängigkeit für das Diagramm " preview +" angegeben.

Wiederholen Sie diesen Vorgang für Ihr "+ rsvpapp " - Diagramm. Erstellen Sie die Datei ` charts / rsvpapp / requirements.yaml +` und öffnen Sie sie in Ihrem Texteditor:

nano charts/rsvpapp/requirements.yaml

Fügen Sie nach dem Öffnen der Datei Folgendes hinzu, und vergewissern Sie sich, dass vor und nach den ausgefüllten Zeilen eine Leerzeile vorhanden ist:

charts / rsvpapp / requirements.yaml

dependencies:
- name: mongodb-replicaset
 repository: https://kubernetes-charts.storage.googleapis.com/
 version: 3.5.5

Jetzt haben Sie das Diagramm "+ mongodb-replicaset " als Abhängigkeit für Ihr Diagramm " rsvpapp +" angegeben.

Um das Frontend der RSVP-Beispielanwendung mit dem MongoDB-Backend zu verbinden, fügen Sie als Nächstes eine Umgebungsvariable "+ MONGODB_HOST " zu Ihrer " deployment.yaml " -Datei in " charts / rsvpapp / templates / +" hinzu. Öffnen Sie diese Datei in Ihrem Texteditor:

nano charts/rsvpapp/templates/deployment.yaml

Fügen Sie der Datei die folgenden hervorgehobenen Zeilen hinzu, zusätzlich zu einer leeren Zeile oben in der Datei und zwei leeren Zeilen unten in der Datei. Beachten Sie, dass diese Leerzeilen erforderlich sind, damit die YAML-Datei funktioniert:

charts / rsvpapp / templates / deployment.yaml

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
 name: {{ template "fullname" . }}
 labels:
   draft: {{ default "draft-app" .Values.draft }}
   chart: "{{ .Chart.Name }}-{{ .Chart.Version | replace "+" "_" }}"
spec:
 replicas: {{ .Values.replicaCount }}
 template:
   metadata:
     labels:
       draft: {{ default "draft-app" .Values.draft }}
       app: {{ template "fullname" . }}
{{- if .Values.podAnnotations }}
     annotations:
{{ toYaml .Values.podAnnotations | indent 8 }}
{{- end }}
   spec:
     containers:
     - name: {{ .Chart.Name }}
       image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"



       imagePullPolicy: {{ .Values.image.pullPolicy }}
       ports:
       - containerPort: {{ .Values.service.internalPort }}
       resources:
{{ toYaml .Values.resources | indent 12 }}

Mit diesen Änderungen kann Helm Ihre Anwendung mit MongoDB als Datenbank bereitstellen.

Untersuchen Sie als Nächstes das von Jenkins X generierte "+ Jenkinsfile +", indem Sie die Datei aus dem Ausgangsverzeichnis Ihrer Anwendung öffnen:

nano Jenkinsfile

Dieses + Jenkinsfile + definiert die Pipeline, die jedes Mal ausgelöst wird, wenn Sie eine Version Ihrer Anwendung in Ihr GitHub-Repository übertragen. Wenn Sie den Codetest automatisieren möchten, sodass die Tests bei jedem Auslösen der Pipeline ausgelöst werden, fügen Sie den Test diesem Dokument hinzu.

Um dies zu demonstrieren, fügen Sie einen benutzerdefinierten Testfall hinzu, indem Sie "+ sh" python -m unittest "" unter " stage" ("CI-Erstellung und Push-Snapshot") + "und" + stage "(" Build Release ") " in ersetzen das ` Jenkinsfile +` mit den folgenden hervorgehobenen Zeilen:

/ rsvpapp / Jenkinsfile

. . .
 stages {
   stage('CI Build and push snapshot') {
     when {
       branch 'PR-*'
     }
     environment {
       PREVIEW_VERSION = "0.0.0-SNAPSHOT-$BRANCH_NAME-$BUILD_NUMBER"
       PREVIEW_NAMESPACE = "$APP_NAME-$BRANCH_NAME".toLowerCase()
       HELM_RELEASE = "$PREVIEW_NAMESPACE".toLowerCase()
     }
     steps {
       container('python') {


         sh "export VERSION=$PREVIEW_VERSION && skaffold build -f skaffold.yaml"
         sh "jx step post build --image $DOCKER_REGISTRY/$ORG/$APP_NAME:$PREVIEW_VERSION"
         dir('./charts/preview') {
           sh "make preview"
           sh "jx preview --app $APP_NAME --dir ../.."
         }
       }
     }
   }
   stage('Build Release') {
     when {
       branch 'master'
     }
     steps {
       container('python') {

         // ensure we're not on a detached head
         sh "git checkout master"
         sh "git config --global credential.helper store"
         sh "jx step git credentials"

         // so we can retrieve the version in later steps
         sh "echo \$(jx-release-version) > VERSION"
         sh "jx step tag --version \$(cat VERSION)"


         sh "export VERSION=`cat VERSION` && skaffold build -f skaffold.yaml"
         sh "jx step post build --image $DOCKER_REGISTRY/$ORG/$APP_NAME:\$(cat VERSION)"
       }
     }
   }
. . .

Mit den hinzugefügten Zeilen installiert die Jenkins X-Pipeline Abhängigkeiten und führt einen Python-Test durch, wenn Sie eine Änderung an Ihrer Anwendung vornehmen.

Nachdem Sie die RSVP-Beispielanwendung geändert haben, übertragen Sie diese Änderungen mit den folgenden Befehlen an GitHub:

git add *
git commit -m update
git push

Wenn Sie diese Änderungen an GitHub übertragen, wird eine neue Erstellung Ihrer Anwendung ausgelöst. Wenn Sie die Jenkins-Benutzeroberfläche öffnen, indem Sie zu "+ http: // jenkins.jx..nip.io +" navigieren und "admin" für Ihren Benutzernamen und Ihr Kennwort eingeben, finden Sie Informationen zu Ihrem neuen Build. Wenn Sie im Menü auf der linken Seite auf "Build-Verlauf" klicken, sollte ein Verlauf Ihrer festgeschriebenen Builds angezeigt werden. Wenn Sie auf das blaue Symbol neben einem Build klicken und dann im linken Menü die Option "Konsolenausgabe" auswählen, finden Sie die Konsolenausgabe für die automatisierten Schritte in Ihrer Pipeline. Wenn Sie zum Ende dieser Ausgabe scrollen, wird die folgende Meldung angezeigt:

Output. . .
Finished: SUCCESS

Dies bedeutet, dass Ihre Anwendung Ihre benutzerdefinierten Tests bestanden hat und jetzt erfolgreich bereitgestellt wird.

Sobald Jenkins X die Anwendungsversion erstellt hat, wird die Anwendung in die Umgebung "+ staging +" verschoben. Um zu überprüfen, ob Ihre Anwendung ausgeführt wird, listen Sie die auf Ihrem Kubernetes-Cluster ausgeführten Anwendungen mit dem folgenden Befehl auf:

jx get app

Sie erhalten eine Ausgabe ähnlich der folgenden:

OutputAPPLICATION STAGING PODS URL
rsvpapp     0.0.2   1/1  http://rsvpapp.jx-staging..nip.io

Daraus können Sie ersehen, dass Jenkins X Ihre Anwendung in Ihrer "+ jx-staging " -Umgebung als Version " 0.0.2 +" bereitgestellt hat. In der Ausgabe wird auch die URL angezeigt, über die Sie auf Ihre Anwendung zugreifen können. Wenn Sie diese URL besuchen, sehen Sie die RSVP-Beispielanwendung:

image: https://assets.digitalocean.com/articles/cart_64885/Sample_App_jx-staging.png [RSVP-Beispielanwendung in der Staging-Umgebung]

Überprüfen Sie als Nächstes die Aktivität Ihrer Anwendung mit dem folgenden Befehl:

jx get activity -f rsvpapp

Sie erhalten eine Ausgabe ähnlich der folgenden:

OutputSTEP                                        STARTED      AGO DURATION STATUS
/rsvpappv/master #1    3h42m23s    4m51s Succeeded Version: 0.0.1
 Checkout Source                          3h41m52s       6s Succeeded
 CI Build and push snapshot               3h41m46s          NotExecuted
 Build Release                            3h41m46s      56s Succeeded
 Promote to Environments                  3h40m50s    3m17s Succeeded
 Promote: staging                         3h40m29s    2m36s Succeeded
   PullRequest                            3h40m29s    1m16s Succeeded  PullRequest: https://github.com//environment-horsehelix-staging/pull/1 Merge SHA: dc33d3747abdacd2524e8c22f0b5fbb2ac3f6fc7
   Update                                 3h39m13s    1m20s Succeeded  Status: Success at: http://jenkins.jx..nip.io/job//job/environment-horsehelix-staging/job/master/2/display/redirect
   Promoted                               3h39m13s    1m20s Succeeded  Application is at: http://rsvpapp.jx-staging..nip.io
 Clean up                                 3h37m33s       1s Succeeded
/rsvpappv/master #2      28m37s    5m57s Succeeded Version: 0.0.2
 Checkout Source                            28m18s       4s Succeeded
 CI Build and push snapshot                 28m14s          NotExecuted
 Build Release                              28m14s      56s Succeeded
 Promote to Environments                    27m18s    4m38s Succeeded
 Promote: staging                           26m53s     4m0s Succeeded
   PullRequest                              26m53s     1m4s Succeeded  PullRequest: https://github.com//environment-horsehelix-staging/pull/2 Merge SHA: 976bd5ad4172cf9fd79f0c6515f5006553ac6611
   Update                                   25m49s    2m56s Succeeded  Status: Success at: http://jenkins.jx..nip.io/job//job/environment-horsehelix-staging/job/master/3/display/redirect
   Promoted                                 25m49s    2m56s Succeeded  Application is at: http://rsvpapp.jx-staging..nip.io
 Clean up                                   22m40s       0s Succeeded

Hier erhalten Sie die Jenkins X-Aktivität für die RSVP-Anwendung, indem Sie einen Filter mit "+ -f rsvpapp +" anwenden.

Listen Sie als Nächstes die Pods auf, die im Namespace + jx-staging + ausgeführt werden, und geben Sie den folgenden Befehl ein:

kubectl get pod -n jx-staging

Sie erhalten eine Ausgabe ähnlich der folgenden:

NAME                                 READY     STATUS    RESTARTS   AGE
jx-staging-mongodb-replicaset-0      1/1       Running   0          6m
jx-staging-mongodb-replicaset-1      1/1       Running   0          6m
jx-staging-mongodb-replicaset-2      1/1       Running   0          5m
jx-staging-rsvpapp-c864c4844-4fw5z   1/1       Running   0          6m

Diese Ausgabe zeigt, dass Ihre Anwendung im Namespace "+ jx-staging +" ausgeführt wird, zusammen mit drei Pods der Back-End-MongoDB-Datenbank, wobei die zuvor an den YAML-Dateien vorgenommenen Änderungen berücksichtigt wurden.

Nachdem Sie eine Testanwendung über die Jenkins X-Pipeline ausgeführt haben, können Sie versuchen, diese Anwendung für die Produktionsumgebung zu promoten.

Schritt 6 - Heraufstufen Ihrer Testanwendung in einen anderen Namespace

Um diese Demonstration abzuschließen, schließen Sie den CI / CD-Prozess ab, indem Sie die RSVP-Beispielanwendung in Ihren Namespace "+ jx-production +" hochstufen.

Verwenden Sie zuerst + jx promot + im folgenden Befehl:

jx promote rsvpapp --version=0.0.2 --env=production

Dadurch wird die Anwendung "+ rsvpapp ", die mit " version = 0.0.2 +" ausgeführt wird, in die Produktionsumgebung verschoben. Während des Erstellungsprozesses werden Sie von Jenkins X aufgefordert, Ihre GitHub-Kontoinformationen einzugeben. Beantworten Sie diese Eingabeaufforderungen mit Ihren individuellen Antworten.

Überprüfen Sie nach erfolgreicher Promotion die Liste der Anwendungen:

jx get app

Sie erhalten eine Ausgabe ähnlich der folgenden:

OutputAPPLICATION STAGING PODS URL                                             PRODUCTION PODS URL
rsvpapp     0.0.2   1/1  http://rsvpapp.jx-staging..nip.io 0.0.2      1/1  http://rsvpapp.jx-production..nip.io

Mit diesen "+ PRODUCTION" -Informationen können Sie bestätigen, dass Jenkins X die "+ rsvp app" in die Produktionsumgebung befördert hat. Besuchen Sie zur weiteren Überprüfung die Produktions-URL "+ http: // rsvpapp.jx-production..nip.io +" in Ihrem Browser. Sie sollten die funktionierende Anwendung sehen, die nicht aus der „Produktion“ läuft:

image: https://assets.digitalocean.com/articles/cart_64885/Sample_App_jx-production.png [RSVP-Beispielanwendung in der Produktionsumgebung]

Listen Sie abschließend Ihre Pods im Namespace "+ jx-production +" auf.

kubectl get pod -n jx-production

Sie werden feststellen, dass + rsvpapp + und die MongoDB-Backend-Pods in diesem Namespace ausgeführt werden:

NAME                                     READY     STATUS    RESTARTS   AGE
jx-production-mongodb-replicaset-0       1/1       Running   0          1m
jx-production-mongodb-replicaset-1       1/1       Running   0          1m
jx-production-mongodb-replicaset-2       1/1       Running   0          55s
jx-production-rsvpapp-54748d68bd-zjgv7   1/1       Running   0          1m

Dies zeigt, dass Sie die RSVP-Beispielanwendung erfolgreich in Ihre Produktionsumgebung hochgestuft haben und die produktionsbereite Bereitstellung einer Anwendung am Ende einer CI / CD-Pipeline simulieren.

Fazit

In diesem Lernprogramm haben Sie mit Helm Pakete in einem simulierten Kubernetes-Cluster verwaltet und ein Helm-Diagramm angepasst, um Ihre eigene Anwendung zu packen und bereitzustellen. Sie richten auch eine Jenkins X-Umgebung in Ihrem Kubernetes-Cluster ein und führen eine Beispielanwendung von Anfang bis Ende über eine CI / CD-Pipeline aus.

Sie haben jetzt Erfahrung mit diesen Tools, die Sie beim Erstellen eines CI / CD-Systems auf Ihrem eigenen Kubernetes-Cluster verwenden können. Wenn Sie mehr über Helm erfahren möchten, lesen Sie unsere Eine Einführung in Helm , the Package Manager for Kubernetes und How To Install Software über Kubernetes-Cluster mit dem Helm Package Manager. Weitere Informationen zu CI / CD-Tools auf Kubernetes finden Sie im nächsten Tutorial in dieser Webinar-Reihe.

Related