TOC

Série de séminaires Web: Gestion des paquets Kubernetes avec Helm et CI / CD avec Jenkins X

introduction

Afin de réduire les erreurs et d’organiser la complexité lors du déploiement d’une application, les systèmes CI / CD doivent inclure un outil robuste pour la gestion / le déploiement de packages et des pipelines avec tests automatisés. Toutefois, dans les environnements de production modernes, la complexité croissante de l’infrastructure basée sur le cloud peut poser des problèmes pour la mise en place d’un environnement CI / CD fiable. Deux outils spécifiques à Kubernetes développés pour résoudre ce problème sont le gestionnaire de paquets Helm et l’outil d’automatisation de pipeline Jenkins X.

Helm est un gestionnaire de paquets spécialement conçu pour Kubernetes, géré par la Cloud Native Computing Foundation (CNCF) en collaboration avec Microsoft, Google, Bitnami et la communauté de contributeurs Helm. À un niveau élevé, il atteint les mêmes objectifs que les gestionnaires de paquets système Linux comme APT ou YUM: gérer l’installation d’applications et de dépendances en arrière-plan et masquer la complexité à l’utilisateur. Mais avec Kubernetes, le besoin de ce type de gestion est encore plus criant: l’installation d’applications nécessite une orchestration complexe et fastidieuse des fichiers YAML, et la mise à niveau ou la restauration de versions peut être difficile, voire impossible. Afin de résoudre ce problème, Helm s’exécute sur Kubernetes et regroupe les applications dans des ressources préconfigurées appelées charts, que l’utilisateur peut gérer à l’aide de commandes simples, ce qui rend le processus de partage et de gestion des applications plus convivial.

Jenkins X est un outil CI / CD utilisé pour automatiser les pipelines et les environnements de production pour Kubernetes. À l’aide d’images Docker, de diagrammes Helm et du moteur de pipeline Jenkins, Jenkins X peut gérer automatiquement les versions et les versions et promouvoir les applications entre environnements sur GitHub.

Dans ce deuxième article de la série https://www.digitalocean.com/community/tutorial_series/webinar-series-ci-cdc-cd-kubernetes[*CI/CD with Kubernetes *, vous présenterez un aperçu de ces deux outils:

  • Gestion, création et déploiement de packages Kubernetes avec Helm.

  • Construire un pipeline CI / CD avec Jenkins X.

Bien que diverses plates-formes Kubernetes puissent utiliser Helm et Jenkins X, dans ce didacticiel, vous allez exécuter un cluster Kubernetes simulé, configuré dans votre environnement local. Pour ce faire, vous utiliserez Minikube, un programme qui vous permettra d’essayer les outils Kubernetes sur votre propre ordinateur sans avoir à configurer un véritable cluster Kubernetes.

À la fin de ce didacticiel, vous comprendrez comment ces outils natifs de Kubernetes peuvent vous aider à mettre en place un système CI / CD pour votre application cloud.

Conditions préalables

Pour suivre ce tutoriel, vous aurez besoin de:

  • Un serveur Ubuntu 16.04 avec 16 Go de RAM ou plus. Étant donné que ce tutoriel est destiné uniquement à des fins de démonstration, les commandes sont exécutées à partir du compte root. * Notez que les privilèges illimités de ce compte ne respectent pas les meilleures pratiques de production et peuvent affecter votre système. * Pour cette raison, il est suggéré de suivre ces étapes dans un environnement de test tel qu’une machine virtuelle ou https: / /www.digitalocean.com/products/droplets/[DigitalOcean Droplet].

  • Un compte GitHub et https://github.com/settings/tokens/new?scopes=repo,read:user,read:org,user,email,write:repo_hook,delete_repo [ Jeton de l’API GitHub]. Assurez-vous d’enregistrer ce jeton d’API afin de pouvoir le saisir lors de la partie Jenkins X de ce didacticiel.

  • Familiarité avec les concepts de Kubernetes. Veuillez vous référer à l’article An Introduction to Kubernetes pour plus de détails.

Étape 1 - Création d’un cluster Kubernetes local avec Minikube

Avant de configurer Minikube, vous devrez installer ses dépendances, y compris l’outil de ligne de commande Kubernetes kubectl, le relais de transfert de données bidirectionnel. socat et le programme de conteneur Docker.

