Le moyen le plus rapide d’apprendre le templating Helm est de prendre des manifestes que vous comprenez déjà et de les templatiser un champ à la fois. Ce guide part d’un Deployment, d’un Service et d’une ConfigMap bruts, génère un chart, et remplace les champs qui doivent varier par des values.

Générer un chart et supprimer l’exemple

helm create webapp
cd webapp
rm -rf templates/tests templates/hpa.yaml templates/ingress.yaml \
       templates/serviceaccount.yaml templates/_helpers.tpl

Les fichiers générés templates/deployment.yaml et templates/service.yaml forment un exemple fonctionnel, mais pour apprendre il est plus clair d’écrire les vôtres de zéro. Videz leur contenu (en gardant les fichiers) et videz values.yaml :

: > values.yaml

Ajouter vos propres manifestes

Écrivez d’abord du YAML Kubernetes brut, exactement comme vous le feriez sans Helm :

# templates/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-webapp
  labels:
    app: my-webapp
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-webapp
  template:
    metadata:
      labels:
        app: my-webapp
    spec:
      containers:
        - name: my-webapp
          image: myorg/webapp:1.0
          envFrom:
            - configMapRef:
                name: my-webapp-config
          ports:
            - containerPort: 8080

# templates/service.yaml
apiVersion: v1
kind: Service
metadata:
  name: my-webapp
spec:
  selector:
    app: my-webapp
  ports:
    - port: 80
      targetPort: 8080

# templates/configmap.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: my-webapp-config
data:
  CUSTOM_HEADER: "this app was deployed with Helm"

Remarquez la même chaîne, my-webapp, répétée dans le nom, le label, le sélecteur et la référence à la ConfigMap. Cette répétition est précisément ce qui rend sujets aux erreurs les manifestes multi-environnements maintenus à la main : renommez l’application une fois et vous avez quatre endroits à corriger.

Remplacer les valeurs répétées par une valeur de template

Introduisez une seule valeur et référencez-la partout où le nom apparaît :

# values.yaml
appName: my-webapp

# templates/deployment.yaml (extrait)
metadata:
  name: {{ .Values.appName }}
  labels:
    app: {{ .Values.appName }}
spec:
  selector:
    matchLabels:
      app: {{ .Values.appName }}
  template:
    metadata:
      labels:
        app: {{ .Values.appName }}
    spec:
      containers:
        - name: {{ .Values.appName }}
          envFrom:
            - configMapRef:
                name: {{ .Values.appName }}-config

Faites de même dans service.yaml et configmap.yaml partout où my-webapp apparaît. .Values est alimenté depuis values.yaml ; un seul changement à cet endroit renomme donc désormais toutes les ressources de façon cohérente.

Templatiser l’image et les données de la ConfigMap

Séparez l’image en valeurs distinctes pour que le tag puisse changer indépendamment du dépôt :

# values.yaml (à ajouter)
image:
  repository: myorg/webapp
  tag: "1.0"

        - name: {{ .Values.appName }}
          image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"

Puis le contenu de la ConfigMap :

# values.yaml (à ajouter)
config:
  customHeader: "this app was deployed with Helm"

# templates/configmap.yaml
data:
  CUSTOM_HEADER: {{ .Values.config.customHeader | quote }}

Le filtre | quote entoure la valeur de guillemets doubles, ce qui compte dès que les valeurs propres à un environnement se mettent à contenir des espaces ou des caractères spéciaux. Une bonne règle pour nommer vos values : reproduisez la structure du manifeste lui-même (config.customHeader correspond au data.CUSTOM_HEADER d’une ConfigMap), pour que quiconque lit le template puisse deviner d’où vient une valeur.

Prévisualiser avant d’installer

Deux commandes génèrent le chart sans toucher à un cluster :

helm template ./webapp
helm install my-webapp ./webapp --dry-run --debug

helm template génère en local et n’a besoin d’aucun cluster. --dry-run --debug sur install valide en plus par rapport à l’API du cluster sans rien persister. Exécutez l’une de ces commandes après chaque modification de template ; une faute de frappe dans {{ .Values.appname }} (mauvaise casse) se génère silencieusement comme une valeur vide au lieu de provoquer une erreur, et c’est le moyen le plus rapide de l’attraper.

Installer et confirmer

helm install my-webapp ./webapp
kubectl get all -l app=my-webapp

my-webapp est ici le nom de la release, et ./webapp est le répertoire du chart. Installer un chart écrit à la main ne diffère en rien de l’installation d’un chart publié.

Modifier une valeur et mettre à niveau

Modifiez values.yaml (changez image.tag, config.customHeader, ce que vous voulez tester) et appliquez le changement :

helm upgrade my-webapp ./webapp
helm list

helm list affiche maintenant la révision 2. Chaque upgrade réapplique l’ensemble du chart avec les valeurs courantes ; c’est donc aussi ainsi que vous déploieriez une nouvelle version au quotidien.

Ajouter un NOTES.txt

# templates/NOTES.txt
Votre release "{{ .Release.Name }}" a été déployée.

Pour accéder à {{ .Values.appName }}, exécutez :
  kubectl port-forward svc/{{ .Values.appName }} 8080:80

.Release.Name est une valeur intégrée que Helm fournit toujours, avec .Chart et .Release.Namespace ; vous ne la définissez pas vous-même. Exécutez de nouveau helm upgrade my-webapp ./webapp et ce texte s’affiche dans le terminal, avec la commande port-forward déjà renseignée pour la personne qui regarde.