Flux CD Flux CD

Déployer votre première application avec un GitRepository et une Kustomization

Pointez Flux vers des manifestes dans Git à l'aide d'une ressource Kustomization et regardez la synchronisation se faire.

12 min Débutant

Flux se configure avec des ressources Kubernetes comme tout le reste du cluster. Deux d’entre elles font l’essentiel du travail : une source comme un GitRepository dit où vit la configuration, et une Kustomization dit « prends les manifestes à ce chemin dans cette source et garde-les appliqués à ce cluster ». Ce guide déploie une petite application, puis modifie Git pour voir la synchronisation se produire. Il suppose que Flux est bootstrappé sur un dépôt fleet-infra (voir le guide précédent).

Préparer les manifestes

Dans votre clone de fleet-infra, ajoutez un dossier d’application à côté du dossier clusters créé par le bootstrap :

fleet-infra/
├── clusters/
│   └── dev/
│       ├── flux-system/        # créé par le bootstrap
│       └── webapp.yaml         # la Kustomization Flux (section suivante)
└── apps/
    └── webapp/
        ├── namespace.yaml
        ├── deployment.yaml
        └── service.yaml

apps/webapp/namespace.yaml :

apiVersion: v1
kind: Namespace
metadata:
  name: webapp

apps/webapp/deployment.yaml :

apiVersion: apps/v1
kind: Deployment
metadata:
  name: webapp
  namespace: webapp
spec:
  replicas: 2
  selector:
    matchLabels:
      app: webapp
  template:
    metadata:
      labels:
        app: webapp
    spec:
      containers:
        - name: webapp
          image: nginx:1.25
          ports:
            - containerPort: 80

apps/webapp/service.yaml :

apiVersion: v1
kind: Service
metadata:
  name: webapp
  namespace: webapp
spec:
  selector:
    app: webapp
  ports:
    - port: 80
      targetPort: 80

Contrairement à certains outils, les manifestes ici nomment explicitement leur namespace, et le dossier inclut l’objet Namespace pour que Flux le crée. Aucun kustomization.yaml n’est nécessaire : quand un dossier n’en contient pas, Flux construit une liste de tous les fichiers YAML qu’il contient.

Écrire la Kustomization Flux

Le bootstrap a déjà créé un GitRepository nommé flux-system qui pointe vers ce même dépôt, vous pouvez donc le réutiliser. clusters/dev/webapp.yaml :

apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
  name: webapp
  namespace: flux-system
spec:
  interval: 10m
  sourceRef:
    kind: GitRepository
    name: flux-system
  path: ./apps/webapp
  prune: true
  wait: true
  timeout: 2m

Les éléments qui comptent :

  • sourceRef est l’origine de l’état désiré. Ici, c’est le dépôt flux-system configuré par le bootstrap.
  • path est le dossier de la source à appliquer.
  • interval est la fréquence à laquelle Flux réapplique les manifestes et corrige la dérive, même quand Git n’a pas changé.
  • prune: true signifie que les objets retirés de Git sont aussi retirés du cluster. C’est désactivé sauf si vous l’activez.
  • wait et timeout font attendre à Flux que les ressources appliquées soient prêtes avant de signaler un succès.

Vous pouvez générer ce YAML avec la CLI plutôt que de l’écrire à la main :

flux create kustomization webapp \
  --source=GitRepository/flux-system \
  --path=./apps/webapp \
  --prune=true --wait=true --timeout=2m --interval=10m \
  --export > clusters/dev/webapp.yaml

Committer et laisser Flux le prendre en compte

git add -A
git commit -m "Add webapp"
git push

La Kustomization flux-system surveille déjà ./clusters/dev, elle découvre donc la nouvelle Kustomization webapp à sa prochaine exécution. Vous n’exécutez jamais kubectl apply pour l’application. Pour éviter d’attendre, demandez à Flux de vérifier Git tout de suite :

flux reconcile source git flux-system
flux get kustomizations --watch

Confirmer le déploiement

La Kustomization webapp apparaît et passe à Ready avec un message nommant la révision appliquée. Vérifiez le cluster, et demandez à Flux d’afficher ce qu’il possède :

kubectl get all -n webapp
flux tree kustomization webapp

Modifier Git et regarder la synchronisation

Modifiez apps/webapp/deployment.yaml, changez l’image en nginx:1.26, puis committez et poussez. Flux récupère les dépôts selon l’intervalle du GitRepository (une minute par défaut après le bootstrap), puis applique le changement. Un nouveau ReplicaSet est déployé. Vérifiez :

flux reconcile kustomization webapp --with-source
kubectl get deploy webapp -n webapp \
  -o jsonpath='{.spec.template.spec.containers[0].image}'; echo

Voilà toute la boucle : on modifie Git, Flux fait converger le cluster. Le guide suivant explique comment contrôler ce comportement.

Utiliser un autre dépôt

Vous n’êtes pas obligé de garder les manifestes d’application dans le dépôt de bootstrap. Pour déployer depuis un autre, créez un GitRepository pour lui et référencez-le depuis la Kustomization :

flux create source git webapp-config \
  --url=https://github.com/your-org/webapp-config \
  --branch=main --interval=1m \
  --export > clusters/dev/webapp-source.yaml

Pour un dépôt privé, ajoutez des identifiants avec flux create secret git et référencez-les avec --secret-ref, ou utilisez une deploy key SSH. Définissez ensuite sourceRef.name: webapp-config dans la Kustomization.

Guides populaires