Tout d’abord, assurez-vous que le gestionnaire de paquets de votre système peut accéder aux paquets via HTTPS avec + apt-transport-https +:

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

Ensuite, pour vous assurer que le téléchargement de kubectl est valide, ajoutez la clé GPG du référentiel Google officiel à votre système:

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

Une fois que vous avez ajouté la clé GPG, créez le fichier + / etc / apt / sources.list.d / kubernetes.list + en l’ouvrant dans votre éditeur de texte:

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

Une fois ce fichier ouvert, ajoutez la ligne suivante:

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

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

Cela montrera à votre système la source de téléchargement de kubectl. Une fois que vous avez ajouté la ligne, enregistrez et quittez le fichier. Pour ce faire, vous pouvez utiliser nano text editor en appuyant sur + CTRL + X +, en tapant + y + et en appuyant sur + + ENTER +.

Enfin, mettez à jour la liste des sources pour APT et installez + kubectl +, + socat + et + docker.io +:

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

Maintenant que vous avez installé kubectl, vous pouvez continuer avec installing Minikube. Premièrement, utilisez + curl + pour télécharger le binaire du programme:

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

Ensuite, modifiez les autorisations d’accès du fichier que vous venez de télécharger afin que votre système puisse l’exécuter:

chmod +x minikube

Enfin, copiez le fichier + minikube + dans le chemin d’exécutable sous + / usr / local / bin / + et supprimez le fichier original de votre répertoire personnel:

cp minikube /usr/local/bin/
rm minikube

Avec Minikube installé sur votre ordinateur, vous pouvez maintenant lancer le programme. Pour créer un cluster Minikube Kubernetes, utilisez la commande suivante:

minikube start --vm-driver none

L’indicateur + - vm-driver none + indique à Minikube d’exécuter Kubernetes sur l’hôte local à l’aide de conteneurs plutôt que d’une machine virtuelle. L’exécution de Minikube de cette façon signifie que vous n’avez pas besoin de télécharger un pilote de machine virtuelle, mais signifie également que le serveur d’API Kubernetes s’exécutera de manière non sécurisée en tant que root.

Maintenant que vous avez lancé Minikube, assurez-vous que votre cluster est en cours d’exécution avec la commande suivante:

minikube status

Vous recevrez le résultat suivant, avec votre adresse IP à la place de ++:

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

Maintenant que vous avez configuré votre cluster Kubernetes simulé à l’aide de Minikube, vous pouvez acquérir une expérience de la gestion de paquets Kubernetes en installant et en configurant le gestionnaire de paquets Helm au-dessus de votre cluster.

Étape 2 - Configuration du gestionnaire de packages Helm sur votre cluster

Afin de coordonner l’installation d’applications sur votre cluster Kubernetes, vous allez maintenant installer le gestionnaire de paquets Helm. Helm se compose d’un client + helm + qui s’exécute en dehors du cluster et d’un serveur + tiller + qui gère les versions des applications depuis le cluster. Vous devrez installer et configurer les deux pour pouvoir exécuter Helm avec succès sur votre cluster.

Pour installer les binaires de Helm, utilisez d’abord + curl + pour télécharger le https://raw.githubusercontent.com/helm suivant. / helm / master / scripts / get [script d’installation] du référentiel officiel Helm GitHub dans un nouveau fichier nommé + get_helm.sh +:

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

Comme ce script nécessite un accès root, modifiez l’autorisation de + get_helm.sh + afin que le propriétaire du fichier (dans ce cas, root) puisse le lire, l’écrire et l’exécuter:

chmod 700 get_helm.sh

Maintenant, exécutez le script:

./get_helm.sh

Une fois le script terminé, vous aurez installé + helm + sur + / usr / local / bin / helm + et + tiller + installé sur + / usr / local / bin / tiller +.

Bien que + tiller + soit maintenant installé, il ne dispose pas encore des rôles et autorisations appropriés pour accéder aux ressources nécessaires de votre cluster Kubernetes. Pour attribuer ces rôles et autorisations à + ​​tiller +, vous devrez créer un service account nommé + tiller + `. Dans Kubernetes, un compte de service représente une identité pour les processus exécutés dans un pod. Une fois qu’un processus est authentifié via un compte de service, il peut alors contacter le serveur API et accéder aux ressources du cluster. Si un pod ne reçoit pas de compte de service spécifique, il obtient le compte de service par défaut. Vous devrez également créer une règle Role-Based access control (RBAC) qui autorise le compte de service `+ tiller +.

