Blog ENI : Toute la veille numérique !
🎁 Jusqu'au 31/12, recevez notre
offre d'abonnement à la Bibliothèque Numérique. Cliquez ici
🎁 Jusqu'au 31/12, recevez notre
offre d'abonnement à la Bibliothèque Numérique. Cliquez ici
  1. Livres et vidéos
  2. Kubernetes
  3. Helm
Extrait - Kubernetes Gérez la plateforme de déploiement de vos applications conteneurisées (3e édition)
Extraits du livre
Kubernetes Gérez la plateforme de déploiement de vos applications conteneurisées (3e édition) Revenir à la page d'achat du livre

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 package 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.15.2-linux-amd64.tar.gz 
13.23 MiB / 13.23 MiB [------------------------------------] 100.00% 
/tmp/helm-v3.15.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.14.2 (ne pas oublier le petit v) :

$ arkade get helm@v3.14.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 à l’aide des commandes suivantes :...

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 conteneur de présentation ;

  • mise en correspondance du port 8080 de la machine locale avec le port 8080 du conteneur 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 conteneur 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 conteneur.

N’hésitez pas à changer la valeur du port d’écoute (8081, par exemple)...