Déployer une application sur Kubernetes nécessite souvent des dizaines de fichiers YAML. Helm résout ce problème en permettant de packager, versionner et déployer des applications avec une seule commande.

Dans l’ article précédent, nous avons vu comment Kubernetes orchestre nos applications. Mais écrire tous ces fichiers YAML à la main est fastidieux et source d’erreurs. Helm est la solution.

Le problème : la jungle YAML

Pour déployer une application WordPress sur Kubernetes, vous devez créer :

• Un Deployment pour WordPress
• Un Service pour exposer WordPress
• Un Ingress pour le domaine et le SSL
• Un PersistentVolumeClaim pour les fichiers
• Un Secret pour les identifiants de base de données
• Une ConfigMap pour la configuration
• Potentiellement des NetworkPolicies, des ResourceQuotas…

Cela représente facilement 200 à 300 lignes de YAML par application. Multipliez par le nombre de clients, et vous comprenez le problème.

Et si vous souhaitez changer le domaine ? Vous devez modifier plusieurs fichiers. Ajouter plus de RAM ? Encore plus de fichiers.

La solution : Helm, le gestionnaire de paquets Kubernetes

Helm est souvent décrit comme l’« apt-get » ou le « brew » de Kubernetes. Il permet de :

• Packager une application dans un « chart » réutilisable
• Paramétrer via un simple fichier de valeurs
• Versionner les déploiements
• Mettre à jour ou revenir en arrière facilement

« Un Helm Chart est une application Kubernetes prête à l’emploi, personnalisable via un fichier de configuration. »

Anatomie d’un Helm Chart

Un Helm chart possède une structure standard :

my-chart/
├── Chart.yaml # Métadonnées (nom, version, description)
├── values.yaml # Valeurs par défaut
├── templates/ # Fichiers YAML templatés
│ ├── deployment.yaml
│ ├── service.yaml
│ ├── ingress.yaml
│ ├── pvc.yaml
│ └── _helpers.tpl # Fonctions utilitaires
└── README.md # Documentation

Chart.yaml : les métadonnées

# Chart.yaml
apiVersion: v2
name: wordpress-stack
description: WordPress avec OpenLiteSpeed, optimisé pour les performances
type: application
version: 3.10.0 # Version du chart
appVersion: "6.4" # Version de WordPress

values.yaml : configuration par défaut

# values.yaml
domain: example.com
wordpress:
 image: litespeedtech/openlitespeed-wordpress:6.4
 resources:
 requests:
 memory: "256Mi"
 cpu: "100m"
 limits:
 memory: "512Mi"
 cpu: "500m"

database:
 # MariaDB déployée dans le même namespace que WordPress
 name: wordpress
 user: wordpress
 # Le mot de passe est injecté via les variables CI/CD

storage:
 size: 2Gi
 storageClass: longhorn

ssl:
 enabled: true
 issuer: letsencrypt-prod

backup:
 enabled: true
 schedule: "0 2 * * *" # Quotidien à 2h du matin

Templates : fichiers YAML dynamiques

Les templates utilisent le langage de templating Go. Exemple simplifié :

# templates/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ .Release.Name }}-wordpress
  namespace: {{ .Release.Namespace }}
spec:
  replicas: {{ .Values.wordpress.replicas | default 1 }}
  selector:
  matchLabels:
  app: {{ .Release.Name }}-wordpress
  template:
  spec:
  containers:
  - name: wordpress
  image: {{ .Values.wordpress.image }}
  resources:
  {{- toYaml .Values.wordpress.resources | nindent 12 }}
  env:
  - name: WORDPRESS_DB_HOST
  value: {{ .Values.database.host }}
  - name: WORDPRESS_DB_NAME
  value: {{ .Values.database.name }}

Les {{ }} sont remplacés par les valeurs du fichier values.yaml lors du déploiement.

Notre chart WordPress personnalisé

Nous avons créé un chart wordpress-stack optimisé pour nos besoins :

Fonctionnalités incluses

• ✅ OpenLiteSpeed : Serveur web ultra-rapide (alternative à Apache/Nginx)
• ✅ SSL automatique : Via Cert-Manager et Let’s Encrypt
• ✅ Base de données dédiée : MariaDB et Redis dédiés à chaque client, dans leur propre namespace
• ✅ Stockage persistant : Via Longhorn avec réplication
• ✅ Sauvegarde automatique : Snapshots quotidiens
• ✅ SFTP intégré : Accès aux fichiers pour les développeurs
• ✅ Ressources configurables : Adaptation aux besoins du client

