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) construit sur le logiciel BitKeeper de Linus Torvalds. Contrairement aux VCS centralisés comme Subversion ou Mercurial, Git fonctionne 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.
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.
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.
