GitOps : définition, principes et déploiement avec ArgoCD
Un mode de déploiement dans lequel un dépôt Git décrit l'état voulu du système et un agent le fait converger en continu : principes OpenGitOps, ArgoCD, Flux et comparaison avec la CI/CD en push.
Par Équipe Blent· Mis à jour le · 14 min de lecture· Niveau avancé
GitOps en bref
- Origine du terme
- Weaveworks, 2017
- Source de vérité
- Un dépôt Git déclaratif
- Modèle de déploiement
- Pull, avec réconciliation continue
- Principes
- Les 4 principes OpenGitOps (CNCF)
- Outils phares
- ArgoCD et Flux, projets CNCF diplômés
- Terrain de prédilection
- Kubernetes
Définition : GitOps
Le GitOps est une méthode de déploiement et d'exploitation dans laquelle l'état souhaité d'un système (applications, configuration, infrastructure) est décrit de manière déclarative dans un dépôt Git, qui sert de source de vérité unique. Un agent installé dans l'environnement cible compare en permanence cet état déclaré à l'état réel et applique automatiquement les écarts : c'est la réconciliation continue. Toute modification passe par un commit, relu et tracé dans l'historique Git, ce qui rend les déploiements auditables et réversibles. Le GitOps est surtout utilisé avec Kubernetes, à l'aide d'outils comme ArgoCD ou Flux.
En une phrase : en GitOps, on ne déploie plus : on modifie un dépôt Git, et un agent fait converger le système vers ce qui y est décrit.
Dans cette définition
Qu'est-ce que le GitOps ?
Le GitOps est une manière d'opérer un système dans laquelle Git ne sert plus seulement à versionner le code, mais aussi à décrire, piloter et tracer l'état de la production.
Dans une chaîne de déploiement classique, un script exécuté par l'outil de CI se connecte à l'environnement cible et y applique des commandes : c'est le modèle push. Le GitOps inverse la logique. L'état souhaité est déclaré dans un dépôt Git, et un agent installé dans l'environnement vient le lire, le compare à la réalité et applique les écarts : c'est le modèle pull. Le déploiement n'est plus une action ponctuelle, mais une convergence permanente vers ce que décrit le dépôt.
Le terme a été proposé en 2017 par Alexis Richardson, de la société Weaveworks, dans un article intitulé « GitOps - Operations by Pull Request ». Weaveworks avait créé Flux pour ses propres besoins d'exploitation sur Kubernetes. Peu après, Intuit publiait ArgoCD en open source. Les deux outils sont aujourd'hui des projets diplômés de la CNCF, et le groupe de travail OpenGitOps a formalisé les principes de la méthode indépendamment de tout éditeur. Notre article GitOps : définition et exemples revient en détail sur cette histoire.
Le GitOps se situe à la croisée de deux autres notions du lexique : l'Infrastructure as Code, qui fournit la description déclarative, et la CI/CD, qui construit les artefacts que le GitOps déploie.
À retenir : en GitOps, personne ne lance de commande de déploiement. On modifie le dépôt, et l'agent fait le reste, en continu.
Les quatre principes OpenGitOps
Le groupe de travail OpenGitOps, hébergé par la CNCF, a défini quatre principes qu'un système doit respecter pour être qualifié de GitOps.
- Déclaratif : l'état souhaité du système est exprimé de manière déclarative. On décrit ce qui doit exister, pas la suite de commandes pour y parvenir.
- Versionné et immuable : cet état est stocké de façon à garantir l'immuabilité et le versionnement, avec un historique complet. Git en est l'implémentation la plus courante.
- Tiré automatiquement : des agents logiciels récupèrent automatiquement les déclarations d'état depuis leur source.
- Réconcilié en continu : ces agents observent en permanence l'état réel du système et tentent d'appliquer l'état souhaité.
Le quatrième principe est celui qui distingue le plus nettement le GitOps d'un simple script de déploiement déclenché par un commit. Un script s'exécute une fois ; un agent GitOps corrige aussi la dérive provoquée par une modification manuelle survenue trois semaines plus tard.
Exemple concret : une Application ArgoCD
Avec ArgoCD, chaque application déployée est décrite par une ressource Kubernetes de type Application. Elle indique où se trouvent les manifestes, dans quel cluster et quel namespace les déployer, et comment synchroniser.
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: boutique-api
namespace: argocd
spec:
project: default
source:
repoURL: https://git.example.com/plateforme/deploiements.git
targetRevision: main
path: apps/boutique-api/overlays/production
destination:
server: https://kubernetes.default.svc
namespace: boutique
syncPolicy:
automated:
prune: true # supprime les ressources retirées du dépôt
selfHeal: true # annule les modifications manuelles dans le cluster
syncOptions:
- CreateNamespace=true
Le dossier overlays/production contient une configuration Kustomize : elle reprend une base commune et fixe, entre autres, le tag d'image à déployer. Pour livrer une nouvelle version, la CI publie l'image, puis ouvre une merge request qui modifie ce tag. Une fois la demande fusionnée, ArgoCD détecte le changement et synchronise le cluster. L'option selfHeal ramène automatiquement toute modification manuelle à l'état décrit dans Git, et prune supprime les ressources qui n'y figurent plus.
Pour éviter de déclarer chaque application à la main, on utilise souvent le motif « app of apps » ou la ressource ApplicationSet, qui génère des applications à partir d'une liste de clusters ou de dossiers.
Dans quels cas utiliser le GitOps ?
Le GitOps donne sa pleine mesure dès que plusieurs environnements, clusters ou équipes doivent rester cohérents dans la durée.
Déploiement continu sur Kubernetes
Livrer les applications d'une équipe à chaque fusion, sans donner d'accès au cluster à la CI.
Gestion multi-clusters
Maintenir des dizaines de clusters alignés à partir d'un même dépôt et de modèles communs.
Promotion entre environnements
Faire passer une version de la préproduction à la production par une simple merge request.
Socle de cluster
Installer et maintenir les briques communes : ingress, certificats, supervision, politiques.
Reprise après sinistre
Reconstruire un cluster complet à l'identique en pointant un agent vers le dépôt.
Environnements réglementés
Prouver qui a déployé quoi et quand, grâce à l'historique Git et aux revues obligatoires.
Quels sont les avantages du GitOps ?
Le GitOps applique à l'exploitation les pratiques éprouvées du développement : versionnement, revue de code et retour arrière.
- Historique complet et auditable de chaque changement de production dans Git.
- Retour arrière simple et rapide par l'annulation d'un commit.
- Sécurité renforcée : la CI n'a plus besoin d'identifiants d'accès au cluster.
- Détection et correction automatique des modifications manuelles non tracées.
- Environnements reproductibles, reconstructibles à partir du seul dépôt.
- Workflow familier pour les développeurs, fondé sur les merge requests.
Quelles sont les limites du GitOps ?
Le GitOps n'est pas une solution universelle : il suppose un système déclaratif et une discipline stricte sur le dépôt.
- Adapté avant tout aux systèmes déclaratifs comme Kubernetes, moins aux scripts impératifs.
- Gestion des secrets délicate : ils ne doivent jamais apparaître en clair dans Git.
- Multiplication des dépôts, branches et dossiers difficiles à organiser à grande échelle.
- Visibilité réduite pour la CI, qui ne sait pas directement si le déploiement a réussi.
- Migrations de bases de données et opérations ponctuelles mal couvertes par la réconciliation.
- Nouvel outil à installer, sécuriser et superviser dans chaque cluster.
GitOps vs CI/CD en push : quelles différences ?
Le GitOps ne s'oppose pas à la CI/CD : il change la manière dont se fait la dernière étape, le déploiement.
| Critère | CI/CD classique (push) | GitOps (pull) |
|---|---|---|
| Qui déploie | Le pipeline CI, depuis l'extérieur | Un agent, depuis l'intérieur du cluster |
| Accès au cluster | La CI détient des identifiants d'administration | Seul l'agent agit ; la CI ne modifie que Git |
| Déclenchement | Ponctuel, à chaque exécution du pipeline | Continu, par comparaison permanente |
| Modifications manuelles | Invisibles jusqu'au prochain déploiement | Détectées, signalées ou annulées |
| Retour arrière | Relancer un ancien pipeline ou un script | Annuler un commit |
| Source de vérité | Dispersée entre scripts, CI et cluster | Le dépôt Git |
| Périmètre naturel | Tout type de cible | Systèmes déclaratifs, Kubernetes en tête |
Dans la plupart des organisations, les deux coexistent : la CI teste, construit et publie l'image, puis met à jour le dépôt de déploiement ; l'agent GitOps prend le relais pour la production.
ArgoCD ou Flux : deux implémentations du GitOps
Les deux outils de référence partagent les mêmes principes mais pas la même philosophie.
- ArgoCD propose une interface web qui affiche l'arbre des ressources de chaque application, leur état de santé et les différences avec Git. Il gère facilement plusieurs clusters depuis une instance centrale, avec une gestion fine des droits par projet. Il se combine avec Argo Rollouts pour les déploiements progressifs.
- Flux est un ensemble de contrôleurs spécialisés (sources, Kustomize, Helm, notifications, mise à jour automatique des images). Sans interface graphique native, il est entièrement piloté par des ressources Kubernetes, ce qui le rend très composable.
Le périmètre du GitOps dépasse d'ailleurs les applications : avec Crossplane, les bases de données, réseaux et buckets Cloud deviennent des objets Kubernetes, réconciliables par le même agent que le reste du cluster.
Faut-il adopter le GitOps ?
Le GitOps devient intéressant lorsque le nombre d'environnements et de personnes qui déploient rend les scripts de déploiement difficiles à maîtriser.
Le GitOps est un bon choix
- Vos applications tournent sur Kubernetes.
- Vous gérez plusieurs environnements ou clusters.
- Vous devez tracer et auditer chaque changement de production.
- Des modifications manuelles font dériver vos environnements.
Une CI/CD classique suffit
- Vous déployez sur des serveurs ou des services managés hors Kubernetes.
- Un seul environnement, rarement modifié, est en jeu.
- Vos manifestes ne sont pas encore décrits de façon déclarative.
- L'équipe découvre Kubernetes et doit d'abord en maîtriser les bases.
Quels outils pour mettre en place le GitOps ?
Une chaîne GitOps combine un agent de réconciliation, un format de description des applications et une solution de gestion des secrets.
- Agent GitOps
ArgoCD
Outil GitOps du projet Argo, avec une interface web riche et un modèle multi-clusters.
- Agent GitOps
Flux
Ensemble de contrôleurs Kubernetes modulaires, créé par Weaveworks.
- Plateforme cible
Kubernetes
L'orchestrateur déclaratif sur lequel s'appuie l'essentiel des chaînes GitOps.
- Packaging
Helm
Gestionnaire de paquets Kubernetes, dont les charts sont déployables par ArgoCD et Flux.
- Configuration
Kustomize
Personnalisation de manifestes par environnement, sans gabarits, intégrée à kubectl.
- Secrets
Sealed Secrets
Chiffrement des secrets pour les stocker dans Git, déchiffrés uniquement dans le cluster.
- Secrets
External Secrets Operator
Synchronisation des secrets depuis Vault ou un gestionnaire Cloud vers Kubernetes.
- Déploiement progressif
Argo Rollouts
Déploiements canary et blue/green pilotés par des métriques, en complément d'ArgoCD.
- Infrastructure
Crossplane
Gestion de ressources Cloud comme des objets Kubernetes, donc réconciliables en GitOps.
Les concepts à connaître autour du GitOps
Le GitOps est la rencontre de l'Infrastructure as Code, du déploiement continu et du modèle déclaratif de Kubernetes.
- Infrastructure as CodeLa description de l'infrastructure en fichiers versionnés, prérequis du GitOps.
- CI/CDLa chaîne qui construit et teste les artefacts avant que GitOps ne les déploie.
- RéconciliationLa boucle qui compare en permanence l'état déclaré et l'état réel pour les aligner.
- Dérive de configurationL'écart qui apparaît quand le système réel ne correspond plus à sa description.
- Déploiement canaryLa mise en production progressive d'une version sur une fraction du trafic.
- Platform EngineeringLa construction de plateformes internes, souvent bâties sur un socle GitOps.
Ressources pour approfondir le GitOps
Trois articles du blog Blent pour passer du principe à une chaîne GitOps opérationnelle.
- Guide
GitOps : définition et exemples
Les principes du GitOps illustrés par des cas concrets de déploiement.
Lire l'article - Outil
ArgoCD : le GitOps sur Kubernetes
Installer ArgoCD, déclarer ses applications et piloter les synchronisations.
Lire l'article - Outil
Helm : gestion de packages sur Kubernetes
Packager ses applications en charts, un format que les agents GitOps savent déployer.
Lire l'article
Questions fréquentes
Questions fréquentes
Expertise
À propos de l'auteur
Équipe Blent
Les ingénieurs et mentors Blent conçoivent, automatisent et mettent en production des infrastructures Cloud, et forment chaque année des centaines de professionnels au Cloud et au DevOps.
Sources et méthodologie
- OpenGitOps, GitOps Principles v1.0.0, CNCF GitOps Working Group
- Alexis Richardson, GitOps - Operations by Pull Request, Weaveworks, 2017
- Documentation officielle d'Argo CD et de Flux
- Retours d'expérience des projets et formations Blent
Comment fonctionne une chaîne GitOps ?
Une chaîne GitOps sépare nettement deux mondes : la CI fabrique les artefacts, puis Git et un agent de réconciliation se chargent du déploiement. Le cycle de vie d'un changement suit six étapes.
Décrire l'état souhaité
Les manifestes Kubernetes, charts Helm ou overlays Kustomize décrivent ce qui doit tourner : images, nombre de réplicas, configuration, ressources réseau. Ils vivent dans un dépôt Git dédié au déploiement.
Proposer un changement
Une nouvelle version, un paramètre modifié ou un nouvel environnement donnent lieu à une merge request. Souvent, c'est la CI elle-même qui ouvre cette demande après avoir publié une nouvelle image.
Relire et fusionner
Le changement est relu, validé par les contrôles automatiques puis fusionné. La fusion vaut décision de déploiement, tracée avec son auteur et sa date.
Détecter l'écart
L'agent GitOps, installé dans le cluster, surveille le dépôt. Il constate que l'état déclaré a changé et calcule la différence avec l'état réel.
Réconcilier
L'agent applique les modifications nécessaires, dans l'ordre voulu, jusqu'à ce que l'état réel corresponde à l'état déclaré. Il rend compte de la santé des ressources déployées.
Corriger la dérive
Si quelqu'un modifie le cluster à la main, l'agent détecte la dérive et la signale ou la corrige automatiquement. Revenir en arrière consiste simplement à annuler un commit.