1) Présentation de GitOps
GitOps est une méthodologie et des outils pour aider 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, un déploiement automatisé, une observabilité, un suivi de la conformité et des capacités d’audit, le tout par le biais de politiques déclaratives simples dans les dépôts Git. GitOps privilégie les personnes par rapport aux machines (par rapport à DevOps), les outils open source par rapport aux outils propriétaires (par rapport à Cloud Native), et la confiance par rapport au contrôle (par rapport à la sécurité). Le résultat final est un environnement dans lequel chacun peut voir tout ce qui se passe, ce qui permet une meilleure collaboration entre les équipes.
2) L’infrastructure en tant que code (IaC)
La construction et l’approvisionnement de l’infrastructure sont des domaines dans lesquels vous pouvez utiliser l’IaC. Les raisons sont doubles : il est fastidieux de taper tout ce code, mais cela signifie également que vous avez moins de possibilités d’introduire des erreurs par inadvertance. Git est un système de contrôle de version (VCS) construit sur le logiciel BitKeeper de Linus Torvalds. Contrairement aux systèmes VCS centralisés comme Subversion ou Mercurial, Git fonctionne en suivant chaque changement effectué 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 de temps – exactement ce dont nous avons besoin dans notre boîte à outils IaC. Avec des outils comme chef-solo , Ansible , et SaltStack , nous pouvons spécifier de manière déclarative l’apparence d’un environnement via une collection de fichiers suivis par notre référentiel – nous n’exécutons pas réellement ces étapes jusqu’à ce que nous voulions mettre à jour notre environnement cible avec les changements de notre référentiel ! Cette méthode nous encourage à être explicite sur la façon dont nous voulons que quelque chose soit configuré ; il n’y a pas de malentendu lorsque les choses tournent mal ou lorsqu’un autre membre de l’équipe a des attentes légèrement différentes des nôtres.
3) Test de l’IaC
L’infrastructure en tant que code est formidable, mais elle ne fonctionne que si votre équipe de développement l’utilise. Vous devez les surveiller, que ce soit par le biais de demandes de retrait ou de revues de code. Lorsque les modifications sont effectuées manuellement, il est difficile de savoir ce qui a changé et quand. Il peut donc s’avérer extrêmement difficile de déterminer quelle version est à l’origine d’une panne ou d’un autre problème, ce qui rend le dépannage et l’application de correctifs plus compliqués que nécessaire. La solution est simple : utilisez un logiciel d’intégration continue open-source (comme GitLab) et créez des tests pour chaque modification que vous apportez dans IaC – par exemple, si vous utilisez Jelastic CloudScripting pour déployer de nouvelles piles, testez vos modifications avant de les valider en mettant à jour une pile préexistante (pre-prod) au lieu d’en créer une nouvelle.
4) Quel est le rapport avec Git ?
Git, plus précisément les outils de gestion des dépôts git, est généralement utilisé pour suivre les modifications du code. Les puissantes capacités de branchement de Git et son architecture distribuée facilitent la gestion de multiples branches de code. Si nous appliquons ces mêmes concepts et méthodes aux ressources autres que le code, comme les fichiers de configuration de l’infrastructure et les scripts d’exécution des tâches à distance, nous pouvons créer une source unique de vérité qui permettra l’automatisation. Imaginez que des milliers de serveurs soient automatiquement mis à jour avec de nouvelles configurations à 1 heure 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 !
5) Gestion de la branche
Le branchement est une bonne chose, il nous permet de travailler sur plusieurs fonctionnalités et modifications à la fois, et de les fusionner plus tard lorsque nous sommes prêts. Par exemple, disons que vous travaillez à l’amélioration des performances de votre site. Il se peut que vous souhaitiez modifier certains styles CSS en plus d’apporter des changements à la configuration de vos serveurs. 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 alors effectuer vos modifications sur le serveur sans craindre de casser les modifications CSS ! Les branches sont géniales ! Cela dit, il y a une chose dont vous devez être conscient : Les branches rendent le suivi de l’historique très difficile.
