Flux CD, Structurer ses dépôts pour plusieurs environnements

Un dépôt Flux qui sert un seul cluster se range presque n'importe comment. Dès qu'il en sert plusieurs, staging et production au minimum, sa structure décide de ce qu'on peut promouvoir, relire et restreindre. Cette leçon monte l'organisation que décrit le guide officiel de Flux : un dossier clusters/<env> par cluster, une infrastructure commune et des applications déclinées par overlays Kustomize. Le cluster de test, en Flux 2.9.6, applique la variante staging, et la comparaison des deux environnements tient en deux lignes. Elle compare ensuite les quatre organisations de dépôts que le guide présente, avec ce que chacune permet de contrôler.

Ce que vous allez apprendre

• Ranger un dépôt en clusters/, infrastructure/ et apps/
• Décliner une application par environnement avec des overlays Kustomize
• Ordonner l'infrastructure avant les applications dans chaque cluster
• Promouvoir un changement de staging vers la production
• Choisir entre monorepo, dépôt par environnement, par équipe ou par application

Prérequis

Cette leçon assemble des mécanismes déjà vus : dépendances entre Kustomizations, overlays et substitution de variables.

• La leçon Kustomization avancée
• La leçon Configuration par environnement

Quelle arborescence pour plusieurs clusters ?

Le guide officiel de Flux range un monorepo en trois dossiers de premier niveau. clusters/ contient l'entrée de chaque cluster, la seule chose qui diffère d'un cluster à l'autre ; infrastructure/ porte ce que chaque cluster doit avoir avant les applications ; apps/ porte les applications, avec un socle commun et un overlay par environnement.

plateforme/
├── clusters/
│   ├── staging/infrastructure.yaml      ← Kustomizations du cluster staging
│   └── production/infrastructure.yaml   ← Kustomizations du cluster production
├── infrastructure/
│   └── namespaces/namespaces.yaml       ← commun à tous les clusters
└── apps/
    ├── base/podinfo/                    ← socle de l'application
    ├── staging/kustomization.yaml       ← overlay staging
    └── production/kustomization.yaml    ← overlay production

Chaque cluster est bootstrappé sur son dossier : --path=clusters/staging pour l'un, --path=clusters/production pour l'autre. Il ne voit ainsi que ses propres Kustomizations, qui pointent vers l'infrastructure commune et vers l'overlay de son environnement.

Décliner une application par overlay

Le socle apps/base/podinfo décrit l'application une fois. Chaque overlay le reprend et ne patche que ce qui change : ici le nombre de réplicas et le message affiché.

apps/production/kustomization.yaml

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
  - ../base/podinfo
patches:
  - target:
      kind: Deployment
      name: podinfo
    patch: |
      - op: replace
        path: /spec/replicas
        value: 3
      - op: replace
        path: /spec/template/spec/containers/0/env/0/value
        value: production

La différence réelle entre les deux environnements se lit avec un simple diff des deux constructions. Sur le dépôt de test, elle tient en deux lignes, ce qui rend toute dérive entre environnements immédiatement visible en revue :

diff <(kustomize build apps/staging) <(kustomize build apps/production)

7c7
<   replicas: 1
---
>   replicas: 3
19c19
<           value: staging
---
>           value: production

Les overlays conviennent quand la structure des objets diffère d'un environnement à l'autre ; quand seules des valeurs changent, la substitution post-build évite même les dossiers par environnement. Les deux se combinent.

Ordonner l'infrastructure avant les applications

L'entrée de chaque cluster déclare deux Kustomizations : l'infrastructure, avec wait: true, puis les applications, qui en dépendent. Les applications ne sont jamais appliquées avant que leur namespace, leurs CRD ou leurs contrôleurs existent.

clusters/staging/infrastructure.yaml

apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
  name: infrastructure
  namespace: flux-system
spec:
  interval: 1h
  path: ./plateforme/infrastructure
  prune: true
  wait: true
  sourceRef:
    kind: GitRepository
    name: fleet-infra
