GitOps : Le Guide Complet pour l’automatisation de Kubernetes

DevOps d’abord et maintenant GitOps ?

Mais “pour aller où avec tout ça”, te demandes-tu n’est-ce pas ?

Relaxe : après avoir lu cet article tout sera désormais clair pour toi.

Tu sais…

La gestion d’applications et d’infrastructures dans le cloud est un vrai défi. Maintenant imagine qu’il soit possible de dire adieu aux déploiements manuels, aux configurations qui divergent et aux retards de mise en production ?

Imagine que chaque modification de ton code déclenche automatiquement et en toute sécurité un déploiement sur ton cluster Kubernetes.

C’est exactement cela, la promesse de GitOps, une méthodologie fiable qui devient rapidement le standard pour livrer des applications sur des plateformes d’orchestration de conteneurs comme Kubernetes.

Ce guide complet t’offre une vision claire de ce qu’est le GitOps, ses bénéfices, les outils à ta disposition et un plan d’action pour te lancer.

🎁 Tu es un chef d'entreprise préoccupé à générer plus de croissance pour ton business en cette ère de l'intelligence artificielle ?

J'offre 1h de consultation gratuite à tous les chefs d'entreprises qui lisent mon blog.

💡 Le but est de découvrir vos challenges afin de vous proposer un plan d'action personnalisé pour votre situation particulière.

🟩 Intéressé.e ? Écris-moi: miakassissa@miakassissa.com

Qu’est-ce que GitOps ?

GitOps est un puissant cadre opérationnel utilisant Git comme source unique de vérité pour à la fois, ton infrastructure et tes applications.

Au lieu d’apporter manuellement des modifications à un serveur de production, tu peux tout simplement déclarer l’état désiré ou souhaité de ton système dans le code et le stocker dans un référentiel ou repository Git.

Un processus automatisé, souvent identifié sous l’appellation “pipeline CI/CD”, surveille ensuite en permanence ce référentiel et s’assure que l’environnement en production correspond à l’état déclaré.

GitOps fait en fait référence la partie « Ops » de DevOps, mais pilotée par un workflow centré sur Git.

Les 3 principes fondamentaux du GitOps

Le GitOps s’appuie sur trois piliers simples mais puissants, qui guident chaque aspect de ton flux de travail.

1. Git est la seule source de vérité

Oublie les configurations éparpillées ou les modifications manuelles directement sur ton cluster.

Avec le GitOps, l’état désiré de toute ton infrastructure et de tes applications est stocké et géré dans un ou plusieurs dépôts Git.

Ton dépôt Git n’est pas seulement un lieu de stockage, c’est la source de vérité unique et incontestée pour l’ensemble de ton système.

2. Tout est “Code”

Le principe de l’Infrastructure as Code (IaC) est au cœur du GitOps.

Cela signifie que l’état désiré de ton système doit être exprimé de manière déclarative, dans des fichiers de configuration versionnés et immuables comme des manifests Kubernetes.

Tu ne donnes pas des instructions (“fais ceci, puis cela”), tu décris juste l’état final que tu souhaites obtenir ou avoir en production.

3. Les opérations se font via des workflows Git

Adieu les scripts complexes et les commandes de déploiement à la main.

Avec GitOps, toutes les opérations, comme les déploiements ou les mises à jour, sont effectuées à travers des workflows Git familiers, comme les pull requests.

Un agent logiciel va ensuite surveiller ton dépôt Git et appliquer automatiquement l’état désiré sur ton cluster.

Pourquoi adopter le GitOps ?

Le GitOps n’est pas qu’une simple tendance ; c’est un cadre de travail qui résout des problèmes concrets pour les équipes de développement (Dev) et d’opérations (Ops).

Un workflow standardisé

En utilisant Git, un outil que tous les développeurs connaissent, tu crées un workflow unique pour tout le monde, du développement de l’application à sa gestion.

Fini les silos, toute l’équipe parle le même langage.

Sécurité et auditabilité renforcées

Chaque changement, qu’il s’agisse d’une nouvelle fonctionnalité ou d’une mise à jour de l’infrastructure, est tracé, examiné et historisé – loggué – dans Git.

Cela facilite grandement l’audit et permet de détecter les modifications non désirées (ce que l’on appelle la dérive de configuration ou drift en Anglais) avant qu’elles n’atteignent la production.

Cohérence et fiabilité multicluster

Tu as plusieurs environnements (développement, staging, production) ou plusieurs clusters Kubernetes ?

