Git comme source unique de vérité pour la configuration

Le GitOps désigne la pratique consistant à utiliser Git comme source unique de vérité (Single Source of Truth, SSOT) pour la configuration de l'infrastructure. Dans ce guide, nous explorons comment stocker et gérer la configuration de vos serveurs dans Git de manière simple, afin de suivre les changements, simplifier les déploiements et garantir la cohérence de votre infrastructure. Vous découvrirez également les outils et les bonnes pratiques qui rendent le GitOps possible, en offrant une traçabilité claire et des déploiements plus rapides et plus faciles à gérer.

Introduction au GitOps

Le GitOps est une méthodologie et un ensemble d'outils qui aident les organisations à faire de Git leur source unique de vérité pour l'infrastructure de production. L'objectif est de fournir un contrôle d'accès sécurisé et fiable, des déploiements automatisés, de l'observabilité, du suivi de conformité et des capacités d'audit, le tout à travers de simples politiques déclaratives stockées dans des dépôts Git.

Le GitOps privilégie les personnes par rapport aux machines (contrairement au DevOps traditionnel), les outils open source par rapport aux solutions propriétaires (contrairement au Cloud Native classique), et la confiance par rapport au contrôle (contrairement aux approches sécuritaires rigides). Le résultat est un environnement où chacun peut voir ce qui se passe, favorisant une meilleure collaboration entre les équipes.

Cette approche est au cœur de ce que nous proposons chez Hidora dans nos prestations de consulting DevOps. Mettre en place un workflow GitOps solide est l'un des premiers leviers d'amélioration que nous recommandons à nos clients.

L'infrastructure en tant que code (IaC)

La construction et le provisionnement d'infrastructure sont des domaines où l'Infrastructure as Code (IaC) prend tout son sens. Les raisons sont doubles : taper manuellement toute la configuration est fastidieux, et cela augmente les risques d'introduire des erreurs involontaires.

Git est un système de contrôle de version (VCS) créé par Linus Torvalds en remplacement de BitKeeper. Contrairement aux VCS centralisés comme Subversion, Git (comme Mercurial) fonctionne de manière distribuée en suivant chaque modification effectuée dans son dépôt depuis sa création. Cela le rend particulièrement efficace pour gérer de grands projets avec de nombreux contributeurs sur de longues périodes, exactement ce dont nous avons besoin dans notre boîte à outils IaC.

Avec des outils comme chef-solo, Ansible et SaltStack, vous pouvez spécifier de manière déclarative l'apparence d'un environnement via une collection de fichiers suivis par votre dépôt. L'exécution réelle ne se fait que lorsque vous souhaitez mettre à jour votre environnement cible avec les changements de votre dépôt. Cette méthode vous encourage à être explicite sur la configuration souhaitée. Il n'y a plus d'ambiguïté quand les choses tournent mal ou quand un autre membre de l'équipe a des attentes légèrement différentes.

Tester l'Infrastructure as Code

L'Infrastructure as Code est formidable, mais elle ne fonctionne que si votre équipe de développement l'utilise réellement. Il faut mettre en place des mécanismes de surveillance, que ce soit à travers des pull requests ou des revues de code.

Quand les changements sont effectués manuellement, il est difficile de savoir ce qui a changé et quand. Cela rend extrêmement compliqué la détermination de quelle version cause un dysfonctionnement, ce qui complexifie inutilement le dépannage et les correctifs.

La solution est simple : utilisez un logiciel d'intégration continue open source (comme GitLab) et créez des tests pour chaque modification IaC. Par exemple, si vous utilisez Jelastic CloudScripting pour déployer de nouvelles stacks, testez vos changements avant de les commiter en mettant à jour une stack pré-existante (pré-production) plutôt qu'en créant une nouvelle. Cela vous permet de valider vos modifications dans un environnement contrôlé avant de les appliquer en production.

Les pièges courants de l'IaC et comment les éviter

L'adoption de l'Infrastructure as Code n'est pas exempte de difficultés. Voici les erreurs les plus fréquentes que nous observons chez nos clients, et les moyens de les prévenir.

Le configuration drift. C'est le piège le plus insidieux : quelqu'un se connecte en SSH à un serveur de production pour appliquer un "quick fix" urgent, sans le reporter dans le dépôt Git. L'état réel de l'infrastructure diverge alors de ce qui est décrit dans le code. Au fil du temps, ces écarts s'accumulent et personne ne sait plus quel est l'état réel du système. La solution : interdire strictement les modifications manuelles en production et mettre en place des outils de détection du drift comme driftctl ou les fonctions de reconciliation d'ArgoCD.

Les secrets en clair dans le dépôt. Stocker des mots de passe, des clés API ou des certificats directement dans les fichiers de configuration est un risque majeur. Même si le dépôt est privé, l'historique Git conserve tout. Un secret commité par erreur reste accessible dans l'historique, même après suppression. Utilisez des outils dédiés comme HashiCorp Vault, SOPS (Secrets OPerationS) ou les sealed secrets de Bitnami pour chiffrer les secrets avant de les commiter.