Déploiement en pratique

Pour déployer un nouveau site WordPress, nous créons simplement un fichier de valeurs :

# values-client-alpha.yaml
domain: www.client-alpha.com

wordpress:
 resources:
 requests:
 memory: "512Mi"
 cpu: "200m"
 limits:
 memory: "1Gi"
 cpu: "1000m"

database:
 name: client_alpha_wp
 user: client_alpha

storage:
 size: 2Gi

sftp:
 enabled: true
 username: alpha-sftp

Puis une seule commande :

helm upgrade --install client-alpha ./wordpress-stack \
 --namespace client-alpha \
 --create-namespace \
 --values values-client-alpha.yaml

Résultat : En moins de 2 minutes, le site est en ligne avec SSL, connecté à la base de données, avec la sauvegarde configurée.

Notre chart app-stack : pour toutes les applications

Au-delà de WordPress, nous avons créé un chart générique app-stack capable de déployer n’importe quelle application conteneurisée :

# values-my-api.yaml
appName: my-api
namespace: my-api
deploymentMode: simple

app:
  image:
  repository: my-registry/my-api
  tag: v2.1.0
  port: 3000
  env:
  - name: NODE_ENV
  value: production
  resources:
  requests:
  memory: "128Mi"
  cpu: "50m"
  limits:
  memory: "256Mi"
  cpu: "200m"
  autoscaling:
  enabled: true
  minReplicas: 2
  maxReplicas: 10

ingress:
 enabled: true
 annotations:
 cert-manager.io/cluster-issuer: "letsencrypt-http"

backup:
 enabled: true

Ce chart prend en charge :

• Applications mono ou multi-conteneurs
• Ingress avec SSL automatique
• Variables d’environnement et secrets
• Health checks configurables
• Jobs et CronJobs

Notre workflow Helm

1. Développement du chart

# Valider la syntaxe
helm lint ./my-chart

# Voir le YAML généré sans déployer
helm template my-release ./my-chart --values values.yaml

# Tester dans un namespace de dev
helm upgrade --install test ./my-chart -n dev --values values-dev.yaml

2. Packaging et publication

# Créer le package (.tgz)
helm package ./my-chart

# Publier dans notre dépôt Helm privé
# (hébergé sur notre cluster)
helm push my-chart-1.0.0.tgz oci://registry.our-domain.com/charts

3. Déploiement en production

# Depuis le dépôt
helm upgrade --install client-prod our-repo/wordpress-stack \
 --namespace client-prod \
 --values values-prod.yaml \
 --version 3.10.0

Gestion des versions et rollback

Helm conserve un historique des déploiements :

# Voir l'historique
helm history client-alpha -n client-alpha

REVISION STATUS DESCRIPTION
1 superseded Install complete
2 superseded Upgrade complete
3 deployed Upgrade complete

En cas de problème, rollback instantané :

# Revenir à la version précédente
helm rollback client-alpha 2 -n client-alpha

Le site revient à son état précédent en quelques secondes.

Helm dans Rancher

Rancher intègre nativement Helm. Depuis l’interface :

1. Accéder à Apps > Charts
2. Sélectionner notre dépôt privé
3. Choisir le chart (wordpress-stack, app-stack…)
4. Remplir le formulaire de configuration
5. Cliquer sur Install

Rancher génère automatiquement un formulaire à partir de values.yaml, rendant le déploiement accessible même aux utilisateurs non techniques.

Nos bonnes pratiques Helm

values/
├── values-dev.yaml # Environnement de dev
├── values-staging.yaml # Pré-production
└── clients/
 ├── client-alpha.yaml
 ├── client-beta.yaml
 └── client-gamma.yaml

Le résultat

Avec nos Helm charts :

Et ensuite ?

Nous avons maintenant :

• ✅ Infrastructure créée par Terraform
• ✅ Serveurs configurés par Ansible
• ✅ Cluster Kubernetes géré via Rancher
• ✅ Applications packagées dans des Helm charts

Mais nous déployons encore manuellement. Dans l’article final de cette série, nous verrons comment GitLab CI/CD et GitOps permettent un déploiement automatique dès que nous poussons du code.