La gestion de plusieurs environnements ou clusters Kubernetes est l’un des plus grands défis de l’automatisation. GitOps résout ce problème de manière élégante et fiable en permettant de les configurer de manière fiable et cohérente en te basant sur un seul dépôt.

La fin des configurations “spaghettis” 🍝

Avant le GitOps, gérer des clusters multiples était un véritable casse-tête.

Imagine que tu aies un environnement de développement, un de staging et un de production.

Au fil du temps, des ajustements manuels sont faits sur chaque cluster.

Ton développeur a besoin d’une permission supplémentaire sur le cluster de dev, ton équipe d’assurance qualité (QA) modifie une configuration sur celui de staging, et une mise à jour d’urgence est appliquée directement sur la production.

Résultat ?

Tes environnements ne sont plus synchronisés.

Tu te retrouves avec des configurations “spaghetti” : un plat de lignes désordonnées, impossible à retracer et à reproduire.

Un déploiement qui fonctionne parfaitement en staging peut échouer en production pour des raisons que personne ne peut expliquer, car les environnements sont devenus différents.

Le GitOps élimine ce chaos en forçant la centralisation de toutes tes configurations. Tu as un seul dépôt Git (ou un ensemble de dépôts bien organisés) qui contient l’état désiré pour tous tes clusters, du dev à la production.

En somme, GitOps transforme la gestion de plusieurs clusters d’un processus manuel, propice aux erreurs et aux dérives, en un workflow automatisé, fiable et transparent, où ton dépôt Git devient la véritable tour de contrôle de ton infrastructure.

C’est l’essence même de l’automatisation à grande échelle.

Déploiement plus rapide et agile

Le GitOps automatise le déploiement de tes applications, ce qui réduit considérablement le temps nécessaire pour passer d’une idée à un produit fonctionnel en production.

C’est un facteur clé pour l’agilité de ton organisation.

GitOps vs DevOps ?

Le DevOps est une culture qui promeut l’automatisation et la collaboration entre le développement et les opérations.

Le GitOps, quant à lui, est une des mises en œuvre de cette culture.

En d’autres termes, le GitOps est la réponse concrète pour l’automatisation de l’infrastructure et du cycle de vie des applications sur Kubernetes, une facette du grand mouvement DevOps.

Le GitOps introduit un concept crucial : la boucle GitOps.

C’est un cycle en quatre étapes qui assure que ton cluster est toujours dans l’état souhaité.

• Déployer : L’agent GitOps applique les manifests (fichiers de configuration) de ton dépôt Git sur le cluster.
• Monitorer : Il surveille en permanence l’état de ton dépôt Git et l’état de ton cluster.
• Détecter la dérive (drift) : L’agent compare l’état réel de ton cluster avec l’état désiré dans Git. Si une différence est détectée, il y a une dérive de configuration.
• Agir : L’agent prend une action pour corriger la dérive, par exemple en remettant le cluster dans l’état désiré défini et déclaré par Git.

L’écosystème GitOps sur Kubernetes : les outils incontournables

Le GitOps, comme le DevOps, est une méthodologie, pas un produit unique.

Pour la mettre en œuvre, tu auras besoin de plusieurs outils qui travaillent ensemble.

Déploiement continu (CD) : Argo CD ou Flux CD

Argo CD est le moteur GitOps par excellence.

Il agit comme un contrôleur dans ton cluster, surveillant en permanence ton dépôt Git pour détecter les changements et synchroniser l’état de l’application.

Il prend en charge de multiples formats de manifests, comme Kustomize et Helm.

Intégration continue (CI) : Tekton & GitHub Actions

Le rôle du CI est de build et de tester ton application.

Tekton

Tekton est un système de CI/CD natif de Kubernetes qui te permet de créer des pipelines flexibles avec des Tasks et des Pipelines réutilisables.

Les Pipelines Tekton sont une suite de tâches (Tasks) qui s’exécutent dans un ordre précis pour créer, tester et déployer ton application.

Ce qui les rend particulièrement puissants, c’est leur nature réutilisable.

Dans Tekton, un Pipeline est une ressource Kubernetes qui définit une séquence d’exécution des tâches.

Au lieu de définir chaque étape du processus directement dans le Pipeline, tu fais référence à des tâches (Tasks) préexistantes.

Ces tâches sont des building blocks autonomes qui effectuent une fonction spécifique, comme compiler une application, construire une image conteneur ou déployer sur Kubernetes.

L’approche de la réutilisabilité se manifeste de plusieurs façons :

