Contactez-nous

Gérer des applications avec les commandes Helm (install, upgrade, rollback)

Maîtrisez les commandes Helm essentielles (install, upgrade, rollback, list, status, uninstall) pour déployer, mettre à jour et gérer le cycle de vie complet de vos applications sur Kubernetes.

Piloter le cycle de vie de vos applications avec Helm CLI

Maintenant que nous comprenons les concepts de Charts, Releases et Repositories, il est temps de passer à la pratique et d'explorer les commandes Helm fondamentales qui vous permettent de gérer activement le cycle de vie de vos applications déployées sur Kubernetes. Le client Helm (la commande helm) est votre interface principale pour interagir avec les Releases.

De l'installation initiale à la mise à jour, en passant par la consultation de l'état et même le retour en arrière en cas de problème, Helm fournit un ensemble cohérent de commandes pour orchestrer ces opérations de manière fiable et reproductible. Maîtriser ces commandes est essentiel pour exploiter pleinement les avantages de Helm.

Déployer une nouvelle application : `helm install`

La commande helm install est utilisée pour déployer un Chart sur votre cluster Kubernetes, ce qui crée une nouvelle Release.

La syntaxe de base est :

helm install [NOM_RELEASE] [CHART] [flags]
  • [NOM_RELEASE] : C'est le nom que vous donnez à cette instance spécifique du déploiement (la Release). Ce nom doit être unique au sein du namespace cible. Si vous l'omettez, Helm en générera un automatiquement (par exemple, my-chart-1678886400), mais il est fortement recommandé d'en fournir un explicite pour une meilleure gestion.
  • [CHART] : Spécifie le Chart à installer. Il peut s'agir de :
    • Le nom d'un Chart dans un repository ajouté (par exemple, bitnami/redis).
    • Le chemin vers un Chart décompressé sur votre système de fichiers local (par exemple, ./mon-app-chart).
    • Le chemin vers une archive de Chart packagée (par exemple, mon-app-chart-0.1.0.tgz).
    • Une URL complète vers une archive de Chart (par exemple, https://example.com/charts/mon-app-chart-0.1.0.tgz).
    • Une référence OCI (par exemple, oci://myregistry.com/charts/my-chart).
  • [flags] : Permettent de personnaliser l'installation :
    • -n ou --namespace : Spécifie le namespace dans lequel installer la Release. S'il n'est pas fourni, le namespace courant du contexte kubeconfig est utilisé.
    • --create-namespace : Crée le namespace s'il n'existe pas déjà.
    • -f ou --values : Fournit un fichier YAML contenant les valeurs pour surcharger celles par défaut du Chart. Peut être utilisé plusieurs fois.
    • --set = : Surcharge une valeur spécifique directement en ligne de commande (par exemple, --set replicaCount=3).
    • --version : Spécifie une version exacte du Chart à installer depuis un repository.
    • --dry-run : Simule l'installation, affiche les manifestes qui seraient générés, mais ne les applique pas au cluster. Très utile pour vérifier le résultat du templating et des valeurs.
    • --debug : Active une sortie plus verbeuse, utile pour le débogage.

Exemple complet :

helm install mon-wordpress-prod bitnami/wordpress \ 
  --namespace prod \ 
  --create-namespace \ 
  -f prod-values.yaml \ 
  --set wordpressPassword=unMotDePasseTresSecret

Après une installation réussie, Helm affiche généralement des informations utiles définies dans le fichier templates/NOTES.txt du Chart (par exemple, comment accéder à l'application).

Mettre à jour une application : `helm upgrade`

La commande helm upgrade est utilisée pour mettre à jour une Release existante. Cela peut impliquer de passer à une nouvelle version du Chart ou de modifier les valeurs de configuration de la Release actuelle.

La syntaxe de base est très similaire à `install` :

helm upgrade [NOM_RELEASE] [CHART] [flags]
  • [NOM_RELEASE] : Le nom de la Release existante à mettre à jour.
  • [CHART] : Le Chart (potentiellement une nouvelle version) à utiliser pour la mise à jour.
  • [flags] : De nombreux flags sont identiques à helm install (-n, -f, --set, --version, --dry-run, --debug).

Lors d'un upgrade, Helm compare la nouvelle configuration (nouveau Chart et/ou nouvelles valeurs) avec la dernière révision de la Release. Il calcule les changements nécessaires aux ressources Kubernetes et applique ces changements via l'API Server. Chaque upgrade réussi crée une nouvelle révision de la Release, conservant l'historique des modifications.

Une option très utile est --install (ou -i). Si vous exécutez helm upgrade --install [NOM_RELEASE] [CHART], Helm mettra à jour la Release si elle existe, mais l'installera si elle n'existe pas encore. C'est pratique pour les scripts d'automatisation (comportement "upsert").

Exemple : Mettre à jour la Release `mon-wordpress-prod` vers la dernière version du Chart et changer le type de Service :

helm upgrade mon-wordpress-prod bitnami/wordpress \ 
  --namespace prod \ 
  --set service.type=LoadBalancer

Revenir en arrière : `helm rollback`

Parfois, une mise à jour se passe mal et vous devez rapidement revenir à un état fonctionnel précédent. La commande helm rollback permet de restaurer une Release à une révision antérieure.

La syntaxe est :

helm rollback [NOM_RELEASE] [REVISION] [flags]
  • [NOM_RELEASE] : Le nom de la Release à restaurer.
  • [REVISION] : Le numéro de la révision vers laquelle revenir. Si omis, Helm revient à la révision précédente (la plus fréquente utilisation).
  • [flags] : Inclut --dry-run, --debug.

Pour connaître l'historique des révisions d'une Release, utilisez la commande helm history [NOM_RELEASE] :

helm history mon-wordpress-prod -n prod
# REVISION UPDATED                  STATUS     CHART               APP VERSION DESCRIPTION
# 1        Wed Mar 15 10:00:00 2023 SUPERSEDED wordpress-15.0.0  6.1.1       Install complete
# 2        Wed Mar 15 11:30:00 2023 DEPLOYED   wordpress-15.1.0  6.2.0       Upgrade complete

Pour revenir à la révision 1 :

helm rollback mon-wordpress-prod 1 -n prod

Il est important de noter que l'opération de rollback crée elle-même une nouvelle révision dans l'historique, dont le contenu est celui de la révision cible du rollback.

Observer et gérer les Releases

Helm fournit plusieurs autres commandes utiles pour observer et gérer vos Releases :

  • helm list (ou helm ls) : Affiche la liste des Releases déployées.
    • helm list -n : Liste les Releases dans un namespace spécifique.
    • helm list -A : Liste les Releases dans tous les namespaces.
    • helm list -a : Inclut aussi les Releases échouées ou désinstallées (si l'historique est conservé).
    Elle affiche le nom de la Release, le namespace, la révision, le statut (deployed, failed, pending, etc.), la version du Chart et la version de l'application.
  • helm status [NOM_RELEASE] : Fournit un état détaillé d'une Release spécifique, incluant la dernière révision, le statut des ressources Kubernetes gérées par la Release (Pods, Services, etc.) et les notes éventuelles du Chart.
  • helm history [NOM_RELEASE] : Comme mentionné précédemment, affiche l'historique des révisions de la Release.
  • helm uninstall [NOM_RELEASE] : Supprime une Release du cluster. Cette commande supprime toutes les ressources Kubernetes associées à la Release ainsi que l'historique de la Release (sauf si l'option --keep-history est utilisée, ce qui est rare). C'est l'opération inverse de helm install.

Ces commandes forment l'arsenal de base pour tout utilisateur de Helm. Elles permettent de gérer le cycle de vie complet des applications de manière structurée, contrôlée et reproductible, en s'appuyant sur le packaging et le templating des Charts Helm.