Dans Kubernetes RBAC API, un role contient des règles qui déterminent un ensemble d’autorisations. Un rôle peut être défini avec une portée de + namespace + ou + cluster +, et ne peut accorder l’accès aux ressources que dans un seul espace de noms. + ClusterRole + peut créer les mêmes autorisations au niveau d’un cluster, en accordant un accès aux ressources à l’échelle du cluster, telles que les nœuds, et les ressources à espace de noms, telles que les pods. Pour attribuer le bon rôle au compte de service + tiller +, créez un fichier YAML appelé + rbac_helm.yaml + et ouvrez-le dans votre éditeur de texte:

nano rbac_helm.yaml

Ajoutez les lignes suivantes au fichier pour configurer le compte de service + tiller +:

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

Dans le fichier précédent, + ServiceAccount + permet aux processus + tiller + d’accéder à apiserver en tant que compte de service authentifié. + ClusterRole + accorde certaines autorisations à un rôle et + + ClusterRoleBinding + attribue ce rôle à une liste de + sujets +, y compris le compte de service + tiller +, les utilisateurs + admin + et + + kubelet + , et le groupe `+ system: serviceaccounts +.

Ensuite, déployez la configuration dans + rbac_helm.yaml + avec la commande suivante:

kubectl apply -f rbac_helm.yaml

Avec la configuration + tiller + déployée, vous pouvez maintenant initialiser Helm avec l’indicateur + - service-acount + pour utiliser le compte de service que vous venez de configurer:

helm init --service-account tiller

Vous recevrez le résultat suivant, représentant une initialisation réussie:

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!

Cela crée un pod + tiller dans l’espace de noms` + kube-system`. Il crée également le référentiel par défaut + .helm + dans votre répertoire + $ HOME + et configure le référentiel de diagrammes stable Helm par défaut à + ​​https: // kubernetes-charts.storage.googleapis.com + et le référentiel local Helm à + http: //127.0.0.1: 8879 / charts +.

Pour vous assurer que le pod + tiller est en cours d’exécution dans l’espace de noms` + kube-system`, entrez la commande suivante:

kubectl --namespace kube-system get pods

Dans votre liste de pods, + tiller-deploy + apparaîtra, comme indiqué dans la sortie suivante:

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

Si le statut du pod + tiller + est + Running +, il peut maintenant gérer les applications Kubernetes à partir de votre cluster pour le compte de Helm.

Pour vous assurer que toute l’application Helm fonctionne, recherchez dans les référentiels de packages Helm une application telle que MongoDB:

helm search mongodb

Dans la sortie, vous verrez une liste d’applications possibles qui correspondent à votre terme de recherche:

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

Maintenant que vous avez installé Helm sur votre cluster Kubernetes, vous pouvez en apprendre plus sur le gestionnaire de paquets en créant un exemple de graphique Helm et en déployant une application à partir de celui-ci.

Étape 3 - Création d’un graphique et déploiement d’une application avec Helm

Dans le gestionnaire de packages Helm, les packages individuels sont appelés charts. Dans un graphique, un ensemble de fichiers définit une application dont la complexité peut varier d’un pod à une application structurée à pile complète. Vous pouvez télécharger des graphiques à partir des référentiels Helm ou utiliser la commande + helm create + pour créer les vôtres.

Pour tester les capacités de Helm, créez un nouveau graphique Helm nommé + demo + avec la commande suivante:

helm create demo

Dans votre répertoire personnel, vous trouverez un nouveau répertoire appelé + demo +, dans lequel vous pourrez créer et éditer vos propres modèles de graphique.

Déplacez-vous dans le répertoire + demo + et utilisez + ls + pour lister son contenu:

cd demo
ls

Vous trouverez les fichiers et répertoires suivants dans + demo +:

demo

charts  Chart.yaml  templates  values.yaml

Avec votre éditeur de texte, ouvrez le fichier + Chart.yaml +:

nano Chart.yaml

À l’intérieur, vous trouverez le contenu suivant:

demo / Chart.yaml

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

Dans ce fichier + Chart.yaml +, vous trouverez des champs tels que + apiVersion +, qui doit toujours être + v1 +, un + description + qui donne des informations supplémentaires sur ce que + demo + est, le + nom + `du graphique et le nombre + version + `, que Helm utilise comme marqueur de publication. Lorsque vous avez terminé d’examiner le fichier, fermez votre éditeur de texte.

Ensuite, ouvrez le fichier + values.yaml +:

nano values.yaml

Dans ce dossier, vous trouverez le contenu suivant:

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: {}

En modifiant le contenu de + values.yaml +, les développeurs de graphiques peuvent fournir des valeurs par défaut pour l’application définie dans le graphique, en contrôlant le nombre de réplicas, la base d’images, l’accès en entrée, la gestion des secrets, etc. Les utilisateurs de graphique peuvent fournir leurs propres valeurs pour ces paramètres avec un fichier YAML personnalisé en utilisant + helm install +. Lorsqu’un utilisateur fournit des valeurs personnalisées, ces valeurs remplacent les valeurs du fichier + values.yaml + du graphique.

Fermez le fichier + values.yaml et répertoriez le contenu du répertoire` + templates` à l’aide de la commande suivante:

ls templates

Vous trouverez ici des modèles de différents fichiers pouvant contrôler différents aspects de votre graphique:

des modèles

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

Maintenant que vous avez exploré le diagramme + demo +, vous pouvez expérimenter l’installation de Helm chart en installant + demo +. Revenez dans votre répertoire personnel à l’aide de la commande suivante:

cd

Installez le diagramme + demo Helm sous le nom` + web` avec + helm install:

helm install --name  ./demo

Vous obtiendrez le résultat suivant:

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

Dans cette sortie, vous trouverez le + STATUS de votre application, ainsi qu’une liste des ressources pertinentes de votre cluster.

Ensuite, répertoriez les déploiements créés par le diagramme + demo + Helm avec la commande suivante:

kubectl get deploy

Cela donnera une sortie qui listera vos déploiements actifs:

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

Lister vos pods avec la commande + kubectl get pods + montrerait les pods exécutant votre application + web +, ce qui ressemblerait à ce qui suit:

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

Pour montrer comment les modifications apportées au diagramme Helm peuvent générer différentes versions de votre application, ouvrez + demo / values.yaml + dans votre éditeur de texte et modifiez + replicaCount: + en + 3 + et '+ image: tag : + de + stable + à + latest + `. Dans le bloc de code suivant, vous trouverez à quoi devrait ressembler le fichier YAML une fois que vous avez fini de le modifier, en mettant en évidence les modifications:

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