Le manque de modularité. Copier-coller des blocs de configuration entre environnements (dev, staging, production) crée une dette technique considérable. Quand un paramètre change, il faut le modifier à plusieurs endroits, avec le risque d'en oublier un. Préférez les modules Terraform, les rôles Ansible ou les Helm charts paramétrés pour factoriser la configuration et ne varier que les paramètres spécifiques à chaque environnement.

L'absence de state management. Pour les outils comme Terraform, le fichier state contient l'état courant de votre infrastructure. Stocker ce fichier localement ou le commiter dans Git est une source de conflits et de corruptions. Utilisez un backend distant (S3, GCS, ou un stockage compatible) avec un mécanisme de verrouillage pour éviter les modifications concurrentes.

Quel est le rapport avec Git ?

Git, et plus spécifiquement les outils de gestion de dépôts Git, est généralement utilisé pour suivre les modifications de code. Les puissantes capacités de branching de Git et son architecture distribuée facilitent la gestion de plusieurs branches de code.

Si vous appliquez ces mêmes concepts et méthodes à des ressources non-code, comme les fichiers de configuration d'infrastructure et les scripts d'exécution de tâches à distance, vous pouvez créer une source unique de vérité qui permet l'automatisation.

Imaginez des milliers de serveurs automatiquement mis à jour avec de nouvelles configurations à 1h du matin chaque dimanche, ou à chaque fois qu'un commit est poussé vers master sur votre projet GitHub. Les avantages sont nombreux : des temps de déploiement plus rapides et moins d'erreurs humaines, pour n'en citer que deux.

C'est exactement ce type d'automatisation que nous mettons en place pour nos clients chez Hidora, dans le cadre de nos services managés. Chaque environnement est versionné, chaque changement est traçable.

La gestion des branches

Le branching est un atout majeur. Il vous permet de travailler simultanément sur plusieurs fonctionnalités et modifications, puis de les fusionner quand vous êtes prêt.

Prenons un exemple concret. Vous travaillez sur l'amélioration des performances de votre site. Vous souhaitez modifier certains styles CSS en plus de faire des changements sur la configuration de votre serveur. Vous pouvez effectuer ces modifications CSS sur leur propre branche (par exemple, /css-perf) et la pousser vers GitHub ou GitLab avec git push origin /css-perf. Vous pouvez ensuite faire vos changements serveur sans craindre de casser les modifications CSS.

Les branches sont fantastiques. Cependant, il y a un point important à garder en tête : les branches peuvent rendre le suivi de l'historique très difficile. C'est pourquoi une bonne stratégie de branching (comme GitFlow ou trunk-based development) est essentielle pour maintenir la clarté de votre historique de configuration.

Exemple pratique : un workflow GitOps avec ArgoCD

Pour illustrer concrètement comment le GitOps fonctionne au quotidien, prenons l'exemple d'un déploiement Kubernetes géré par ArgoCD.

Le principe est simple : ArgoCD surveille en permanence un dépôt Git contenant les manifestes Kubernetes de votre application. Dès qu'un changement est détecté (nouveau tag d'image, modification d'une variable d'environnement, ajustement des ressources), ArgoCD applique automatiquement la modification au cluster.

Le workflow typique se déroule ainsi : un développeur modifie la version de l'image dans le fichier values.yaml d'un Helm chart, soumet une pull request, un collègue valide le changement après revue, et dès le merge, ArgoCD détecte la modification et met à jour le déploiement en production. En cas de problème, un simple git revert suivi d'un merge ramène l'infrastructure à son état précédent en quelques minutes. Ce mécanisme de rollback instantané est l'un des avantages les plus puissants du GitOps par rapport aux déploiements manuels traditionnels.

Bonnes pratiques pour adopter le GitOps

Pour tirer le meilleur parti du GitOps, voici quelques recommandations issues de notre expérience :

• Tout versionner. Pas seulement le code applicatif, mais aussi les configurations serveur, les scripts de déploiement, les politiques de sécurité et les définitions d'infrastructure.
• Automatiser les déploiements. Utilisez des pipelines CI/CD qui se déclenchent automatiquement à chaque changement validé dans la branche principale.
• Protéger la branche principale. Exigez des revues de code et des tests automatisés avant toute fusion vers master ou main.
• Documenter les changements. Chaque commit doit expliquer pourquoi un changement a été fait, pas seulement ce qui a changé.
• Auditer régulièrement. Vérifiez périodiquement que l'état réel de votre infrastructure correspond à ce qui est décrit dans Git.

Le GitOps n'est pas une destination, c'est un parcours. Chaque organisation peut l'adopter progressivement, en commençant par les éléments les plus critiques de son infrastructure. L'essentiel est de démarrer et d'itérer.