Helm : gérer les paquets dans Kubernetes
Auteur : Rédaction Domeny.ForSale Publié le
En bref : Helm est un gestionnaire de paquets pour Kubernetes : il facilite l’installation, la configuration et la mise à jour des applications dans un cluster. Au lieu de gérer séparément de nombreux fichiers décrivant l’application, vous utilisez un paquet appelé chart auquel vous fournissez vos propres paramètres. Helm aide aussi à suivre les déploiements successifs, mais ne remplace pas Kubernetes et ne garantit pas qu’une mise à jour sera sans risque.
Quel problème Helm résout-il ?
Kubernetes est un système qui exécute et gère des applications dans des conteneurs. Un cluster, c’est-à-dire un environnement composé de machines gérées par Kubernetes, a besoin d’une description de ce qu’il doit exécuter. Cette description prend le plus souvent la forme de manifestes : des fichiers YAML définissant des ressources, par exemple un Deployment qui gère les instances de l’application ou un Service qui permet de s’y connecter.
Une application peut nécessiter plusieurs ressources de ce type, parfois plus d’une dizaine. Si vous l’exécutez séparément dans un environnement de test et en production, certains paramètres seront communs, d’autres différents : nombre d’instances, adresse du domaine, version de l’image du conteneur ou limites de mémoire. Copier les manifestes à la main complique le maintien de leur cohérence.
Helm permet de regrouper les modèles de ces ressources dans un seul paquet. À partir des modèles et de la configuration, il génère des manifestes, puis les transmet à Kubernetes. Le principe ressemble à celui d’un gestionnaire de paquets pour un système d’exploitation, sauf que Helm gère les ressources du cluster, et non des programmes installés sur un ordinateur portable.
Chart, release et values : trois notions essentielles
Un chart est un paquet Helm contenant des modèles de ressources Kubernetes, des paramètres par défaut et des informations sur le paquet. Il peut décrire une application unique ou un ensemble de composants liés. Un chart peut aussi avoir des dépendances, c’est-à-dire utiliser d’autres charts.
Une release est une installation précise d’un chart dans le cluster, dotée de son propre nom. Vous pouvez installer plusieurs fois le même chart, par exemple sous les noms boutique-test et boutique-prod, avec des paramètres différents. Une release ne désigne donc pas simplement une version de l’application : elle identifie un déploiement géré par Helm.
Les values sont les valeurs de configuration injectées dans les modèles. Un chart contient généralement un fichier par défaut values.yaml, et l’utilisateur peut fournir un fichier supplémentaire avec ses propres paramètres. Les noms des paramètres disponibles dépendent du chart : Helm n’impose pas de champ universel pour configurer toutes les applications.
Voici un exemple de structure pour un chart simple :
mon-application/
├── Chart.yaml
├── values.yaml
└── templates/
├── deployment.yaml
└── service.yaml
Le fichier Chart.yaml décrit le paquet, values.yaml contient la configuration par défaut et le répertoire templates contient les modèles. La version du chart et celle de l’application sont deux choses différentes : modifier la manière de déployer l’application n’implique pas nécessairement de modifier le programme lui-même.
Comment se déroule un déploiement avec Helm ?
Supposons qu’une équipe assure la maintenance d’une application de boutique. Elle a besoin d’une instance dans l’environnement de test et de trois en production. Elle peut utiliser un chart unique et deux fichiers de configuration, plutôt que de créer deux copies indépendantes des manifestes.
Si le chart propose le paramètre replicaCount, le fichier values-test.yaml peut contenir :
replicaCount: 1
L’exemple suivant suppose que Helm est installé, que vous avez accès au cluster et que vous disposez d’un chart local dans le répertoire mon-application. Vous pouvez d’abord générer les manifestes sans installer l’application :
helm template boutique-test ./mon-application -f values-test.yaml
Cela permet de vérifier le résultat produit par les modèles, mais ne confirme pas encore que le cluster acceptera toutes les ressources ni que l’application fonctionnera. Pour installer ou mettre à jour la release, utilisez la commande :
helm upgrade --install boutique-test ./mon-application \
-f values-test.yaml --namespace test --create-namespace
Un namespace est un espace qui sépare logiquement des ressources au sein du cluster. L’option --install permet l’installation si la release n’existe pas encore ; sinon, la commande la met à jour. Avant de l’exécuter, vérifiez le contexte Kubernetes actif pour ne pas déployer accidentellement l’application en production.
Mises à jour et limites du retour en arrière
Helm conserve l’historique des révisions successives d’une release, autrement dit des modifications de son déploiement. La commande helm history boutique-test -n test affiche cet historique, et helm rollback permet de revenir à une révision antérieure.
Un rollback n’est pas une sauvegarde de l’application ni de ses données. Rétablir une configuration antérieure des ressources n’annule pas automatiquement une migration de base de données, des modifications effectuées dans un service externe ou les effets de l’exécution du programme. Pour mettre à jour une application qui stocke des données, il faut prévoir séparément les sauvegardes et la compatibilité des versions.
Helm ne dispense pas non plus de comprendre Kubernetes. Des limites de ressources inadaptées, l’absence des autorisations requises ou une image de conteneur incorrecte peuvent empêcher l’application de démarrer, que les manifestes aient été rédigés à la main ou générés à partir d’un chart.
Quand choisir Helm et comment évaluer un chart existant ?
Helm est utile si vous répétez les déploiements, gérez plusieurs environnements ou installez une application composée de nombreuses ressources. Pour quelques manifestes simples et rarement modifiés, il peut ajouter une couche de modèles superflue. Kustomize peut être une alternative : il adapte les manifestes existants au lieu d’utiliser les modèles de Helm.
Avant d’utiliser un chart existant, vérifiez sa provenance, sa documentation, les versions de Kubernetes requises, les autorisations et la manière dont il gère les données persistantes. Examinez les manifestes générés, en particulier les ressources qui accordent des autorisations et les services qui rendent l’application accessible depuis l’extérieur du cluster. Les mots de passe inscrits dans le fichier values ne deviennent pas sûrs simplement parce que vous utilisez Helm : ne les enregistrez pas dans un dépôt de code ordinaire.
Pour commencer, choisissez un environnement de test et un seul chart. Vérifiez les paramètres disponibles dans la documentation de la version exacte de ce chart, puis testez l’installation, la mise à jour et le comportement des données lors d’un retour en arrière.
À lire aussi : Qu’est-ce que Brave ?
À lire aussi
