GitOps : déploiement continu via Git en pratique

Quelqu'un a modifié un paramètre directement en production. Personne ne sait qui. Personne ne sait quand. Et l'application qui fonctionnait hier ne fonctionne plus aujourd'hui.

Ce scénario est le quotidien des équipes qui gèrent leur infrastructure sans discipline de déploiement rigoureuse. Le GitOps est la réponse systémique à ce problème.

Son principe fondamental : Git est la seule source de vérité pour l'état de l'infrastructure et des applications. Tout ce qui n'est pas dans Git n'existe pas. Tout ce qui est dans Git est appliqué automatiquement.

Ce guide vous explique les principes, les outils et les bonnes pratiques pour mettre en place le GitOps en production.

• 77% des organisations ont adopté, à des degrés divers, les principes du GitOps comme méthodologie de livraison logicielle (CNCF Annual Survey 2024)
• Argo est la plateforme CI/CD la plus associée au GitOps, utilisée par 45% des répondants (CNCF Annual Survey 2024)."

Qu'est-ce que le GitOps ?

Le GitOps est une approche opérationnelle qui utilise Git comme source de vérité unique pour l'état désiré de l'infrastructure et des applications. Tout changement d'infrastructure ou de configuration passe par une pull request Git, est reviewé, approuvé et automatiquement appliqué par un opérateur qui synchronise en permanence l'état réel du système avec l'état décrit dans Git.

C'est une évolution naturelle du DevOps qui étend les pratiques d'ingénierie logicielle (versioning, revue de code, CI/CD) à l'exploitation de l'infrastructure. Là où le DevOps rapproche les équipes Dev et Ops autour du déploiement applicatif, le GitOps automatise la réconciliation continue entre ce qui est décrit et ce qui tourne réellement en production.

Les 4 principes OpenGitOps

Le projet OpenGitOps (CNCF) a formalisé quatre principes fondamentaux.

• Déclaratif : l'état désiré du système est décrit de manière déclarative (fichiers YAML, Helm charts, Kustomize overlays). On décrit ce qu'on veut, pas comment l'obtenir
• Versionné et immuable : l'état désiré est stocké dans Git de manière immuable. L'historique complet de chaque modification est consultable et réversible
• Récupéré automatiquement : les agents logiciels (ArgoCD, Flux) récupèrent automatiquement l'état désiré depuis Git et l'appliquent sans intervention humaine
• Réconcilié en continu : les agents surveillent en permanence l'écart entre l'état réel et l'état désiré. Tout drift est automatiquement corrigé

GitOps vs CI/CD classique : la distinction essentielle

Dans un pipeline CI/CD classique, le pipeline "pousse" les changements vers l'environnement cible (push model). Un script kubectl apply ou helm upgrade est exécuté depuis le pipeline.

Dans le GitOps, c'est l'inverse. Un agent déployé dans le cluster "tire" les changements depuis Git (pull model). Le pipeline CI ne touche jamais directement le cluster. Il se contente de mettre à jour le dépôt Git. L'agent se charge du reste.

Cette inversion est fondamentale pour la sécurité : le pipeline n'a plus besoin d'accéder au cluster en production.

Les outils de référence : ArgoCD et Flux

ArgoCD : le standard de facto

ArgoCD est le contrôleur GitOps le plus adopté dans l'écosystème Kubernetes. Il surveille un ou plusieurs dépôts Git et synchronise automatiquement l'état du cluster avec ce qui est décrit dans ces dépôts.

Son interface web est l'une de ses forces distinctives. Elle visualise en temps réel l'état de chaque application déployée, les diffs entre l'état Git et l'état cluster, l'historique des déploiements et les opérations de rollback. C'est un outil particulièrement apprécié des équipes qui débutent en GitOps pour sa lisibilité.

ArgoCD supporte nativement Helm, Kustomize, Jsonnet et les manifests YAML bruts. Son modèle de multi-tenancy et son intégration RBAC en font la solution privilégiée des plateformes Kubernetes partagées entre plusieurs équipes.