Enregistrez et quittez le fichier.

Avant de déployer cette nouvelle version de votre application + web +, répertoriez les versions de Helm telles qu’elles sont maintenant avec la commande suivante:

helm list

Vous recevrez le résultat suivant, avec le déploiement que vous avez créé précédemment:

OutputNAME    REVISION        UPDATED                         STATUS          CHART           APP VERSION     NAMESPACE

Notez que + REVISION + est répertorié comme + 1 +, indiquant qu’il s’agit de la première révision de l’application + web +.

Pour déployer l’application + web + avec les dernières modifications apportées à + ​​demo / values.yaml +, mettez à niveau l’application avec la commande suivante:

helm upgrade web ./demo

Maintenant, listez à nouveau les communiqués de Helm:

helm list

Vous recevrez le résultat suivant:

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

Notez que + REVISION + a été remplacé par + 2 +, indiquant qu’il s’agit de la deuxième révision.

Pour trouver l’historique des versions de Helm pour + web +, utilisez ce qui suit:

helm history web

Cela montrera les deux révisions de l’application + web +:

Sortie

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

Pour restaurer votre application en révision + 1 +, entrez la commande suivante:

helm rollback web 1

Cela donnera la sortie suivante:

OutputRollback was a success! Happy Helming!

Maintenant, ouvrez l’historique des versions de Helm:

helm history web

Vous recevrez la liste suivante:

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

En rétablissant l’application + web +, vous avez créé une troisième révision avec les mêmes paramètres que la révision + 1 +. N’oubliez pas que vous pouvez toujours savoir quelle révision est active en recherchant l’élément + DEPLOYED + sous + STATUS +.

Pour préparer la section suivante, nettoyez votre zone de test en supprimant votre version + web à l’aide de la commande` + helm delete`:

helm delete web

Examinez à nouveau l’historique des versions de Helm:

helm history web