---
apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
  name: apps
  namespace: flux-system
spec:
  dependsOn:
    - name: infrastructure
  interval: 10m
  path: ./plateforme/apps/staging
  prune: true
  wait: true
  sourceRef:
    kind: GitRepository
    name: fleet-infra

Le cluster de test, branché sur clusters/staging, a appliqué les deux couches dans l'ordre et déployé la variante staging :

NAME            READY  MESSAGE
infrastructure  True   Applied revision: main@sha1:c11ceb7f
apps            True   Applied revision: main@sha1:c11ceb7f
$ kubectl -n podinfo get deploy podinfo …
replicas=1 message=staging

L'intervalle de l'infrastructure est volontairement plus long que celui des applications : elle change rarement, et ses changements peuvent toucher tout le cluster.

Promouvoir de staging vers la production

Dans un monorepo, promouvoir, c'est porter dans l'overlay de production un changement déjà validé en staging, par une pull request. Le guide officiel insiste sur l'infrastructure : ses changements peuvent provoquer une panne de tout le cluster, et se font donc par étapes. On fusionne d'abord le changement pour staging ; une fois le cluster réconcilié et ses tests de conformité passés, on le promeut en production, toujours derrière une revue.

Pour les applications, l'automatisation d'images peut livrer une nouvelle version en staging, et pousser la même mise à jour vers une branche dédiée pour la production, où une PR attend l'approbation : c'est le schéma vu dans la leçon Automatisation d'images. Les branches restent courtes : tous les environnements vivent dans main, dans des dossiers distincts.

Monorepo, dépôt par environnement, par équipe ou par application ?

Le guide officiel décrit quatre organisations. Elles ne s'excluent pas : une plateforme réelle en combine souvent deux. Le choix porte surtout sur qui peut lire et modifier quoi.

Organisation	Principe	Ce qu'elle apporte	Ce qu'elle coûte
Monorepo	Tous les environnements dans main, en dossiers	Une seule revue, une vision complète	Tout le monde lit la configuration de production
Dépôt par environnement	Un dépôt staging, un dépôt production	Accès à la production restreint, revues plus ciblées	Promotion plus lente, surtout pour l'infrastructure
Dépôt par équipe	La plateforme gère l'infrastructure, chaque équipe ses applications	Séparation des responsabilités	Demande l'isolation multi-tenant
Dépôt par application	Les manifestes vivent avec le code ; le dépôt de configuration pointe dessus	Pas de duplication de manifestes	Une source de plus par application

Glissez pour voir

Le dépôt par équipe s'appuie sur l'isolation vue dans la leçon Multi-tenancy : la plateforme enregistre la source de chaque équipe, et chaque équipe gère ses overlays. Le dépôt par application se branche par une GitRepository vers le dépôt de l'application, ou par un chart Helm publié.

Restreindre la production sans changer de dépôt

Git ne sait pas restreindre l'accès à un dossier, mais la forge le peut en partie : un fichier CODEOWNERS impose la revue d'une équipe désignée sur clusters/production/ et apps/production/. C'est souvent une étape intermédiaire suffisante avant de séparer les dépôts.

À retenir

• Un monorepo Flux se range en clusters/<env>, infrastructure/ et apps/ ; chaque cluster est bootstrappé sur son propre dossier.
• Les overlays Kustomize déclinent une application par environnement ; un diff des constructions montre l'écart réel entre environnements.
• L'infrastructure se réconcilie avant les applications, grâce à dependsOn et wait.
• La promotion de staging vers la production passe par une PR et des tests, par étapes pour l'infrastructure.
• Monorepo, dépôt par environnement, par équipe ou par application : le choix porte sur qui peut lire et modifier la production.

Contrôle de connaissances

Vérifiez que l'essentiel de ce guide est acquis. Les questions portent uniquement sur ce qui vient d'être expliqué ici.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

6 questions

6 min.

70% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

×

📖 Voir la documentation →