Flux : l'alternative GitOps native

Flux est le projet GitOps de la CNCF, co-créé par Weaveworks. Son approche est différente d'ArgoCD : plutôt qu'une application monolithique avec une interface web centrale, Flux est un ensemble de controllers Kubernetes spécialisés (Source Controller, Kustomize Controller, Helm Controller, Notification Controller).

Cette architecture en controllers natifs Kubernetes le rend plus flexible et plus extensible qu'ArgoCD. Il s'intègre naturellement dans des workflows GitOps complexes avec des besoins de multi-tenancy avancés ou d'intégration avec des systèmes externes.

Comparatif ArgoCD vs Flux

Mettre en place le GitOps sur Kubernetes

Structure des dépôts Git

Deux approches principales structurent les dépôts GitOps.

Le monorepo centralise toutes les configurations dans un seul dépôt. Simple à gérer pour les petites équipes, il peut devenir difficile à gouverner avec de nombreuses équipes et applications.

Le multi-repo sépare les configurations par équipe, application ou périmètre fonctionnel. Plus complexe à orchestrer, il offre une isolation claire des responsabilités et des permissions.

Une bonne pratique universelle est de séparer le dépôt du code applicatif du dépôt de configuration GitOps. Le pipeline CI met à jour le dépôt de configuration. L'agent GitOps synchronise le cluster depuis ce dépôt.

Gestion des environnements

Chaque environnement (dev, staging, prod) correspond à une branche ou un répertoire dédié dans le dépôt GitOps. La promotion d'une version de dev vers staging puis vers prod se fait via des pull requests ou des merge automatisés entre branches.

Cette structure garantit que la prod ne peut être modifiée que par le processus défini, jamais directement.

Helm et Kustomize : gestion des configurations

Helm encapsule les applications Kubernetes en charts paramétrables. Dans un workflow GitOps, ArgoCD ou Flux appliquent les charts Helm directement depuis Git, avec les paramètres spécifiques à chaque environnement.

Kustomize permet de personnaliser des manifests YAML de base avec des overlays spécifiques à chaque environnement, sans templating. Il est natif dans kubectl et particulièrement adapté aux équipes qui préfèrent éviter la complexité du templating Helm.

Secrets management dans un workflow GitOps

Les secrets ne doivent jamais apparaître en clair dans Git. Trois approches sont couramment utilisées.

Sealed Secrets chiffre les secrets dans Git avec une clé asymétrique. Seul le contrôleur déployé dans le cluster peut les déchiffrer.

External Secrets Operator synchronise les secrets depuis un gestionnaire externe (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault) vers les Secrets Kubernetes.

SOPS (Secrets OPerationS) chiffre les fichiers de secrets avec des clés PGP, KMS ou Age avant de les committer dans Git.

GitOps en production : bonnes pratiques

1. Séparer strictement les dépôts application et infrastructure

Le code applicatif et la configuration de déploiement ont des cycles de vie différents et des équipes responsables différentes. Les mélanger dans le même dépôt crée du couplage et de la confusion.

2. Définir des stratégies de promotion explicites

La promotion entre environnements doit être un processus documenté et automatisable : pull request avec revue, tests automatiques sur l'environnement cible, approbation humaine pour la production. Éviter les promotions ad hoc qui contournent le processus.

3. Monitorer le drift en continu

Le drift de configuration survient quand l'état réel du cluster s'éloigne de l'état décrit dans Git. ArgoCD et Flux le détectent et le corrigent automatiquement. Configurez des alertes pour être notifié quand un drift persiste malgré les tentatives de réconciliation.

4. Instrumenter l'observabilité du pipeline GitOps

