Helm est un outil open‑source qui facilite l’installation, la mise à jour et la gestion des applications Kubernetes. Il fonctionne via un **client‑only** qui communique directement avec l’API Kubernetes (comme `kubectl`). Un « Chart » Helm est un ensemble de fichiers décrivant un ensemble de ressources Kubernetes (Deployment, Service, ConfigMap, etc.) avec une logique de templating avancée. Un « Release » est une instance d’un chart installée avec un nom donné dans un namespace. ISOSET propose des cursus pratiques pour maîtriser Helm Charts, des repositories publics aux charts d’entreprise.

• Chart – le package contenant tous les manifestes et métadonnées (solution open‑source).
• Release – exécution concrète d’un chart sur un cluster (nom, version, paramètres).
• Repository – dépôt public ou privé d’index Charts (ex: Artifact Hub).

Sans Helm, chaque déploiement Kubernetes nécessite de dupliquer ou d’adapter manuellement des fichiers YAML. Helm apporte la réutilisabilité via le templating, la gestion des versions (toutes les releases sont tracées), la reproductibilité (environnements dev/staging/prod avec des valeurs différentes) et l’écosystème de charts pré‑construits (Bitnami, Grafana, Prometheus). Avec Helm, on peut installer une application complexe en une seule commande, puis la mettre à jour ou la retirer proprement en gérant l’ensemble de ses ressources.

# Installer un chart depuis un repo public
helm repo add bitnami https://charts.bitnami.com/bitnami
helm install my-release bitnami/nginx

ISOSET aide les entreprises à standardiser leurs déploiements microservices avec Helm Charts versionnés.

Un chart typique est un répertoire avec des fichiers spécifiques. Les plus importants sont `Chart.yaml` (métadonnées du chart) et `values.yaml` (configuration par défaut), ainsi que le répertoire `templates/` qui contient les modèles YAML.

# Structure de dossier d’un chart
mon-chart/
├── Chart.yaml          # Métadonnées (nom, version, appVersion)
├── values.yaml         # Valeurs par défaut pour les templates
├── charts/             # Dépendances (sous‑charts)
├── templates/          # Manifests Kubernetes avec templating
│   ├── deployment.yaml
│   ├── service.yaml
│   ├── _helpers.tpl    # Fonctions et variables réutilisables
│   └── NOTES.txt       # Message d’information après l’installation
└── .helmignore         # Fichiers à exclure (comme .gitignore)

`Chart.yaml` contient le nom, la version sémantique (`version`) et la version de l’application sous‑jacente (`appVersion`). ISOSET forme à la construction de charts respectant les meilleures pratiques et à la gestion des versions.

Le fichier `values.yaml` contient les valeurs par défaut injectées dans les templates (via `.Values.maVariable`). Pendant l’installation ou la mise à jour, on peut remplacer ces valeurs avec l’option `–set` ou un fichier `custom-values.yaml`. C’est la clé de la multi‑environnement : on garde le même chart, on change les valeurs.

# Exemple de values.yaml (application web)
replicaCount: 3
image:
  repository: nginx
  tag: latest
  pullPolicy: IfNotPresent
service:
  type: ClusterIP
  port: 80
resources:
  limits:
    cpu: 500m
    memory: 512Mi
  requests:
    cpu: 250m
    memory: 256Mi

Le templating combine le fichier `values.yaml` et les modèles Go du dossier `templates/` pour produire les manifestes finaux. ISOSET enseigne à structurer les valeurs par environnement avec des Helmfile ou des overlay de valeurs.

Helm utilise le moteur de templating Go avec des extensions (Functions). Les structures de contrôle permettent de générer des manifestes dynamiques : `if/else` (conditionnelles), `range` (boucles sur des listes), `with` (restriction de portée). On accède aux objets `.Release` (nom, namespace), `.Chart` (métadonnées), `.Files` (fichiers du chart), `.Capabilities` (version K8s).

# Exemple de condition (replicaCount)
replicas: {{ .Values.replicaCount }}
{{- if .Values.ingress.enabled }}
apiVersion: networking.k8s.io/v1
kind: Ingress
...
{{- end }}

# Exemple de boucle sur les labels
{{- range $key, $value := .Values.labels }}
{{ $key }}: {{ $value | quote }}
{{- end }}

On peut aussi déclarer des variables avec `:=` et utiliser `include` pour inclure des sous‑templates (ex: `_helpers.tpl`). ISOSET initie les jeunes au templating Go via la création de charts simples.

Helm intègre plus de 60 fonctions : Go built‑in (len, index, print) et la bibliothèque Sprig (fonctions de manipulation de chaînes, listes, math, encodage, etc.). Les pipelines (`|`) permettent d’enchaîner les transformations de data. Les fonctions courantes : `quote`, `default`, `toYaml`, `indent`, `join`, `splitList`, `upper/lower`.

• `cat « a » « b »` – concatène en une chaîne séparée par des espaces (`a b`).
• `list « a » « b » | join « , »` – transforme une liste en chaîne CSV (`a,b`).
• `default « valeurParDefaut » .Values.option` – valeur par défaut si vide.
• `toYaml .Values.httpHeaders | nindent 4` – formate un bloc YAML indenté.

# Exemple de pipeline avec Sprig
env:
{{- range $key, $val := .Values.env }}
- name: {{ $key | upper | quote }}
  value: {{ $val | quote }}
{{- end }}

# Indentation pour les annotations
annotations: {{ .Values.annotations | toYaml | nindent 4 }}