Vous recevrez le résultat suivant:

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

Le + STATUS + pour + REVISION 3 + a été remplacé par + DELETED +, ce qui indique que votre instance déployée de + web + a été supprimée. Cependant, bien que cela supprime la version, il ne la supprime pas du magasin. Afin de supprimer complètement la version, exécutez la commande + helm delete avec l’indicateur` + - purge`.

helm delete web --purge

Dans cette étape, vous avez géré les versions d’application sur Kubernetes avec Helm. Si vous souhaitez approfondir vos connaissances sur Helm, consultez notre An Introduction to Helm, the Gestionnaire de paquets pour Kubernetes ou consultez la documentation officielle Helm.

Vous allez ensuite configurer et tester l’outil d’automatisation de pipeline Jenkins X à l’aide de la CLI + jx + pour créer un cluster Kubernetes prêt pour le CI / CD.

Étape 4 - Configuration de l’environnement Jenkins X

Avec Jenkins X, vous pouvez créer votre cluster Kubernetes à partir de zéro avec l’automatisation des pipelines et les solutions CI / CD intégrées. En installant l’outil CLI + jx +, vous serez en mesure de gérer efficacement les versions des applications, les images Docker et les graphiques Helm, en plus de promouvoir automatiquement vos applications dans les environnements de GitHub.

Puisque vous utiliserez + jx + pour créer votre cluster, vous devez d’abord supprimer le cluster Minikube que vous avez déjà. Pour ce faire, utilisez la commande suivante:

minikube delete

Cela supprimera le cluster Kubernete simulé local, mais pas les répertoires par défaut créés lors de la première installation de Minikube. Pour les nettoyer de votre ordinateur, utilisez les commandes suivantes:

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

Une fois que vous avez complètement vidé Minikube de votre ordinateur, vous pouvez installer le binaire Jenkins X.

Commencez par télécharger le fichier + jx + compressé à partir du référentiel officiel Jenkins X GitHub avec la commande + curl + et décompressez-le avec la commande + tar +:

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

Ensuite, déplacez le fichier + js téléchargé vers le chemin de l’exécutable sous` + / usr / local / bin`:

mv jx /usr/local/bin

Jenkins X est livré avec un registre Docker qui s’exécute dans votre cluster Kubernetes. S’agissant d’un élément interne, les mesures de sécurité telles que les certificats auto-signés peuvent causer des problèmes au programme. Pour résoudre ce problème, configurez Docker pour qu’il utilise des registres non sécurisés pour la plage d’adresses IP locale. Pour ce faire, créez le fichier + / etc / docker / daemon.json et ouvrez-le dans votre éditeur de texte:

nano /etc/docker/daemon.json

Ajoutez le contenu suivant au fichier:

/etc/docker/daemon.json

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

Enregistrez et quittez le fichier. Pour que ces modifications prennent effet, redémarrez le service Docker à l’aide de la commande suivante:

systemctl restart docker

Pour vérifier que vous avez configuré Docker avec des registres non sécurisés, utilisez la commande suivante:

docker info

À la fin de la sortie, vous devriez voir la ligne en surbrillance suivante:

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

Maintenant que vous avez téléchargé Jenkins X et configuré le registre Docker, utilisez l’outil CLI + jx + pour créer un cluster Minikube Kubernetes doté de fonctionnalités CI / CD:

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

Ici, vous créez un cluster Kubernetes avec Minikube, avec le drapeau + - cpu = 5 + pour définir 5 CPU et + - memory = 13314 + pour donner à votre cluster 13314 MB de mémoire. Jenkins X étant un programme robuste mais volumineux, ces spécifications permettront à Jenkins X de fonctionner sans problème dans cette démonstration. De plus, vous utilisez + - default-admin-password = admin + pour définir le mot de passe Jenkins X comme + admin + et + - vm-driver = none + pour configurer le cluster localement, comme vous l’avez fait auparavant. Étape 1.

Au fur et à mesure que Jenkins X optimise votre cluster, vous recevez diverses invites à différents moments du processus, qui définissent les paramètres de votre cluster et déterminent son mode de communication avec GitHub pour la gestion de vos environnements de production.

Tout d’abord, vous recevrez l’invite suivante:

Output? disk-size (MB) 150GB