Les métriques de déploiement (fréquence, temps de synchronisation, taux d'échec) doivent être visibles dans votre plateforme d'observabilité. ArgoCD expose des métriques Prometheus nativement, Flux également.

GitOps et sécurité : RBAC et audit trail

Le pull model : l'avantage sécurité fondamental

Dans un modèle push classique, le pipeline CI/CD dispose d'accès en écriture au cluster de production. Un credential compromis peut déclencher des modifications non autorisées directement en production.

Dans le modèle pull du GitOps, le pipeline n'a jamais accès au cluster. Il écrit seulement dans Git. C'est l'agent dans le cluster qui récupère et applique les changements. La surface d'attaque est radicalement réduite.

Contrôle d'accès dans ArgoCD

ArgoCD dispose d'un système RBAC qui contrôle qui peut synchroniser quelles applications, depuis quels dépôts et vers quels clusters. Les permissions sont définies de manière déclarative et versionnées dans Git comme le reste de la configuration.

Traçabilité complète

Chaque déploiement est tracé dans Git avec l'auteur de la pull request, le reviewer, la date d'approbation et le hash du commit appliqué. En cas d'incident, l'audit trail est complet et inaltérable. Le rollback se fait en un seul git revert ou en une opération ArgoCD.

Smile et le GitOps : notre pratique en production

Chez Smile, nous implémentons des workflows GitOps en production depuis l'émergence du paradigme. Notre pratique couvre ArgoCD pour les plateformes Kubernetes multi-équipes, Flux pour les architectures nécessitant une extensibilité maximale, et les deux en configuration hybride pour les clients avec des exigences très spécifiques.

Nous accompagnons les équipes DevOps et les ingénieurs qui débutent en GitOps avec des formations pratiques orientées cas d'usage réels, du devops junior qui découvre ArgoCD jusqu'à l'architecte plateforme qui conçoit une stratégie multi-cluster.

Notre conviction : une infrastructure sans GitOps est une infrastructure dont personne ne connaît vraiment l'état à un instant T.

Vous souhaitez mettre en place le GitOps dans votre organisation ? Découvrez notre approche GitOps en pratique.

Questions fréquentes sur le GitOps

GitOps fonctionne-t-il uniquement avec Kubernetes ?

Non, mais c'est là où il est le plus mature. Les principes GitOps (Git comme source de vérité, réconciliation continue, pull model) s'appliquent à n'importe quelle infrastructure. Terraform avec un backend GitOps, Ansible piloté depuis Git, des configurations serveur gérées via Flux : le GitOps peut s'étendre au-delà de Kubernetes. Cependant, l'écosystème d'outils (ArgoCD, Flux) est optimisé pour Kubernetes et c'est dans cet environnement qu'il offre la meilleure expérience.

Quelle est la différence entre GitOps et CI/CD ?

Le CI/CD couvre l'intégration continue (tests, builds) et le déploiement continu (livraison automatisée). Le GitOps est une approche spécifique du déploiement continu qui impose le pull model et Git comme source de vérité. On peut avoir du CI/CD sans GitOps (pipeline qui pousse directement vers le cluster). On ne peut pas avoir de GitOps sans CI/CD (le pipeline CI est nécessaire pour mettre à jour les images et les configurations dans Git).

ArgoCD ou Flux : comment choisir ?

Pour une équipe qui débute, ArgoCD est recommandé grâce à son interface web intuitive qui rend le GitOps visible et compréhensible immédiatement. Pour une équipe avancée qui veut une intégration profonde dans l'écosystème Kubernetes et une extensibilité maximale, Flux est préférable. Les deux sont de très bons choix et de nombreuses organisations utilisent les deux selon les cas d'usage.

Comment gérer les secrets dans un workflow GitOps sans les exposer dans Git ?

Trois approches sont recommandées selon le contexte. Sealed Secrets pour sa simplicité et son indépendance vis-à-vis des services externes. External Secrets Operator pour les organisations qui ont déjà un gestionnaire de secrets (Vault, AWS Secrets Manager). SOPS pour les équipes qui préfèrent une solution légère sans infrastructure supplémentaire. Les trois s'intègrent nativement avec ArgoCD et Flux.