Dans la plupart des setups GitOps, votre pipeline CI construit une image puis committe le nouveau tag dans le dépôt de configuration. Flux propose une alternative : deux contrôleurs optionnels surveillent votre registre de conteneurs, choisissent le tag le plus récent qui correspond à une règle, et committent eux-mêmes la modification dans Git. Le cluster ne change toujours qu’à cause d’un commit Git, vous conservez donc la piste d’audit. Ce guide utilise l’image publique podinfo.

Comment les pièces s’articulent

Trois ressources travaillent ensemble :

• ImageRepository analyse un registre pour y trouver les tags d’une image.
• ImagePolicy choisit un tag dans cette liste, par exemple la version sémantique la plus élevée dans une plage.
• ImageUpdateAutomation modifie le YAML de votre dépôt Git là où un marqueur l’indique, puis committe et pousse.

Les trois utilisent l’API image.toolkit.fluxcd.io/v1. L’ancienne version v1beta2 a été retirée des CRD dans Flux 2.9, migrez donc tout ancien manifeste avant de mettre à niveau.

Installer les contrôleurs supplémentaires

Les contrôleurs d’images ne font pas partie d’une installation par défaut. Relancez le bootstrap en les ajoutant, et autorisez Flux à pousser vers le dépôt :

flux bootstrap github \
  --owner=<your-github-user> \
  --repository=fleet-infra \
  --branch=main \
  --path=clusters/dev \
  --personal \
  --components-extra=image-reflector-controller,image-automation-controller \
  --read-write-key

Le bootstrap peut être relancé sans risque. Il committe les manifestes des nouveaux contrôleurs et les installe. --read-write-key rend la deploy key accessible en écriture pour que l’automatisation puisse pousser. Vérifiez avec kubectl get pods -n flux-system.

Analyser le registre

apps/podinfo/image-repository.yaml, dans le même dossier que votre déploiement :

apiVersion: image.toolkit.fluxcd.io/v1
kind: ImageRepository
metadata:
  name: podinfo
  namespace: flux-system
spec:
  image: ghcr.io/stefanprodan/podinfo
  interval: 5m

Pour un registre privé, ajoutez secretRef pointant vers un secret de registre Docker, créé avec kubectl create secret docker-registry ou flux create secret oci.

Choisir un tag avec une policy

apiVersion: image.toolkit.fluxcd.io/v1
kind: ImagePolicy
metadata:
  name: podinfo
  namespace: flux-system
spec:
  imageRepositoryRef:
    name: podinfo
  policy:
    semver:
      range: 6.x

semver avec range: 6.x sélectionne la version 6.x la plus élevée. Les autres types de policy sont numerical (le nombre le plus élevé) et alphabetical, qui conviennent à des tags comme des numéros de build ou des dates. Pour des règles basées sur les noms de tags, ajoutez filterTags avec une expression régulière à la policy.

Marquer la ligne à mettre à jour

Flux met à jour exactement les lignes que vous marquez par un commentaire. Dans apps/podinfo/deployment.yaml :

    spec:
      containers:
        - name: podinfo
          image: ghcr.io/stefanprodan/podinfo:6.5.0 # {"$imagepolicy": "flux-system:podinfo"}

Le marqueur est namespace:nom-de-la-policy. Par défaut, il remplace toute la référence d’image. Pour ne mettre à jour que le tag, utilisez {"$imagepolicy": "flux-system:podinfo:tag"}, et pour les valeurs Helm ou les entrées images de Kustomize, le même marqueur fonctionne sur la ligne qui contient le tag. Tout ce qui n’a pas de marqueur est laissé tel quel.

Indiquer à Flux comment committer

apiVersion: image.toolkit.fluxcd.io/v1
kind: ImageUpdateAutomation
metadata:
  name: flux-system
  namespace: flux-system
spec:
  interval: 30m
  sourceRef:
    kind: GitRepository
    name: flux-system
  git:
    checkout:
      ref:
        branch: main
    commit:
      author:
        name: fluxcdbot
        email: fluxcdbot@users.noreply.github.com
      messageTemplate: |
        Automated image update

        {{range .Changed.Changes}}
        - {{.OldValue}} -> {{.NewValue}}
        {{end}}
    push:
      branch: main
  update:
    path: ./apps
    strategy: Setters

Les éléments qui comptent :

• sourceRef est le dépôt Git dans lequel committer. Il doit être accessible en écriture, d’où --read-write-key.
• checkout.ref.branch est la branche de départ, et push.branch est celle où va le commit.
• update.path limite les dossiers analysés à la recherche de marqueurs.
• messageTemplate contrôle le message de commit pour que l’historique reste lisible.

Pousser directement sur main rend tout entièrement automatique. Le temps de gagner en confiance, poussez plutôt vers une branche distincte (par exemple push.branch: flux-image-updates), puis fusionnez une pull request quand vous êtes satisfait. Le changement n’atteint le cluster qu’après la fusion.

Le voir fonctionner

Committez et poussez ces fichiers, puis vérifiez chaque étape :

flux get image repository
flux get image policy
flux get image update

Le repository indique combien de tags ont été analysés, la policy indique le tag sélectionné, et l’automatisation de mise à jour indique le dernier commit poussé. Si le tag sélectionné est plus récent que celui de votre YAML, un commit apparaît dans Git, et Flux l’applique ensuite comme n’importe quel autre changement. Pour déboguer, utilisez kubectl describe sur chaque objet : un mauvais marqueur, une plage de policy qui ne correspond à rien, ou une deploy key en lecture seule sont les coupables habituels.

Quelle approche choisir

Utilisez les commits pilotés par la CI si un pipeline gère déjà la promotion et que vous voulez un seul endroit qui décide de ce qui est livré. Utilisez Flux image automation quand vous voulez que le dépôt de configuration du cluster suive un registre de lui-même, par exemple pour garder un environnement de dev sur la dernière version corrective. Les deux peuvent coexister.