Appuyez sur + ENTER pour continuer. Ensuite, vous serez invité à entrer le nom que vous souhaitez utiliser avec git, l’adresse e-mail que vous souhaitez utiliser avec git et votre nom d’utilisateur GitHub. Entrez chacun de ceux-ci lorsque vous y êtes invité, puis appuyez sur + ENTER +.

Ensuite, Jenkins X vous demandera d’entrer votre jeton d’API GitHub:

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:

Entrez votre jeton ici ou créez un nouveau jeton avec les autorisations appropriées en utilisant l’URL en surbrillance dans le bloc de code précédent.

Ensuite, Jenkins X demandera:

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)

Entrez + Y + pour les deux questions.

Après cela, Jenkins X vous invitera à répondre aux questions suivantes:

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

Pour le précédent, sélectionnez + Static Master Jenkins +, et sélectionnez + Kubernetes Workloads: CD automatisé CI + avec GitOps Promotion + pour ce dernier. Lorsque vous êtes invité à sélectionner une organisation pour votre référentiel d’environnement, sélectionnez votre nom d’utilisateur GitHub.

Enfin, vous recevrez le résultat suivant, qui vérifie la réussite de l’installation et fournit votre mot de passe administrateur Jenkins X.

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

Ensuite, utilisez la commande + js get pour recevoir une liste d’URL contenant des informations sur votre application:

jx get urls

Cette commande donnera une liste semblable à la suivante:

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

Vous pouvez utiliser les URL pour afficher les données Jenkins X relatives à votre environnement CI / CD via une interface utilisateur en saisissant l’adresse dans votre navigateur, ainsi que votre nom d’utilisateur et votre mot de passe. Dans ce cas, ce sera “admin” pour les deux.

Ensuite, afin de vous assurer que les comptes de service des espaces de noms + jx +, + jx-staging + et + jx-production + ont des privilèges d’administrateur, modifiez vos stratégies RBAC à l’aide des commandes suivantes:

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

Maintenant que vous avez créé votre cluster Kubernetes local avec les fonctionnalités Jenkins X intégrées, vous pouvez créer une application sur la plate-forme pour tester ses capacités CI / CD et expérimenter un pipeline Jenkins X.

Étape 5 - Création d’une application de test dans votre environnement Jenkins X

Avec votre environnement Jenkins X configuré dans votre cluster Kubernetes, vous disposez maintenant d’une infrastructure CI / CD en place qui peut vous aider à automatiser un pipeline de tests. Dans cette étape, vous allez essayer ceci en configurant une application de test dans un pipeline Jenkins X opérationnel.

À des fins de démonstration, ce didacticiel utilisera un exemple d’application RSVP créé par l’équipe CloudYuga. Vous pouvez trouver cette application, ainsi que d’autres documents Webinaires, dans le référentiel DO-Community GitHub.

Tout d’abord, clonez l’exemple d’application à partir du référentiel avec la commande suivante:

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

Une fois le référentiel cloné, accédez au répertoire + rsvpapp + et supprimez les fichiers git:

cd rsvpapp
rm -r .git/

Pour initialiser un référentiel git et un projet Jenkins X pour une nouvelle application, vous pouvez utiliser + jx create + pour recommencer à zéro ou un modèle, ou + jx import + pour importer une application existante à partir d’un projet local ou d’un référentiel git. Pour ce tutoriel, importez l’application exemple RSVP en exécutant la commande suivante à partir du répertoire de base de l’application:

jx import

Jenkins X vous demandera votre nom d’utilisateur GitHub, si vous souhaitez initialiser Git, un message de validation, votre organisation et le nom que vous souhaitez pour votre référentiel. Répondez oui pour initialiser git, puis fournissez le reste des invites avec vos informations et préférences individuelles GitHub. Lorsque Jenkins X importe l’application, des diagrammes Helm et un fichier Jenkins sont créés dans le répertoire personnel de votre application. Vous pouvez modifier ces graphiques et le fichier Jenkins selon vos besoins.

Étant donné que l’exemple d’application RSVP s’exécute sur le port + 5000 + de son conteneur, modifiez votre fichier + charts / rsvpapp / values.yaml + en conséquence. Ouvrez le + charts / rsvpapp / values.yaml + dans votre éditeur de texte:

nano charts/rsvpapp/values.yaml

Dans ce fichier + values.yaml +, définissez + service: internalPort: + à + ​​5000 +. Une fois que vous avez apporté cette modification, votre fichier devrait ressembler à ceci:

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

