Editions ENI Livres | Vidéos | e-Formations
Helm - Gestionnaire de package
Objectifs du chapitre et prérequis
Pour aborder ce chapitre, vous devez maîtriser les concepts qui ont été vus dans les chapitres précédents et particulièrement la manipulation des éléments dans Kubernetes ainsi que certaines notions comme les espaces de noms (namespace) ou les déploiements (deployment, pod).
Ce chapitre a pour but de présenter et mettre en place le gestionnaire de packages Helm.
Présentation de Helm
1. Pourquoi faire appel à Helm ?
Helm a été introduit par la communauté afin de répondre à un besoin de simplification de l’installation des logiciels dans un cluster Kubernetes. Avant l’arrivée de ce mécanisme, l’administrateur devait gérer lui-même le cycle de vie des fichiers YAML, leur personnalisation ainsi que l’intégration des produits en eux-mêmes.
Un cluster Kubernetes fonctionne à l’aide de nombreux produits (Elasticsearch, Prometheus, Grafana, Nginx, etc.). Les maîtriser tous peut être chronophage.
Les charts Helm sont une aide précieuse pour s’affranchir des problématiques d’installation initiale.
On parle de chart Helm dans le cas des packages Helm.
2. Principe de fonctionnement
En version 3, Helm fonctionne à l’aide d’un client écrit en Go. Ce dernier s’appuie sur l’API de Kubernetes. Le programme se présente sous la forme d’un binaire autoporteur et ne réclame aucune dépendance (pas même le binaire kubectl).
Auparavant, la version 2 de Helm utilisait une partie serveur (Tiller). N’utilisez pas cette solution : outre le fait que tout ceci est obsolète (Helm 3 est sorti en fin d’année 2019), ce fonctionnement pose des problèmes de sécurité.
Déploiement de Helm
1. Installation du client Helm
a. Installation à l’aide d’Arkade
L’option la plus simple est de faire appel à la commande arkade suivie de l’option get et du nom du paquet à récupérer :
$ arkade get helm L’outil procède alors au téléchargement de la dernière version et renvoie le message suivant :
Downloading: helm
Downloading: https://get.helm.sh/helm-v3.7.2-linux-amd64.tar.gz
13.23 MiB / 13.23 MiB [------------------------------------] 100.00%
/tmp/helm-v3.7.2-linux-amd64.tar.gz written.
/tmp/linux-amd64 linux-amd64/
...
Tool written to: /home/yannig/.arkade/bin/helm
... Pour installer une version spécifique, ajoutez un arobase (@) derrière le nom du paquet suivi de la référence à installer.
Ici, un exemple d’installation de la version v3.7.2 (ne pas oublier le petit v) :
$ arkade get helm@v3.7.2 b. Installation manuelle
L’installation manuelle se déroule de la manière suivante :
-
Récupérez le binaire correspondant au système/architecture : https://github.com/helm/helm/releases
-
Décompressez le binaire.
-
Mettez à disposition le binaire dans les chemins d’exécution.
Sous Linux (architecture amd64), ces opérations peuvent être réalisées à...
Déploiement d’une application avec Helm
1. Déterminer le package à déployer
a. Recherche d’un chart Helm
Le binaire Helm est présent : il est temps de réaliser un premier déploiement.
En premier lieu, il faut déterminer le package à déployer. WordPress sera la première application installée.
Ce logiciel est composé de deux briques :
-
Une partie frontale de présentation (basée sur PHP).
-
Une partie de stockage des données (basée sur MariaDB).
Avant d’installer une application, il faut chercher si un package remplit ce service.
Cette recherche se fait en utilisant la commande helm avec le mot-clé search repo suivi du motif à rechercher :
$ helm search repo wordpress Dans le jargon de Helm, on parle d’un chart pour désigner un paquet.
Toutefois, lors d’un premier lancement, cette commande ne renvoie rien. En effet, par défaut Helm ne dispose d’aucune source de paquets.
b. Gestion des sources de charts Helm
Dans les anciennes versions de Helm v2, la source de paquets stable était configurée par défaut. Depuis la version 3, ce n’est plus le cas et il faut les ajouter soi-même.
Dans le cas d’une installation de WordPress, Bitnami met à disposition un ensemble de paquets parfaits pour la suite de l’exercice à l’adresse https://charts.bitnami.com/bitnami.
Bitnami est un projet qui vise à mettre à disposition un ensemble de solutions libres (WordPress, Drupal, Redmine, Mediawiki, etc.). Son développement est soutenu par la société espagnole Bitrock. Cette dernière a fait l’objet d’une acquisition par VMware en mai 2019.
L’ajout d’une source se fait à l’aide de la commande helm et des options suivantes :
-
Les mots-clés repo add.
-
Le nom du dépôt à ajouter (bitnami par exemple).
-
L’adresse du dépôt de charts Helm.
Ci-dessous la commande complète à utiliser :
$ helm repo add bitnami https://charts.bitnami.com/bitnami La commande renverra le message suivant :
"bitnami" has been added to your repositories Dans le cas où le dépôt existerait déjà avec la même adresse, la commande renverra le message suivant :...
Cycle de vie d’une application déployée avec Helm
1. Ouverture du port vers WordPress
L’application est prête à fonctionner. Il est possible d’accéder au serveur WordPress via le port 8080 du pod de présentation en suivant cette procédure :
-
Récupération du nom du pod associé au container de présentation.
-
Mise en correspondance du port 8080 de la machine locale avec le port 8080 du container de présentation.
Récupérez la liste des pods de l’espace de noms intranet à l’aide de la commande suivante :
$ kubectl -n intranet get pods Ci-dessous le résultat de la commande :
NAME READY STATUS RESTARTS AGE
wordpress-compta-799d8d7b7d-mbsgx 1/1 Running 0 22m
wordpress-compta-mariadb-0 1/1 Running 0 22m Récupérez également le déploiement présent dans le même espace de noms :
$ kubectl -n intranet get deployment Ci-dessous le résultat attendu :
NAME READY UP-TO-DATE AVAILABLE AGE
wordpress-compta 1/1 1 1 24m La connexion au container de WordPress va se faire à l’aide de kubectl suivie par les options suivantes :
-
L’option port-forward.
-
La référence du déploiement deployment/wordpress-compta.
-
Le port d’écoute en local (8080) suivi du caractère deux-points (:) suivi du port 8080 correspondant au port utilisé par le container.
N’hésitez pas à changer la valeur du port d’écoute (8081, par exemple) dans...
