Diagramme de workflow GitOps : déploiement en mode pull avec Argo CD ou Flux

Dans un pipeline classique, la CI construit le code puis pousse le résultat dans le cluster avec kubectl apply ou helm upgrade. Cela fonctionne, mais le pipeline a besoin d'identifiants d'administration pour chaque cluster, personne ne peut dire avec certitude ce qui tourne sans interroger le cluster, et un déploiement modifié à la main diverge en silence de ce que dit le dépôt.

GitOps inverse le sens. Git contient l'état souhaité, et un agent dans le cluster le tire en continu et aligne le cluster dessus. Cet article explique les principes, le workflow à deux dépôts qu'utilisent la plupart des équipes, le fonctionnement de la promotion et du rollback, et dessine l'ensemble du flux.

Les quatre principes

Le projet OpenGitOps de la CNCF définit GitOps par quatre principes :

1. Déclaratif : l'état souhaité du système est exprimé de manière déclarative.
2. Versionné et immuable : cet état est stocké de façon à conserver un historique de versions complet et immuable, ce qui veut dire Git en pratique.
3. Tiré automatiquement : des agents logiciels tirent l'état souhaité depuis la source.
4. Réconcilié en continu : les agents comparent sans cesse l'état réel à l'état souhaité et corrigent l'écart.

Le troisième point est ce qui distingue GitOps du « déploiement depuis un pipeline qui lit Git ». Le cluster tire ; rien de l'extérieur ne pousse dedans.

Deux dépôts : code et configuration

La plupart des équipes séparent deux types de changements :

• Le dépôt d'application contient le code source. La CI le construit, lance les tests, l'analyse et pousse un tag d'image immuable dans un registre.
• Le dépôt de configuration contient les manifestes Kubernetes, les values Helm ou les overlays Kustomize de chaque environnement. Il décrit ce qui doit tourner où, tags d'image compris.

Le lien entre les deux est un petit changement explicite : la CI, ou un outil d'automatisation d'images, ouvre une pull request dans le dépôt de configuration qui monte le tag d'image de staging. Cette pull request est la demande de déploiement, avec revue et piste d'audit.

Le contrôleur dans le cluster

Argo CD et Flux sont les deux contrôleurs GitOps les plus répandus. Tous deux tournent dans le cluster, interrogent le dépôt de configuration ou reçoivent ses webhooks, génèrent les manifestes, les comparent aux objets en place et appliquent l'écart.

Leurs réglages de réconciliation décident de la rigueur du système :

• Synchronisation automatique : appliquer les nouveaux commits sans que personne n'appuie sur un bouton.
• Pruning : supprimer les objets retirés de Git.
• Self-heal : annuler les changements faits directement dans le cluster. Dans les options de synchronisation automatique d'Argo CD, le self-heal est un interrupteur distinct de l'auto-sync.

Le self-heal est le réglage qui fait de Git la vraie source de vérité. Sans lui, un kubectl edit à 3 h du matin devient permanent et invisible.

Promotion et rollback

Les environnements sont des dossiers, des overlays ou des fichiers du dépôt de configuration. Promouvoir, c'est copier une version de l'un vers le suivant :

1. La pull request monte le tag de staging ; staging se met à jour quelques minutes après le merge.
2. Les tests et les vérifications s'exécutent sur staging.
3. Une seconde pull request monte la production au même tag. La merger, c'est le déploiement en production.

Le rollback est un git revert de ce merge. Le contrôleur voit l'ancien tag et l'applique. Comme tout l'historique est dans Git, la question « qu'est-ce qui tournait en production mardi dernier à 14 h ? » a une réponse exacte.

Qui ouvre la pull request

Il existe deux façons courantes de relier une nouvelle image au dépôt de configuration :

• La CI l'ouvre. La dernière étape du pipeline clone le dépôt de configuration, modifie une ligne, commite sur une branche et ouvre une pull request. C'est explicite et facile à déboguer, et le pipeline n'a besoin que d'un jeton pour ce seul dépôt.
• Un outil d'automatisation d'images la commite. Les contrôleurs d'automatisation d'images de Flux et le projet Argo CD Image Updater peuvent surveiller un registre, choisir les nouveaux tags conformes à une politique et les réécrire dans Git. Utile pour les environnements de staging qui doivent toujours exécuter le dernier build.

Beaucoup d'équipes combinent les deux : l'automatisation garde staging à jour, tandis que les changements de production arrivent toujours sous forme de pull request revue, ouverte par une personne ou un job de release. Quel que soit votre choix, écrivez-le sur le diagramme, car « comment une nouvelle version arrive-t-elle ici ? » est la première question que l'on pose sur une installation GitOps.

Une release de bout en bout

Suivez la version 1.8.0 d'un service shop, du commit à la production :

1. Un développeur merge un changement dans le dépôt d'application. La CI lance les tests, construit l'image, l'analyse et pousse shop:1.8.0 dans le registre.
2. La CI ouvre dans le dépôt de configuration une pull request qui passe le tag de staging de 1.7.3 à 1.8.0. Un relecteur l'approuve et la merge.
3. En une ou deux minutes, le contrôleur remarque le nouveau commit, génère les manifestes de staging et met à jour le déploiement. Kubernetes déploie de nouveaux pods, qui tirent l'image depuis le registre.
4. Les smoke tests passent sur staging. La responsable de la release ouvre une seconde pull request qui passe la production en 1.8.0.
5. Après ce merge, la production se déploie de la même façon. Si les taux d'erreur augmentent, annuler le commit de merge remet la 1.7.3.