ISOSET forme à l’utilisation des fonctions avancées pour des charts production‑grade.

Un chart peut inclure d’autres charts (sous‑charts) en les déclarant dans le champ `dependencies` du `Chart.yaml`. Helm extrait alors ces dépendances dans le dossier `charts/`. On peut les activer/désactiver via les `conditions` ou les `tags`. Les valeurs des sous‑charts sont stockées dans `values.yaml` sous une section portant le nom du sous‑chart.

# Chart.yaml (dépendance)
dependencies:
- name: postgresql
  version: 12.x.x
  repository: https://charts.bitnami.com/bitnami
  condition: postgresql.enabled   # contrôlable depuis les valeurs
  tags:
    - database

Les conditions (`condition`) et les tags permettent d’inclure ou d’exclure dynamiquement des sous‑charts en fonction de la configuration, sans modifier le code du chart parent. ISOSET recueille des témoignages d’apprenants qui ont structuré des architectures microservices avec des subcharts.

Une release est une instance d’un chart déployée dans un namespace. `helm install` déploie pour la première fois, `helm upgrade` applique de nouvelles valeurs ou une nouvelle version de chart, `helm rollback` permet de revenir à une version antérieure stable en cas de problème, et `helm uninstall` supprime la release. Helm garde l’historique (`helm history`).

• `helm install ` – premier déploiement.
• `helm upgrade -f values.yaml` – mise à jour.
• `helm rollback ` – retour à une version antérieure.
• `helm list -n ` – lister les releases.
• `helm uninstall ` – suppression propre.

# Installer un chart avec un nom et des valeurs personnalisées
helm install frontend ./frontend-chart -f prod-values.yaml

# Mettre à jour après changement de configuration
helm upgrade frontend ./frontend-chart -f prod-values.yaml

# Voir historique et revenir à la révision 1
helm history frontend
helm rollback frontend 1

# Supprimer la release
helm uninstall frontend

Les hooks sont des ressources Kubernetes annotées (Job, ConfigMap, etc.) qui s’exécutent à des moments précis du cycle de vie d’une release : `pre‑install`, `post‑install`, `pre‑upgrade`, `post‑upgrade`, `pre‑delete`, `post‑delete`, etc. On les utilise pour des migrations de base de données, des vérifications avant installation, ou des sauvegardes.

# Job hook post‑upgrade (migration)
apiVersion: batch/v1
kind: Job
metadata:
  name: db-migration-job
  annotations:
    "helm.sh/hook": post-upgrade
    "helm.sh/hook-weight": "5"
    "helm.sh/hook-delete-policy": hook-succeeded
spec:
  template:
    spec:
      restartPolicy: Never
      containers:
      - name: migration
        image: myapp/migrate:latest
        command: ["python", "migrate.py"]

Les hooks sont déployés temporairement ; Helm peut les supprimer automatiquement si l’annotation `hook-delete-policy` est définie. ISOSET inclut des labs de mise en œuvre de hooks pour des pipelines d’état.

• Nommer cohéremment les ressources – utiliser `{{ .Release.Name }}-{{ .Chart.Name }}` pour éviter les collisions.
• Respecter le versionnage sémantique – incrémenter `version` dans `Chart.yaml` à chaque modification significative.
• Fournir des valeurs par défaut safe – dans `values.yaml`, définir aussi des ressources resource requests/limits.
• Utiliser `helm lint` – valide la structure et les bonnes pratiques sans déployer.
• Tester avec `helm template –debug` – génère les manifests localement pour déboguer la syntaxe.
• Écrire des helpers dans `_helpers.tpl` – pour les fonctions réutilisables (labels, noms).

Plusieurs commandes aident à déboguer avant d’installer : `helm lint` (vérifications statiques), `helm template –debug` (rendu local des manifests sans accès au cluster), `helm install –dry-run –debug` (simule l’installation avec détection d’éventuelles collisions de ressources). Ces commandes affichent la sortie YAML finale, ce qui permet de traquer les erreurs de syntaxe ou de logique.

# Debug complet sans installation réelle
helm lint ./chart
helm template mon-release ./chart -f prod-values.yaml --debug
helm install mon-release ./chart --dry-run --debug -f prod-values.yaml

Les commandes `–debug` sont particulièrement utiles car elles affichent les erreurs de templating avec la pile d’exécution. ISOSET enseigne ces méthodes dans des environnements pratiques sur K3s et Docker Desktop.

On peut héberger ses propres charts sur un dépôt HTTP statique (ou sur OCI registries). La commande `helm repo add` ajoute un dépôt, `helm repo update` met à jour l’index local. Les outils comme GitHub Actions ou GitLab CI/CD intègrent Helm pour packager, tester, pousser les charts vers un dépôt, puis déployer les releases sur les clusters de dev, staging et prod.

# Déploiement partiel avec CI/CD (GitHub Actions style)
helm repo add myrepo https://charts.entreprise.com/
helm dependency build ./chart
helm package ./chart
helm push ./chart-1.0.0.tgz myrepo

ISOSET propose une immersion dans l’automatisation des charts via GitOps et pipelines CI/CD.

Les témoignages d’anciens élèves d’ISOSET confirment l’impact de la formation : *« Avant Helm, je dupliquais des bundles de YAML pour chaque environnement. En quelques jours, j’ai maîtrisé le templating et les subcharts. Aujourd’hui, toute l’équipe déploie les apps en une ligne de commande. »*