GitOps avec Flux : le cluster suit le dépôt

Avec le déploiement continu « push » (leçon D.3), le pipeline agit sur le cluster et l'état réel finit par diverger de ce que l'on croit : un kubectl edit en urgence, un déploiement oublié. Le GitOps inverse la logique : un dépôt Git décrit l'état voulu du cluster, et un contrôleur installé dans le cluster le compare en permanence à la réalité et corrige les écarts. Pour déployer, on fait un commit. Flux est l'un des deux outils de référence (projet diplômé de la CNCF). Cette leçon est théorique : les contrôleurs Flux et une forge Git demandent plus qu'un namespace d'exercice.

Ce que vous saurez à la fin : énoncer les principes du GitOps, installer Flux avec flux bootstrap, décrire une source Git et ce qu'il faut en appliquer, déployer un chart Helm avec Flux, suivre et forcer une synchronisation, et automatiser la mise à jour des images.

1. Les quatre principes

Selon le projet OpenGitOps de la CNCF, un système GitOps est :

1. déclaratif : l'état voulu est décrit, pas les étapes pour y arriver ;
2. versionné et immuable : cet état vit dans Git, avec tout son historique ;
3. tiré automatiquement : des agents récupèrent eux-mêmes l'état voulu ;
4. réconcilié en continu : les agents corrigent tout écart entre le voulu et le réel.

Conséquences : le dépôt est la documentation de la production, chaque changement passe par une demande de fusion relue, un retour arrière est un git revert, et aucun identifiant du cluster ne sort du cluster.

2. Installer Flux

flux check --pre                                  # le cluster convient-il ?
export GITHUB_TOKEN=…                             # un jeton qui peut écrire dans le dépôt
flux bootstrap github \
  --owner=mon-org --repository=flotte \
  --branch=main --path=clusters/prod

bootstrap installe les contrôleurs de Flux dans le namespace flux-system, commite leurs manifestes dans le dépôt, et configure Flux pour qu'il suive ce même dépôt. Flux se gère alors lui-même par GitOps : le mettre à jour, c'est un commit.

3. Une source et ce qu'il faut appliquer

Flux sépare d'où viennent les manifestes (une source) et ce qu'il faut en faire :

apiVersion: source.toolkit.fluxcd.io/v1
kind: GitRepository
metadata: {name: vitrine, namespace: flux-system}
spec:
  url: https://github.com/mon-org/vitrine
  ref: {branch: main}
  interval: 1m                       # vérifie le dépôt chaque minute
---
apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata: {name: vitrine, namespace: flux-system}
spec:
  sourceRef: {kind: GitRepository, name: vitrine}
  path: ./deploy/prod                # le dossier à appliquer (Kustomize, leçon 2.18)
  targetNamespace: vitrine
  interval: 10m                      # réconcilie au moins toutes les 10 minutes, même sans commit
  prune: true                        # supprime ce qui a été retiré du dépôt
  wait: true                         # attend que les ressources soient prêtes

prune: true est ce qui rend le dépôt vraiment maître : un fichier supprimé dans Git, et l'objet disparaît du cluster.

4. Un chart Helm

apiVersion: source.toolkit.fluxcd.io/v1
kind: HelmRepository
metadata: {name: bitnami, namespace: flux-system}
spec:
  type: oci
  url: oci://registry-1.docker.io/bitnamicharts
  interval: 1h
---
apiVersion: helm.toolkit.fluxcd.io/v2
kind: HelmRelease
metadata: {name: cache, namespace: vitrine}
spec:
  interval: 10m
  chart:
    spec:
      chart: redis
      version: "21.x"                # une plage : Flux suit les correctifs
      sourceRef: {kind: HelmRepository, name: bitnami, namespace: flux-system}
  values:
    architecture: standalone

Les valeurs (leçon 2.17) sont versionnées dans Git comme le reste. Une mise à jour du chart qui échoue peut être annulée automatiquement (spec.upgrade.remediation).

5. Suivre et intervenir

flux get kustomizations                          # état de chaque synchronisation (Ready, révision appliquée)
flux get helmreleases -A
flux reconcile kustomization vitrine --with-source   # forcer : relire le dépôt et appliquer maintenant
flux suspend kustomization vitrine               # suspendre pendant une intervention manuelle…
flux resume kustomization vitrine                # … puis reprendre
flux logs --level=error

Une modification manuelle (kubectl edit) d'un objet géré par Flux est annulée à la réconciliation suivante : c'est voulu. En urgence, on suspend, on corrige, puis on reporte la correction dans Git avant de reprendre.

6. Automatiser les images

Le pipeline publie vitrine:1.4.3. Qui met à jour le dépôt ? Les contrôleurs d'automatisation d'images de Flux : ImageRepository surveille le registre, ImagePolicy choisit la bonne étiquette (par exemple la plus haute version 1.x selon semver), et ImageUpdateAutomation commite la nouvelle étiquette dans le dépôt. Le cluster suit, et l'historique Git garde la trace de chaque version déployée.

7. Organiser le dépôt

Un découpage courant : clusters/<nom>/ (ce que chaque cluster applique), infrastructure/ (contrôleurs partagés : ingress, cert-manager…), apps/base/ et apps/<environnement>/ (les applications et leurs variantes Kustomize). Les secrets ne vont jamais en clair dans Git : chiffrez-les avec SOPS (que Flux sait déchiffrer) ou tirez-les d'un coffre avec External Secrets.

Validez la leçon avec le questionnaire.