À aucun moment quoi que ce soit hors du cluster n'a eu besoin d'identifiants du cluster, et chaque étape a laissé un commit derrière elle.

Secrets

Les secrets en clair ne peuvent pas aller dans Git. Approches courantes :

• Chiffrés dans Git, avec des outils comme Sealed Secrets ou SOPS, déchiffrés uniquement dans le cluster.
• Des références dans Git, les valeurs ailleurs, avec un opérateur comme External Secrets qui lit dans un gestionnaire de secrets.

Dans les deux cas, le dépôt de configuration reste relisible et les valeurs des secrets n'apparaissent jamais dans un diff.

Le diagramme d'architecture

Comment le lire :

• Ligne du haut, le build : un développeur pousse vers le dépôt d'application, la CI construit et teste l'image 1.8.0 puis la pousse dans le registre.
• Au milieu : la CI ouvre une pull request qui monte le tag de staging dans le dépôt de configuration. C'est le seul endroit où la CI touche au déploiement.
• En bas, le cluster : le contrôleur GitOps tire le dépôt de configuration (en tirets) et l'applique au namespace de staging, qui exécute désormais la 1.8.0, ainsi qu'à la production, qui exécute encore la 1.7.3 jusqu'au merge de sa propre pull request. Les nœuds tirent les images depuis le registre (en pointillés).
• Le bloc Markdown énonce les règles du workflow : promotion par pull request, rollback par revert, dérives annulées par le self-heal.

Ce qui change pour l'équipe

• La CI perd les identifiants du cluster. C'est le cluster qui va chercher ; le pipeline n'a besoin que d'un accès en écriture à un dépôt.
• Les revues couvrent les déploiements. Qui a déployé quoi, quand et pourquoi figure dans l'historique des pull requests.
• Les dérives deviennent visibles. Le contrôleur affiche les ressources désynchronisées au lieu de les cacher.
• Le débogage se déplace. « Pourquoi ceci n'a-t-il pas été déployé ? » trouve sa réponse dans l'état de synchronisation et les événements du contrôleur : rendez-les visibles à ceux qui mergent.

Ce qu'il faut mettre sur un diagramme GitOps

• Les deux dépôts, et la pull request qui les relie.
• Le sens du pull, du contrôleur vers le dépôt de configuration, pas du pipeline vers le cluster.
• Chaque environnement avec la version qu'il exécute, pour rendre la promotion visible.
• Les réglages de synchronisation : auto-sync, prune, self-heal.

Le diagramme des stratégies de déploiement montre comment le déploiement lui-même peut être canary ou blue-green, le diagramme de pipeline CI/CD détaille les étapes de build, le diagramme d'architecture Kubernetes montre le cluster lui-même, et l'article sur le passage du YAML Kubernetes au diagramme montre comment transformer les manifestes du dépôt de configuration en image.

Le construire dans Archboard

1. Connectez-vous avec Google ou GitHub et créez un diagramme.
2. Ajoutez une Personne du pack Modèle C4, deux nœuds Dépôt et un Pipeline CI/CD du pack DevOps, ainsi qu'un Registre du pack Docker.
3. Ajoutez un Cadre du pack Base pour le cluster, avec un Conteneur pour le contrôleur GitOps.
4. Ajoutez deux nœuds Namespace du pack Kubernetes avec un Deployment dans chacun, étiqueté avec la version qu'il exécute.
5. Dessinez le pull en arête en tirets du contrôleur vers le dépôt de configuration, et ajoutez un bloc Markdown du pack Base avec les règles du workflow.

L'exemple utilise 12 nœuds de diagramme et reste dans les limites de l'offre Free.

FAQ

Quelle est la différence entre GitOps et CI/CD ? La CI/CD construit, teste et livre le logiciel. GitOps est une façon de faire la partie livraison : l'état souhaité vit dans Git et un agent dans l'environnement cible le tire et le réconcilie, au lieu qu'un pipeline y pousse les changements.

Faut-il utiliser Argo CD ou Flux ? Les deux implémentent le même modèle. Argo CD offre une interface web riche et des vues centrées sur les applications ; Flux est un ensemble de contrôleurs composables que beaucoup d'équipes pilotent entièrement par Git et la CLI.

Ai-je besoin de dépôts séparés pour l'application et la configuration ? C'est une convention répandue, pas une règle. Des dépôts séparés gardent l'historique des déploiements propre et permettent de changer la configuration sans reconstruire le code.

Comment faire un rollback avec GitOps ? Annulez le commit qui a changé la version dans le dépôt de configuration. Le contrôleur applique l'état précédent.

Comment gère-t-on les secrets avec GitOps ? Stockez-les chiffrés dans Git, ou stockez des références dans Git et laissez un opérateur aller chercher les valeurs dans un gestionnaire de secrets à l'intérieur du cluster.

Commencez gratuitement — un siège, sans carte bancaire.