• Modularité : Le Pipeline est une composition de tâches indépendantes. Tu peux donc créer une seule tâche pour, par exemple, compiler un projet Java avec Maven, et la réutiliser dans de multiples Pipelines pour différents projets. Cela évite de réécrire la même logique et assure une cohérence dans tes processus.
• Flexibilité grâce aux paramètres : Les Pipelines et les tâches peuvent être configurés pour accepter des paramètres, ce qui les rend dynamiques. Par exemple, tu peux créer un Pipeline de déploiement qui accepte le nom du dépôt Git et la version de l’image conteneur comme paramètres. Tu n’as pas besoin de créer un nouveau Pipeline pour chaque projet ou chaque version ; il suffit de changer les paramètres à chaque exécution.
• Partage des ressources : Un Pipeline peut définir des espaces de travail (Workspaces) pour permettre aux tâches de partager des fichiers et des données. Par exemple, une tâche peut cloner le code source dans un espace de travail, et la tâche suivante peut compiler ce même code en accédant au même espace de travail.

L’un des plus grands atouts de cette modularité est la possibilité de centraliser des tâches et des Pipelines dans des catalogs ou des Hubs.

Tekton Hub est une plateforme web dédiée où tu peux trouver, partager et contribuer à des tâches et des pipelines créés par la communauté.

Cela te permet d’adopter rapidement les meilleures pratiques sans réinventer la roue. Tu peux installer une tâche existante d’un simple tkn hub install task <nom_de_la_tâche>, et l’intégrer directement dans tes propres Pipelines.

En résumé, la réutilisabilité des Pipelines Tekton te permet de créer une bibliothèque de building blocks standardisés et flexibles, qui peuvent être assemblés et adaptés pour répondre aux besoins spécifiques de chaque projet, sans avoir à tout recoder chaque fois.

GitHub Actions

GitHub Actions est une autre solution populaire qui s’intègre parfaitement aux dépôts sur GitHub, transformant chaque push en un pipeline automatisé.

Gestion des manifests : Kustomize & Helm

Avant d’être déployés, tes manifests Kubernetes doivent souvent être adaptés.

Kustomize te permet de personnaliser des fichiers YAML standard sans utiliser de langage de templating.

Pour des applications plus complexes avec de nombreuses dépendances, Helm est un gestionnaire de paquets qui utilise un système de templates puissant, appelé Charts.

Imagine que tu aies une application et que tu veuilles la déployer sur plusieurs environnements : un pour le développement, un pour le staging (les tests finaux), et un pour la production.

Chacun de ces environnements a besoin de la même base de configuration, mais avec quelques différences (comme le nombre de répliques, le nom du service, les paramètres de la base de données, etc.).

C’est là que la gestion des manifests entre en jeu.

Kustomize : l’approche simple et déclarative

Kustomize est un outil natif de Kubernetes (intégré à kubectl) qui te permet de personnaliser des manifests YAML standards sans toucher aux fichiers d’origine.

Son approche est basée sur la composition.

Tu pars d’une configuration de base, que tu gardes intacte, et tu utilises des “overlays” (des fichiers de patch) pour appliquer les modifications spécifiques à chaque environnement.

Comment ça marche ?

Tu as un dossier base qui contient tous les manifests de ton application.

Puis, pour chaque environnement (par exemple, staging et production), tu crées un dossier avec un fichier kustomization.yaml qui indique les modifications à apporter (par exemple, changer l’image du conteneur, ajouter une étiquette).

Kustomize génère ensuite les manifests finaux pour cet environnement.

L’avantage c’est qu’il n’y a pas de langage de templating à apprendre.

Tu travailles directement avec des fichiers YAML valides.

C’est idéal pour les projets qui ont des variations simples ou des équipes qui préfèrent une approche déclarative et lisible.

Helm : le gestionnaire de paquets puissant

Helm est l’équivalent d’un gestionnaire de paquets comme apt sur Linux/Debian, mais pour Kubernetes.

Il te permet de regrouper un ensemble de manifests, de ressources et de configurations en un seul “paquet” appelé Chart.

Un Helm Chart peut être partagé, versionné et déployé comme une seule unité.

Comment ça marche ?

Un Helm Chart contient des fichiers YAML avec des templates.

Ces templates utilisent un langage de templating (Go templating) qui te permet d’utiliser des variables, des boucles et des conditions pour générer les manifests finaux.

L’avantage de Helm est qu’il est parfait pour les applications complexes ayant de nombreuses dépendances.