Enregistrez et quittez votre fichier.

Ensuite, changez le + charts / preview / Requirements.yaml + pour qu’il s’adapte à votre application. + Requirements.yaml + est un fichier YAML dans lequel les développeurs peuvent déclarer des dépendances de diagramme, ainsi que l’emplacement du diagramme et la version souhaitée. Étant donné que notre exemple d’application utilise MongoDB à des fins de base de données, vous devez modifier le fichier + charts / preview / requirements.yaml + pour répertorier MongoDB en tant que dépendance. Ouvrez le fichier dans votre éditeur de texte avec la commande suivante:

nano charts/preview/requirements.yaml

Editez le fichier en ajoutant l’entrée + mongodb-replicaset + après l’entrée + alias: cleanup +, comme indiqué dans le bloc de code suivant:

diagrammes / aperçu / conditions.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

Ici, vous avez spécifié le graphique + mongodb-replicaset + en tant que dépendance du graphique + preview +.

Ensuite, répétez cette procédure pour votre graphique + rsvpapp +. Créez le fichier + charts / rsvpapp / requirements.yaml + et ouvrez-le dans votre éditeur de texte:

nano charts/rsvpapp/requirements.yaml

Une fois le fichier ouvert, ajoutez ce qui suit en vous assurant qu’il ne reste qu’une seule ligne d’espace vide avant et après les lignes remplies:

charts / rsvpapp / requirements.yaml

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

Vous avez maintenant spécifié le graphique + mongodb-replicaset + en tant que dépendance pour votre graphique + rsvpapp +.

Ensuite, afin de connecter le client de l’exemple d’application RSVP au serveur MongoDB, ajoutez une variable d’environnement + MONGODB_HOST + à votre fichier + deployment.yaml + dans + charts / rsvpapp / templates / +. Ouvrez ce fichier dans votre éditeur de texte:

nano charts/rsvpapp/templates/deployment.yaml

Ajoutez les lignes en surbrillance suivantes au fichier, en plus d’une ligne vierge en haut du fichier et de deux lignes vides en bas du fichier. Notez que ces lignes vierges sont nécessaires pour que le fichier YAML fonctionne:

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

Grâce à ces modifications, Helm pourra déployer votre application avec MongoDB comme base de données.

Ensuite, examinez le + Jenkinsfile + généré par Jenkins X en ouvrant le fichier à partir du répertoire de base de votre application:

nano Jenkinsfile

Ce + Jenkinsfile + définit le pipeline qui est déclenché chaque fois que vous validez une version de votre application dans votre référentiel GitHub. Si vous souhaitez automatiser vos tests de code afin que les tests soient déclenchés chaque fois que le pipeline est déclenché, vous devez ajouter le test à ce document.

Pour illustrer cela, ajoutez un scénario de test personnalisé en remplaçant + sh" python -m unittest "+" sous `+ stage ('CI Build and push snapshot') + et + stage ('Build Release') + dans le + Jenkinsfile + avec les lignes en surbrillance suivantes:

/ 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)"
       }
     }
   }
. . .

Avec les lignes ajoutées, le pipeline Jenkins X installera des dépendances et effectuera un test Python chaque fois que vous validerez une modification de votre application.

Maintenant que vous avez modifié l’exemple d’application RSVP, validez et transmettez ces modifications à GitHub à l’aide des commandes suivantes:

git add *
git commit -m update
git push

Lorsque vous transmettez ces modifications à GitHub, vous déclenchez une nouvelle version de votre application. Si vous ouvrez l’interface utilisateur Jenkins en accédant à + ​​http: // jenkins.jx..nip.io + et en entrant «admin» pour votre nom d’utilisateur et votre mot de passe, vous obtiendrez des informations sur votre nouvelle version. Si vous cliquez sur «Historique de la construction» dans le menu situé à gauche de la page, vous devriez voir l’historique de vos générations validées. Si vous cliquez sur l’icône bleue à côté d’une construction, puis sélectionnez «Sortie de la console» dans le menu de gauche, vous trouverez la sortie de la console pour les étapes automatisées de votre pipeline. En faisant défiler jusqu’à la fin de cette sortie, vous trouverez le message suivant:

Output. . .
Finished: SUCCESS

