GitOps & ArgoCD
GitOps transforme Git en source de vérité pour l'infrastructure. Découvrez comment ArgoCD automatise les déploiements Kubernetes, détecte les dérives et améliore la sécurité.
GitOps avec ArgoCD et Kubernetes : construire une plateforme de déploiement moderne
Les infrastructures modernes sont devenues de plus en plus complexes. Les applications sont distribuées sur plusieurs environnements, exécutées dans des conteneurs et déployées sur des clusters Kubernetes. Dans ce contexte, effectuer manuellement les déploiements devient rapidement difficile à maintenir.
Les équipes DevOps ont donc besoin d'une méthode permettant d'automatiser les déploiements tout en conservant une visibilité complète sur les changements effectués dans l'infrastructure.
C'est dans ce contexte qu'est apparu le concept de GitOps.
GitOps utilise Git comme source de vérité pour définir l'état souhaité d'une infrastructure ou d'une application. Un outil comme ArgoCD surveille ensuite cette configuration et s'assure que le cluster Kubernetes correspond continuellement à cet état.
1. Qu'est-ce que GitOps ?
GitOps est une approche opérationnelle qui utilise un repository Git comme source de vérité pour l'état souhaité d'un système.
Au lieu de modifier directement un cluster Kubernetes avec des commandes manuelles, les changements sont décrits dans des fichiers versionnés dans Git.
Le cluster est ensuite synchronisé automatiquement avec cette configuration.
On peut résumer le principe avec la chaîne suivante :
Developer
|
v
Git Repository
|
v
Pull Request
|
v
Validation
|
v
ArgoCD
|
v
Kubernetes
Git devient ainsi beaucoup plus qu'un simple outil utilisé pour stocker du code source. Il devient également le registre historique de l'infrastructure.
Visualisation du modèle GitOps
2. Les limites des déploiements traditionnels
Avant GitOps, de nombreuses équipes administraient leurs environnements Kubernetes en exécutant directement des commandes depuis leur machine locale ou depuis des serveurs CI.
Une procédure pouvait par exemple ressembler à :
kubectl apply -f deployment.yaml
kubectl apply -f service.yaml
kubectl apply -f ingress.yaml
Cette approche fonctionne parfaitement pour apprendre Kubernetes ou effectuer de petites opérations.
Cependant, elle devient problématique lorsque plusieurs développeurs, plusieurs environnements et plusieurs clusters doivent être gérés.
Problème 1 : manque de traçabilité
Si quelqu'un modifie directement une ressource Kubernetes, il peut être difficile de déterminer précisément qui a effectué la modification et pourquoi.
Problème 2 : configuration différente entre environnements
Il peut également arriver qu'un environnement de production soit légèrement différent de celui décrit dans les fichiers du projet.
Problème 3 : changements manuels
Les modifications manuelles créent progressivement ce qu'on appelle une configuration drift.
Problème 4 : rollback compliqué
Lorsqu'un déploiement échoue, revenir exactement à la configuration précédente peut devenir difficile si l'historique des modifications n'est pas correctement conservé.
3. Les principes fondamentaux du GitOps
Une architecture GitOps repose généralement sur plusieurs principes.
Déclaratif
L'infrastructure doit être décrite de manière déclarative. On décrit ce que l'on souhaite obtenir plutôt que la succession exacte des commandes nécessaires pour y parvenir.
replicas: 3
image: myapp:v2
Kubernetes se charge ensuite d'atteindre cet état.
Versionné
Toutes les configurations doivent être stockées dans un système de contrôle de version.
Git fournit naturellement cette fonctionnalité.
Automatisé
Une fois qu'un changement est validé, le déploiement peut être réalisé automatiquement.
Réconcilié
Le système doit continuellement comparer l'état réel avec l'état souhaité et corriger les différences lorsque cela est nécessaire.
4. Qu'est-ce qu'ArgoCD ?
ArgoCD est un outil de Continuous Delivery conçu spécialement pour les environnements Kubernetes.
Son rôle principal est de maintenir le cluster Kubernetes synchronisé avec les manifests présents dans Git.
ArgoCD fonctionne selon un modèle de réconciliation.
Git
|
| Desired State
v
ArgoCD
|
| Compare
v
Kubernetes
|
| Live State
v
ArgoCD
Si les deux états correspondent, l'application est considérée comme Synced.
S'ils diffèrent, ArgoCD détecte une situation de OutOfSync.
5. Architecture GitOps complète
Une architecture GitOps moderne sépare généralement plusieurs responsabilités.
Developer
|
v
Git Pull Request
|
v
+------------------+
| CI Pipeline |
| |
| Tests |
| Lint |
| Security Scan |
| Build |
+--------+---------+
|
v
Container Registry
|
v
GitOps Repository
|
v
ArgoCD
|
v
Kubernetes Cluster
|
+-------------+-------------+
| |
Application Database
Cette séparation permet d'éviter de mélanger les responsabilités de la CI et du CD.
- CI : tester, scanner et construire.
- Registry : stocker les images.
- Git : stocker l'état souhaité.
- ArgoCD : synchroniser Kubernetes.
6. Desired State et Live State
L'un des concepts les plus importants du GitOps est la différence entre Desired State et Live State.
Desired State
Le Desired State représente la configuration que nous voulons obtenir. Il est généralement stocké dans Git.
replicas: 3
image: myapp:v1.5.0
Live State
Le Live State correspond à ce qui existe réellement dans Kubernetes.
replicas: 3
image: myapp:v1.5.0
Lorsque les deux états sont identiques, l'environnement est cohérent.
Mais imaginons qu'un administrateur exécute :
kubectl scale deployment myapp --replicas=5
Le cluster contient maintenant :
replicas: 5
alors que Git contient toujours :
replicas: 3
ArgoCD détecte alors une différence entre les deux états.
7. Détection des dérives
Une dérive, ou configuration drift, apparaît lorsque l'état réel du cluster ne correspond plus à l'état déclaré dans Git.
Exemple :
Git:
Deployment
replicas = 3
Kubernetes:
Deployment
replicas = 5
ArgoCD peut détecter automatiquement cette différence.
Selon la configuration choisie, l'équipe peut :
- examiner la différence ;
- effectuer une synchronisation manuelle ;
- activer la synchronisation automatique.
Ce mécanisme est particulièrement utile pour maintenir la cohérence des environnements de production.
8. Comment organiser un repository GitOps ?
L'organisation du repository devient rapidement importante lorsque plusieurs applications et environnements sont gérés.
Une structure simple peut être :
gitops/
│
├── applications/
│ ├── api/
│ │ ├── deployment.yaml
│ │ ├── service.yaml
│ │ └── ingress.yaml
│ │
│ └── frontend/
│ ├── deployment.yaml
│ ├── service.yaml
│ └── ingress.yaml
│
├── environments/
│ ├── development/
│ ├── staging/
│ └── production/
│
└── argocd/
└── applications/
Pour des projets plus importants, Helm ou Kustomize peuvent être utilisés afin d'éviter de dupliquer les manifests.
9. Créer une application ArgoCD
ArgoCD représente chaque application déployée à travers une ressource Kubernetes appelée Application.
Un exemple simplifié :
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: my-application
namespace: argocd
spec:
project: default
source:
repoURL: https://github.com/example/gitops.git
targetRevision: main
path: applications/my-application
destination:
server: https://kubernetes.default.svc
namespace: my-application
syncPolicy:
automated:
prune: true
selfHeal: true
Plusieurs informations importantes apparaissent ici.
repoURL
Indique le repository Git contenant les manifests.
targetRevision
Indique la branche ou la révision utilisée.
path
Indique l'emplacement des manifests dans le repository.
destination
Définit le cluster et le namespace dans lesquels l'application doit être déployée.
10. Intégrer GitOps avec une pipeline CI
GitOps ne remplace pas la Continuous Integration.
Au contraire, CI et GitOps peuvent fonctionner ensemble.
Une pipeline moderne peut suivre ce workflow :
Pull Request
|
v
+---------------+
| CI Pipeline |
+---------------+
|
+----------+----------+
| | |
v v v
Tests SAST Build
| | |
+----------+----------+
|
v
Docker Image
|
v
Container Registry
|
v
Update Git Manifest
|
v
Git
|
v
ArgoCD
|
v
Kubernetes
La CI peut construire une nouvelle image Docker.
docker build -t myapp:1.6.0 .
docker push registry.example.com/myapp:1.6.0
Le repository GitOps peut ensuite être mis à jour :
image:
repository: registry.example.com/myapp
tag: 1.6.0
ArgoCD détecte le changement et déploie automatiquement la nouvelle version.
11. GitOps et DevSecOps
GitOps devient particulièrement intéressant lorsqu'il est intégré dans une stratégie DevSecOps.
Chaque modification peut être contrôlée avant son arrivée en production.
Pull Requests
Les modifications de l'infrastructure peuvent être soumises sous forme de Pull Requests.
Code Review
Un ou plusieurs membres de l'équipe peuvent analyser les modifications avant leur validation.
Security Scanning
Des outils peuvent analyser :
- les images Docker ;
- les manifests Kubernetes ;
- les dépendances ;
- les secrets accidentellement commités ;
- les mauvaises configurations.
Policy as Code
Des politiques peuvent également être appliquées automatiquement afin d'empêcher certaines configurations dangereuses.
12. Gérer Development, Staging et Production
Une plateforme professionnelle possède généralement plusieurs environnements.
development
|
v
staging
|
v
production
Chaque environnement peut utiliser une configuration différente tout en conservant la même application.
Par exemple :
development
replicas: 1
staging
replicas: 2
production
replicas: 5
Kustomize ou Helm permettent de gérer efficacement ces variations.
13. Rollback : revenir rapidement à une version précédente
L'un des avantages importants du GitOps est la facilité avec laquelle une modification peut être annulée.
Supposons que la version :
myapp:v2.4.0
provoque un problème en production.
Si la version précédente était :
myapp:v2.3.0
il suffit de restaurer la configuration correspondante dans Git.
git revert <commit>
git push
ArgoCD détectera ensuite la nouvelle configuration et synchronisera Kubernetes.
Le rollback devient donc une opération Git plutôt qu'une succession de commandes manuelles exécutées directement sur le cluster.
14. Bonnes pratiques GitOps
1. Protéger la branche principale
La branche contenant la configuration de production doit être protégée. Les modifications doivent passer par des Pull Requests.
2. Ne pas stocker les secrets en clair
Les credentials et secrets sensibles ne doivent jamais être stockés directement dans Git en texte brut.
3. Utiliser le principe du moindre privilège
ArgoCD et les différents ServiceAccounts doivent disposer uniquement des permissions nécessaires.
4. Séparer les environnements
Les configurations de développement, staging et production doivent être clairement séparées.
5. Valider les manifests avant le déploiement
Les manifests Kubernetes doivent être validés automatiquement dans la CI.
6. Scanner les images
Une image contenant des vulnérabilités critiques ne devrait pas être déployée automatiquement en production.
7. Surveiller le cluster
GitOps automatise le déploiement, mais l'observabilité reste essentielle. Les métriques, logs et traces permettent de vérifier que l'application fonctionne réellement après le déploiement.
15. GitOps : une nouvelle façon de penser l'infrastructure
Le changement le plus important apporté par GitOps n'est pas simplement l'automatisation d'un déploiement.
Il s'agit surtout de changer la relation entre les équipes et leur infrastructure.
Dans un modèle traditionnel, un administrateur peut modifier directement l'environnement.
Dans un modèle GitOps, l'infrastructure devient une configuration versionnée, reviewable et reproductible.
Traditional:
Human
|
+----> Kubernetes
|
+----> Manual Changes
|
+----> Configuration Drift
GitOps:
Human
|
v
Git
|
v
Review
|
v
ArgoCD
|
v
Kubernetes
Cette approche rapproche finalement la gestion de l'infrastructure du développement logiciel traditionnel.
16. GitOps dans une architecture Cloud Native
GitOps s'intègre naturellement dans une architecture Cloud Native.
Git
|
+-------+-------+
| |
CI GitOps
| |
v v
Container ArgoCD
Registry |
| |
+-------+-------+
|
v
Kubernetes
|
+-------------+-------------+
| | |
Frontend API Workers
| | |
+-------------+-------------+
|
Database
Cette architecture permet d'automatiser une grande partie du cycle de vie applicatif.
17. Les avantages du GitOps
Traçabilité
Chaque changement possède un historique Git permettant de savoir quand et pourquoi une modification a été effectuée.
Automatisation
Les déploiements peuvent être synchronisés automatiquement sans intervention manuelle répétitive.
Reproductibilité
Un environnement peut être reconstruit à partir des configurations stockées dans Git.
Rollback
Une version précédente peut être restaurée grâce à l'historique Git.
Sécurité
Les modifications peuvent être contrôlées et analysées avant leur déploiement.
Détection de Drift
Les différences entre Git et le cluster peuvent être détectées automatiquement.
18. GitOps ne signifie pas uniquement ArgoCD
Il est important de faire une distinction entre le concept et l'outil.
GitOps est une méthodologie et un ensemble de pratiques.
ArgoCD est l'un des outils permettant d'implémenter cette approche avec Kubernetes.
D'autres outils existent également dans l'écosystème GitOps.
Le choix de l'outil dépend de l'architecture, des besoins de l'équipe et des contraintes de l'organisation.
19. GitOps et l'avenir des plateformes Kubernetes
Avec la croissance des architectures Cloud Native, le nombre de ressources Kubernetes à gérer augmente rapidement.
Une équipe peut devoir gérer :
- plusieurs clusters ;
- plusieurs régions Cloud ;
- plusieurs environnements ;
- des dizaines d'applications ;
- des centaines de services.
Dans ce contexte, les opérations manuelles deviennent difficiles à maintenir.
GitOps permet de transformer la gestion de l'infrastructure en un processus déclaratif, automatisé et auditable.
20. Conclusion
GitOps représente une évolution importante dans la manière de gérer les infrastructures Kubernetes.
En utilisant Git comme source de vérité, les équipes peuvent versionner leurs configurations, effectuer des revues de code, appliquer des contrôles de sécurité et automatiser les déploiements.
ArgoCD ajoute une couche de réconciliation permettant de maintenir le cluster Kubernetes aligné avec l'état déclaré dans Git.
Une architecture complète peut alors suivre ce modèle :
Developer
|
v
Pull Request
|
v
CI / Security
|
v
Container Registry
|
v
GitOps Repository
|
v
ArgoCD
|
v
Kubernetes
|
v
Monitoring
Le résultat est une infrastructure plus automatisée, traçable, reproductible et sécurisée.
Mais GitOps ne doit pas être considéré comme une simple solution de déploiement. C'est surtout une manière de concevoir et de gérer les infrastructures modernes en rapprochant le monde du développement, de l'infrastructure et de la sécurité.
Git devient la source de vérité. ArgoCD assure la réconciliation. Kubernetes exécute l'état souhaité.
À retenir
- GitOps utilise Git comme source de vérité.
- Kubernetes représente l'état réel de l'infrastructure.
- ArgoCD compare et réconcilie les deux états.
- Les Pull Requests permettent de contrôler les changements.
- La CI peut gérer les tests, les scans et la construction des images.
- GitOps facilite les rollbacks et l'audit.
- La détection de drift permet d'identifier les changements manuels.
- GitOps constitue une excellente base pour une stratégie DevSecOps Cloud Native.