Il te permet de réutiliser des paquets d’applications complètes (par exemple, un Chart pour une base de données PostgreSQL ou pour un serveur web) et de les personnaliser simplement en modifiant un fichier de valeurs (values.yaml).

C’est la solution de choix quand tu as besoin d’une standardisation forte et de partager des configurations complexes entre différentes équipes ou projets.

En somme, si Kustomize se concentre sur la composition et la modification de configurations existantes, Helm se positionne comme un gestionnaire de paquets complet pour la gestion de l’intégralité du cycle de vie des applications sur Kubernetes.

Les deux sont souvent utilisés ensemble dans un contexte GitOps pour différentes parties d’un pipeline de déploiement.

Images conteneur : Buildah & Jib

Le GitOps ne fonctionne qu’avec des applications conteneurisées.

Buildah est une alternative à Docker qui te permet de construire des images OCI (Open Container Initiative) sans démon et en tant que simple utilisateur, améliorant ainsi la sécurité.

Pour les développeurs Java, Jib crée des images conteneur directement depuis ton code, sans même avoir besoin d’un Dockerfile.

Sécurité des secrets : Sealed Secrets & HashiCorp Vault

Stocker des mots de passe dans Git est une mauvaise idée/pratique.

Sealed Secrets est une solution qui te permet d’encrypter tes secrets Kubernetes et de les stocker en toute sécurité dans ton dépôt Git.

Alternativement, tu peux utiliser External Secrets pour récupérer tes identifiants depuis un coffre-fort externe comme HashiCorp Vault, sans jamais les stocker dans Git.

La mise en pratique : Démarrer un projet GitOps sur Kubernetes

Le processus de déploiement d’une application via GitOps sur Kubernetes est bien défini. Voici comment ça se passe, illustré par le schéma suivant:

Dépôts Git : Tu maintiens deux dépôts. Un pour le code source de ton application (Source Git Repository) et un autre pour les manifests de configuration Kubernetes (Config Git Repository).

Pipeline CI : Quand tu pousses de nouvelles modifications sur ton dépôt de code source, un webhook déclenche un pipeline de CI (par exemple, un Pipeline Tekton ou Jenkins).

Ce pipeline se charge de compiler ton code, de lancer les tests, de construire une nouvelle image conteneur et de la pousser vers un registre d’images (Image Registry comme Harbor ou autre).

Mise à jour des manifests : Une fois l’image dans le registre, le pipeline met à jour le manifeste dans ton dépôt de configuration pour qu’il pointe vers la nouvelle image. Cette mise à jour peut être faite avec Kustomize ou Helm.

Déploiement CD : Un agent GitOps (par exemple, Argo CD) surveille constamment ton dépôt de configuration. Il détecte le nouveau commit avec l’image mise à jour et applique automatiquement les changements sur ton cluster Kubernetes.

S’il n’y a pas de désynchronisation entre les manifests et l’état du cluster, l’agent ne fait rien, mais il est toujours prêt à agir.

Lire aussi ⬇️

• Qu’est-ce que Kubernetes ?
• Qu’est-ce que Kubernetes ? (L’histoire de Phippy et Capitaine Kube)
• Les bases de GitOps : pourquoi l’adopter pour le CI/CD ?

🎁 Tu es un chef d'entreprise préoccupé à générer plus de croissance pour ton business en cette ère de l'intelligence artificielle ?

J'offre 1h de consultation gratuite à tous les chefs d'entreprises qui lisent mon blog.

💡 Le but est de découvrir vos challenges afin de vous proposer un plan d'action personnalisé pour votre situation particulière.

🟩 Intéressé.e ? Écris-moi: miakassissa@miakassissa.com

Conclusion

GitOps n’est pas juste un mot à la mode, c’est une évolution logique de la culture DevOps et une méthode concrète pour automatiser, sécuriser et fiabiliser tes déploiements sur Kubernetes.

En utilisant Git comme source de vérité, tu donnes à tes équipes un cadre de travail transparent et auditable, qui réduit les risques et accélère le temps de mise sur le marché.

C’est une approche qui te permet de voir tes applications se déployer en toute confiance, en sachant que l’état de ton cluster reflète toujours ce qui est dans ton dépôt.

Ce guide est la première étape de ton voyage.

Chaque outil mentionné ici, d’Argo CD à Tekton en passant par Kustomize et Sealed Secrets, est un élément essentiel de l’écosystème.

Je t’invite à explorer les autres articles de ce cluster pour maîtriser chacun d’eux et construire ta propre stratégie GitOps.

Le futur de l’automatisation est déjà là, et il est temps de s’y adapter.