Les applications réelles s’exécutent dans plusieurs environnements qui diffèrent légèrement : nombre de réplicas, noms d’hôte, valeurs de configuration. Argo CD peut déployer depuis du YAML brut, des charts Helm ou Kustomize, et détecte lequel un dossier utilise. Ce guide montre comment structurer un dépôt unique pour plusieurs environnements avec des overlays Kustomize et avec des fichiers de valeurs Helm, et aborde un piège qui surprend souvent lors des changements de configuration. Il s’appuie sur l’exemple webapp des guides précédents.

Choisir une organisation : des dossiers, pas des branches

Vous pouvez modéliser les environnements comme des branches de longue durée (dev, staging, main), mais cela transforme la promotion en exercice de merge et laisse les environnements dériver les uns des autres. Une seule branche avec un dossier par environnement est plus facile à raisonner : tous les environnements sont visibles côte à côte, et un changement dans l’un d’eux est un diff ordinaire.

Kustomize est conçu pour cela : une base partagée, plus un petit overlay par environnement qui ne modifie que ce qui diffère.

Construire une base Kustomize et des overlays

webapp-config/
├── base/
│   ├── deployment.yaml
│   ├── service.yaml
│   └── kustomization.yaml
└── overlays/
    ├── dev/
    │   └── kustomization.yaml
    └── prod/
        └── kustomization.yaml

base/kustomization.yaml liste les ressources partagées :

resources:
  - deployment.yaml
  - service.yaml

Dans base/deployment.yaml, faites en sorte que le conteneur lise ses paramètres depuis un ConfigMap que chaque overlay générera :

          envFrom:
            - configMapRef:
                name: webapp-config

overlays/dev/kustomization.yaml :

resources:
  - ../../base
namespace: webapp-dev
replicas:
  - name: webapp
    count: 2
configMapGenerator:
  - name: webapp-config
    literals:
      - HEADER=Hello from dev

overlays/prod/kustomization.yaml est identique, avec namespace: webapp-prod, count: 4 et sa propre valeur de HEADER.

Pointer une Application vers chaque overlay

Argo CD détecte un kustomization.yaml dans le chemin et le construit pour vous. Créez une Application par environnement :

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: webapp-dev
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/your-org/webapp-config.git
    targetRevision: HEAD
    path: overlays/dev
  destination:
    server: https://kubernetes.default.svc
    namespace: webapp-dev
  syncPolicy:
    syncOptions:
      - CreateNamespace=true
    automated:
      prune: true

Pour webapp-prod, changez le nom, le chemin (overlays/prod) et le namespace, et envisagez de supprimer automated pour que les synchronisations de production soient approuvées par une personne.

Pour Helm, la forme est la même, mais la source est un chart et vous sélectionnez le fichier de valeurs d’un environnement :

  source:
    repoURL: https://github.com/your-org/webapp-config.git
    targetRevision: HEAD
    path: charts/webapp
    helm:
      valueFiles:
        - values-dev.yaml

Les chemins de valueFiles sont relatifs au dossier du chart, et les fichiers suivants écrasent les précédents.

Gérer volontairement les changements de configuration

Modifiez la valeur de HEADER dans un environnement et comparez ce que fait chaque outil :

• Kustomize ajoute un hash du contenu aux noms des ConfigMaps générés. Une nouvelle valeur produit un nouveau ConfigMap (webapp-config-<hash>) et met à jour la référence du Deployment, ce qui déclenche un déploiement des Pods. L’ancien ConfigMap est désormais orphelin : l’application apparaît donc OutOfSync jusqu’à ce qu’il soit élagué (pruned). Avec prune: true, cela est nettoyé pour vous.
• Helm met à jour le ConfigMap existant sur place. La spec du Deployment ne change pas : les Pods en cours d’exécution gardent donc les anciennes valeurs et rien n’indique à Argo CD ou à Kubernetes de les redémarrer.

La solution standard pour Helm consiste à placer une somme de contrôle du ConfigMap dans le template du Pod, de sorte qu’un changement de configuration modifie le template et redéploie les Pods. Dans templates/deployment.yaml :

  template:
    metadata:
      annotations:
        checksum/config: {{ include (print $.Template.BasePath "/configmap.yaml") . | sha256sum }}

Redémarrer le Deployment à la main fonctionne aussi, une fois, mais ce n’est pas consigné dans Git, ce qui va à l’encontre de l’objectif.

Promouvoir les changements d’un environnement à l’autre

Avec cette organisation, la promotion est une suite de commits ordinaires. Modifiez d’abord l’overlay dev (par exemple, un changement d’image avec kustomize edit set image webapp=nginx:1.26 exécuté dans overlays/dev), laissez la synchronisation automatisée l’appliquer, et vérifiez. Faites ensuite le même changement dans overlays/prod et synchronisez-le, manuellement si vous avez gardé la production sous validation. Un pipeline CI peut automatiser le commit dev, et une pull request ou une approbation peut contrôler celui de la production. Pour piloter de nombreux clusters ou environnements depuis un seul endroit, intéressez-vous aux ApplicationSets d’Argo CD, qui génèrent des ressources Application à partir d’un modèle.