GitOps est un workflow qui permet d’optimiser, fluidifier et sécuriser les mise en production grâce à un VCS (un système de gestion de version). Dans cet article, nous allons aborder les principaux concepts de GitOps, comprendre pourquoi vous devriez l’envisager dans votre projet et analyser les risques amenés par ce workflow.

C’est quoi GitOps? 

Apparu en Août 2017, le terme GitOps a été inventé par WeaveWorks, dont les développeurs utilisent git comme la seule source de vérité. 

Dans un premier temps, Alexis Richardson, le CEO de WeaveWorks, a rédigé une série d’articles sur le sujet. Il a aussi défini GitOps par Operations By pull request. Et depuis, plusieurs entreprises ont repris cette méthodologie.

GitOps est une approche où on décrit l’état de notre infrastructure dans Git. Le repository git doit contenir l’état souhaité de l’infrastructure, ainsi que toutes les modifications apportées au projet. L’opérateur surveille les modifications dans le repository et applique ces modifications pour s’assurer qu’il n’y ait pas d’écart entre l’état souhaité (le contenu du repository) et l’état actuel (l’état de l’environnement). Les changements sont revus, approuvés et mergés ensuite dans la branche master.

Les changements via l’interface utilisateur ou la ligne de commande sont interdits. Tout changement doit être approuvé à travers des pull request (ou merge request). Suite à cette approbation, la modification sera appliquée automatiquement par l’opérateur.

Comment GitOps fonctionne?

Il existe deux modèles pour implémenter Gitops :

Modèle en push

Le modèle en push fonctionne avec les outils classiques de CI/CD (Jenkins, GitLab Travis, Circle-CI, Spinnaker…)

Les codes applicatifs et ceux de l’infrastructure sont versionnés dans des repositories git distincts.

Le déploiement d’une nouvelle version de l’application se déroule de façon suivante :

• La présence d’un nouveau commit déclenche le pipeline de build.
• Le pipeline de build lance toutes les tests (unitaires, intégrations, etc.).
• Le succès des tests lance le build d’un nouveau conteneur.
• Le pipeline de build se termine avec la modification du repository de l’environnement, en mettant à jour la version de l’application.
• Cette modification va déclencher le pipeline de déploiement pour remplacer l’ancienne image par la nouvelle.

Lorsque l’on apporte une modification du repository de l’infrastructure, seul le pipeline de déploiement sera déclenché pour appliquer les nouvelles modifications. 

Dans cette approche, nous ne pouvons détecter s’il existe un divergence automatiquement entre le git et l’infrastructure. Il faut ajouter du monitoring pour pouvoir détecter cette différence et réagir pour réduire cet écart.

Modèle en pull

Le modèle en pull fonctionne avec les outils classiques de CI (Jenkins, GitLab Travis, Circle-CI…) et des outils modernes de CD (ArgoCD, Flux, JenkinsX…)

Les codes applicatifs et d’infrastructure sont versionnés dans des repositories git distincts.

Le déploiement d’une nouvelle version de l’application se déroule de façon suivante:

• La présence d’un nouveau commit déclenche la pipeline de build.
• Le pipeline de build lance tous les tests (unitaires, integrations, etc.).
• Le succès des tests lance le build d’un nouveau conteneur.
• Le pipeline de build se termine avec la modification de l’environnement, en mettant à jour la version de l’application.
• L’opérateur détecte un écart entre le repo git et l’environnement.
• L’opérateur applique un patch pour éliminer cet écart. Il va chercher cette image du registry et la déployer.

Le pipeline de déploiement peut être déclenché par un écart entre l’état souhaité et l’état actuel:  cela peut provenir d’un nouveau commit dans le repository de l’environnement ou d’une modification accidentelle dans l’environnement.

S’il y a eu des modifications opérées manuellement, l’opérateur va remettre en conformité avec celui décrit dans Git. Ainsi, nous sommes assurés qu’il n’y a pas eu de modification manuelle et que l’infrastructure reste auditable via Git. Ce qui offre un avantage non négligeable par rapport au modèle en push.

Pourquoi utiliser GitOps ? 

Avec un workflow GitOps :

