Introduction au GitOps : Gérer l'infrastructure et les applications via Git

Repenser l'automatisation du déploiement pour Kubernetes

L'approche traditionnelle consistant à pousser les déploiements depuis un système CI/CD, bien que fonctionnelle, présente des défis en termes de sécurité, de cohérence et de gestion de l'état réel du cluster. Comment garantir que l'état de votre cluster Kubernetes correspond exactement à ce qui a été déployé ? Comment gérer la dérive de configuration (lorsque des changements manuels sont appliqués au cluster) ? Comment sécuriser les credentials donnant un accès potentiellement large au cluster depuis l'extérieur ?

Face à ces questions, une nouvelle approche a émergé et gagné une popularité significative dans l'écosystème Cloud Native, particulièrement adaptée à la nature déclarative de Kubernetes : le GitOps.

GitOps n'est pas un outil spécifique, mais plutôt un modèle opérationnel ou un ensemble de pratiques qui utilise Git comme unique source de vérité pour l'infrastructure et les applications. Au lieu de pousser les changements depuis un pipeline CI/CD, GitOps adopte un modèle "pull" où l'état désiré, défini de manière déclarative dans un dépôt Git, est automatiquement appliqué et maintenu dans le cluster par des agents spécialisés.

Les principes fondamentaux du GitOps

Le GitOps repose sur quatre principes clés :

1. L'ensemble du système est décrit de manière déclarative : L'état désiré de toute votre infrastructure (configurations Kubernetes, manifestes d'application, etc.) doit être défini dans un format déclaratif (comme les fichiers YAML Kubernetes, les Charts Helm, ou les Kustomizations).
2. L'état désiré du système est versionné dans Git : Le dépôt Git est considéré comme l'unique source de vérité faisant autorité. Toute modification de l'état désiré doit passer par un commit dans Git.
3. Les changements approuvés sont appliqués automatiquement au système : Des agents logiciels s'exécutant dans le cluster surveillent en permanence le dépôt Git. Lorsqu'ils détectent une différence entre l'état défini dans Git et l'état réel du cluster, ils appliquent automatiquement les changements nécessaires pour faire converger le cluster vers l'état décrit dans Git (modèle "pull").
4. Assurance de l'état et divergence : Les agents assurent en continu que l'état du cluster correspond à la source de vérité dans Git. Ils détectent et peuvent corriger (ou alerter sur) toute dérive de configuration (changements manuels non reflétés dans Git).

Comment fonctionne le GitOps en pratique ?

Le flux de travail typique en GitOps ressemble à ceci :

1. Développement & CI : Un développeur modifie le code de l'application. Le pipeline CI traditionnel s'exécute : tests, construction de l'image conteneur, et pousse l'image vers un registre. Crucialement, le pipeline CI ne déploie PAS directement sur le cluster.
2. Mise à jour de la configuration : Au lieu de déployer, le pipeline CI (ou un développeur/opérateur via une Pull Request) met à jour la configuration déclarative dans un dépôt Git dédié à la configuration (souvent appelé "Config Repo"). Cette mise à jour peut consister à changer le tag de l'image dans un fichier YAML, à modifier une valeur dans un fichier values.yaml de Helm, ou à ajuster une Kustomization.
3. Détection du changement par l'agent GitOps : Un agent GitOps (comme Argo CD ou Flux), déployé dans le cluster Kubernetes, surveille en permanence le Config Repo. Il détecte le nouveau commit ou la mise à jour de la branche/du tag qu'il suit.
4. Comparaison et Synchronisation : L'agent compare l'état désiré défini dans le Config Repo avec l'état actuel des ressources dans le cluster Kubernetes.
5. Application des changements : Si une différence est détectée, l'agent utilise l'API Kubernetes pour appliquer les changements nécessaires (création, mise à jour, suppression de ressources) afin que l'état du cluster corresponde exactement à ce qui est décrit dans Git.
6. Surveillance continue : L'agent continue de surveiller à la fois le dépôt Git et le cluster pour maintenir la synchronisation et corriger toute dérive éventuelle.

Les bénéfices majeurs de l'approche GitOps

L'adoption du GitOps apporte des avantages significatifs, particulièrement dans le contexte Kubernetes :

• Fiabilité et Stabilité : L'état désiré est clairement défini et versionné. Les rollbacks sont aussi simples qu'un git revert suivi d'une synchronisation par l'agent.
• Cohérence : Garantit que l'état du cluster (ou de plusieurs clusters/environnements) correspond toujours à la définition dans Git, éliminant la dérive de configuration.
• Sécurité Améliorée : L'agent dans le cluster initie les connexions sortantes vers Git (modèle "pull"), réduisant la nécessité d'exposer des credentials Kubernetes sensibles à l'extérieur du cluster. Les actions sont limitées par le ServiceAccount de l'agent.
• Auditabilité et Visibilité : L'historique Git fournit une piste d'audit complète de tous les changements apportés à l'infrastructure et aux applications (qui a changé quoi, quand, et pourquoi via les messages de commit).
• Expérience Développeur : Les développeurs utilisent des outils et des flux de travail qu'ils connaissent bien (Git, Pull Requests) pour gérer les déploiements.
• Productivité : Accélère les déploiements en les automatisant de manière fiable après la validation des changements dans Git.

GitOps et CI/CD : des approches complémentaires

Il est important de noter que GitOps ne remplace pas nécessairement la CI. Au contraire, ils sont souvent complémentaires. La CI reste responsable de la construction, des tests et de la publication des artefacts (comme les images conteneurs). Le GitOps prend ensuite le relais pour gérer le déploiement et le cycle de vie de ces artefacts sur l'infrastructure, en se basant sur les changements de configuration validés dans Git.

GitOps représente un changement de paradigme vers une gestion d'infrastructure véritablement déclarative, automatisée et sécurisée, s'alignant parfaitement sur la philosophie de Kubernetes. Dans la section suivante, nous explorerons les outils populaires qui permettent de mettre en oeuvre cette approche.