Cela signifie que votre application a réussi vos tests personnalisés et est maintenant déployée avec succès.

Une fois que Jenkins X aura créé la version de l’application, l’application sera promue dans l’environnement + staging +. Pour vérifier que votre application est en cours d’exécution, répertoriez les applications en cours d’exécution sur votre cluster Kubernetes à l’aide de la commande suivante:

jx get app

Vous recevrez une sortie similaire à celle-ci:

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

À partir de là, vous pouvez constater que Jenkins X a déployé votre application dans votre environnement + jx-staging + en tant que version + 0.0.2 +. La sortie affiche également l’URL que vous pouvez utiliser pour accéder à votre application. Visiter cette URL vous montrera l’exemple d’application RSVP:

image: https: //assets.digitalocean.com/articles/cart_64885/Sample_App_jx-staging.png [Exemple d’application RSVP dans l’environnement de transfert]

Ensuite, vérifiez l’activité de votre application avec la commande suivante:

jx get activity -f rsvpapp

Vous recevrez une sortie similaire à celle-ci:

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

Ici, vous obtenez l’activité Jenkins X pour l’application RSVP en appliquant un filtre avec + -f rsvpapp +.

Ensuite, répertoriez les pods s’exécutant dans l’espace de noms + jx-staging + à l’aide de la commande suivante:

kubectl get pod -n jx-staging

Vous recevrez une sortie similaire à celle-ci:

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

Cette sortie montre que votre application s’exécute dans l’espace de noms + jx-staging +, avec trois pods de la base de données MongoDB dorsale, conformément aux modifications apportées aux fichiers YAML précédemment.

Maintenant que vous avez exécuté une application de test via le pipeline Jenkins X, vous pouvez essayer de promouvoir cette application dans l’environnement de production.

Étape 6 - Promotion de votre application de test vers un autre espace de noms

Pour terminer cette démonstration, vous allez terminer le processus CI / CD en faisant la promotion de l’exemple d’application RSVP dans votre espace de noms + jx-production +.

Tout d’abord, utilisez + jx promotion + dans la commande suivante:

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

Cela favorisera l’application + rsvpapp + s’exécutant avec + version = 0.0.2 + dans l’environnement de production. Tout au long du processus de création, Jenkins X vous invitera à saisir les informations relatives à votre compte GitHub. Répondez à ces invites avec vos réponses individuelles telles qu’elles apparaissent.

Après une promotion réussie, consultez la liste des applications:

jx get app

Vous recevrez une sortie similaire à celle-ci:

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

Avec ces informations + PRODUCTION, vous pouvez confirmer que Jenkins X a promu` + rsvp app` dans l’environnement de production. Pour plus de vérification, visitez l’URL de production + http: // rsvpapp.jx-production..nip.io + dans votre navigateur. Vous devriez voir l’application opérationnelle ne fonctionnant pas à partir de «production»:

image: https: //assets.digitalocean.com/articles/cart_64885/Sample_App_jx-production.png [Exemple d’application RSVP dans l’environnement de production]

Pour finir, listez vos pods dans l’espace de noms + jx-production +.

kubectl get pod -n jx-production

Vous constaterez que + rsvpapp + et les modules dorsaux MongoDB sont en cours d’exécution dans cet espace de noms:

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

Cela montre que vous avez promu l’exemple d’application RSVP dans votre environnement de production, en simulant le déploiement prêt à la production d’une application à la fin d’un pipeline CI / CD.

Conclusion

Dans ce tutoriel, vous avez utilisé Helm pour gérer des packages sur un cluster Kubernetes simulé et personnalisé un diagramme Helm pour créer un package et déployer votre propre application. Vous configurez également un environnement Jenkins X sur votre cluster Kubernetes et exécutez un exemple d’application via un pipeline CI / CD, du début à la fin.

Vous avez maintenant une expérience de ces outils que vous pouvez utiliser lors de la construction d’un système CI / CD sur votre propre cluster Kubernetes. Si vous souhaitez en savoir plus sur Helm, consultez notre An Introduction à Helm , le gestionnaire de paquets pour Kubernetes et Comment installer le logiciel sur les clusters Kubernetes avec le gestionnaire de paquets Helm. Pour explorer d’autres outils CI / CD sur Kubernetes, vous pouvez en savoir plus sur le maillage de service Istio dans le prochain tutoriel de cette série de webinaires.

Related