• On dispose de l’historique de modification de chaque environnement. Cet historique est partagé pour tous les membres de l’équipe.
• Avoir un historique complet de notre infrastructure nous permet de voir comment l’infrastructure a évolué. Les messages des commits deviennent une documentation de notre infrastructure.
• Les pratiques de développement de l’extrême programing comme les pull request (merge request, selon votre VCS), la revue de codes et le pair programming ont fait leurs preuves dans le monde de développement. Ces pratiques apportent beaucoup sur la qualité de code et de partage de connaissance sur le projet. Amener ces pratiques dans la gestion des environnements peut être que bénéfique.
• Grâce au pull request, plus besoin d’ouvrir des tickets sur un outils tiers et d’attendre la réponse. S’il y a des points à revoir, ils seront documentés et expliqués dans la pull request. L’approbation de la pull request devient la validation des modifications. Ce qui allège le processus de validation.
• Les changements sont soumis à des pull request. Les reviews de ces pull request permettent une double validation des changements pour réduire l’erreur humaine. Aussi les pull request permettent le partage de connaissance.
• Le rollback dans un workflow GitOps devient un jeu d’enfant, il suffit de faire un git revert sur le dernier commit. 
• Sécurisation des déploiements: tous les changements passent par git. Donc toutes les modifications sont auditables. Dans un modèle en pull, seul l’opérateur à droit de déployer dans le cluster.  Le CI ou nos devops n’ont plus besoin d’accéder au cluster directement. Ce qui réduit la surface d’attaque à notre cluster. 
• Architecture modulaire: Repo/Operator/target . La seule contrainte qu’il y a entre ces trois composants est le repo Git. On peut utiliser la technologie qu’on estime mature dans chaque composant de cette architecture pour répondre à nos besoins.  Le seul choix qu’on doit faire dans un premier temps est le modèle GitOps à utiliser. Même ce choix reste réversible à moindre coup. Exemple d’architecture: Github, Flux, Kubernetes
• La facilité d’identifier rapidement l’écart entre nos différents environnements. Un simple Git diff suffit pour identifier l’écart entre deux branches ou deux commits.
• Les backups sont out of the box grâce à l’historique de git.
• Les tests de changement deviennent simples: monter un environnement sandbox ou modifier un environnement devient à la main de chaque développeur

Beaucoup des avantages évoqués nous rappellent l’Infrastructure as code. En effet, GitOps n’est que la continuité logique de l’IaC.

Cette approche n’est pas exclusive à Kubernetes mais à tout système déclaratif.

Les points de vigilance

• Les commits dans git deviennent une documentation de l’infrastructure. Les messages des commit, évolutions et corrections doivent être autoporteurs (il suffit de lire le message pour comprendre si c’est une correction ou une évolution). On peut utiliser une approche où on préfixe les commit par des tag (feat, fix, docs,style, perf…) pour faciliter la lecture de l’histoire.
• Lorsqu’on utilise les pull request, on peut se retrouver dans une situation où il y a beaucoup de pull request à valider et avoir un goulot d’étranglement dans la lecture des pull request. La priorisation de la lecture des pull request devient primordiale. Le deuxième risque est que le développeur peut avoir plusieurs tâches en parallèle: corriger les retours pull request et une nouvelle tâche. Il doit pouvoir basculer entre deux tâches facilement. 
• Le rollback avec git est une simple commande. Mais souvent ce qui rend la tâche complexe est la compatibilité des versions: il faut être vigilant dans la modification du schéma de base de données et faire en sorte que l’application reste opérationnelle avec les deux schémas. La remarque reste valable pour les APIs.

Comment je gère mes secrets ?

Dans un workflow GitOps (ou n’importe workflow), il est strictement interdit de mettre en clair des secrets dans un repositories git. Il existe plusieurs façon de contourner cette situation. On peut récupérer les mots de passes par environnement à la demande. Chaque environnement aura accès au clés qu’il aura besoin. On peut utiliser des outils comme :

• Bitnami Sealed Secrets
• Godaddy Kubernetes External Secrets (Secret Manager et Vault peuvent être utilisés à travers cet outil).

Pourquoi GitOps et pas SvnOps

Git est devenu le VCS de référence dans la plupart des équipes de développement. Git n’est pas indispensable dans cette approche mais il fluidifie sa mise en place grâce ces fonctionnalités. Libre à vous d’utiliser votre VCS.

Conclusion

L’utilisation de GitOps permet de déclarer toute l’infrastructure en code, et d’avoir une traçabilité de toutes les modifications apportées sur les environnements. Le rollback et le disaster recovery sont disponibles sans effort grâce à git. En plus, il ne demande pas de nouvelles compétences dans l’équipe. GitOps est un bon compromis entre vitesse et contrôle.

Pour terminer, citons Alexis Richarson pour qui « GitOps n’est que 90% de bonnes pratiques et 10% de trucs cools« .

Ressources :

• Weave Works
• 11 reasons for adopting Gitops
• Git Ops