Dans le monde du DevOps, on voit régulièrement émerger de nouveaux termes et outils. Souvent annoncés comme des révolutions, ils sont pourtant très vite oubliés pour être aussi vite remplacés par de nouveaux phénomènes. Néanmoins, certains d’entre eux perdurent, à l’instar du GitOps.
Avant toute chose rappelons l’objectif du DevOps : unifier les équipes de développement et les équipes Opérations au travers de l’automatisation, de la gestion et du monitoring, dans le but d’accélérer et d’optimiser la chaîne de production et de livrer son application plus rapidement. Le DevOps regroupe ainsi un ensemble d’outils, de bonnes pratiques et de méthodes.
Pour comprendre comment nous sommes arrivés au GitOps, il faut comprendre un concept qui fait foi depuis quelques années et qui représente la dernière grande révolution dans le monde DevOps : l’infrastructure-as-code. Cette pratique simplifie la gestion des infrastructure IT et facilite la consommation par les équipes. Pour schématiser au maximum ce concept :
> Les équipes Ops rédigent, au sein de fichiers normés, des modèles d’infrastructure (serveur Linux, Windows…) ;
> Les équipes Dev font appel aux fichiers rédigés par les équipes Ops, en y joignant un fichier de configuration pour personnaliser l’infrastructure dont ils ont besoin ;
> La symbiose des deux fichiers permet de provisionner l’infrastructure demandée et donne naissance à un nouveau fichier, unique, servant de fiche d’identité pour l’environnement créé.
En résumé, trois fichiers contiennent l’ensemble des informations nécessaires pour créer un environnement unique. Le GitOps permet de stocker ces fichiers dans un dépôt et d’en surveiller les évolutions.
Cette approche, que l’on pourrait formuler « Infrastructure as Code + CI/CD + Merge Request » permet une meilleure productivité en accélérant le développement et le déploiement, tout en améliorant la stabilité et la fiabilité de l’infrastructure cloud.
Mais alors, comment tirer pleinement parti du GitOps ? Quels en sont les bénéfices ? Et enfin, qu’est-ce qui différencie cette approche du DevOps ?
GitOps, le livre de recettes du cloud
Les actions nécessaires au déploiement et à la configuration de l’infrastructure et des applications du cloud sont stockées dans des fichiers. On pourrait imaginer un livre de recettes, que les outils vont lire et exécuter afin d’obtenir un cloud dans un état attendu.
Pour modifier l’état attendu (par exemple changer la version d’un outil, ajouter un utilisateur ou sécuriser des applications), les développeurs et administrateurs vont modifier ces fichiers. Dès que ces modifications sont « poussées », c’est-à-dire que l’on décide de les intégrer dans « l’état attendu du cloud », des outils vont détecter ces changements et exécuter les actions nécessaires pour rendre la plateforme cloud conforme à ces attentes.
L’important n’est pas l’outil, mais le but recherché
Le paradigme GitOps répond à plusieurs objectifs :
> Limiter les périodes d’indisponibilité : qu’il y ait une panne, une mise-à-jour à effectuer, une maintenance, ou le déploiement d’une nouvelle solution, une plateforme indisponible empêche les équipes de travailler, voire les clients d’accéder à des services. En automatisant le déploiement, la configuration et les tests d’une plateforme cloud, en laissant les outils orchestrer les opérations, on assure une rapidité d’exécution et de livraison avec une qualité largement supérieure. En résumé, une plateforme stable et fonctionnelle avec des interruptions bien plus courtes.
> Limiter les erreurs : la rédaction des actions et la configuration des outils permet d’avoir une seule source de vérité, de pouvoir suivre les modifications et donc de mettre en place des procédures de tests, de qualité et d’approbation en amont. Il n’est plus nécessaire d’attendre d’avoir déployé une erreur pour se rendre compte de la maldonne.
> Un état sûr et une grande agilité : l’état d’une infrastructure étant stocké dans un système de gestion de versions, il n’existe qu’un endroit à consulter pour connaître l’état général de l’environnement. En cas de souci, on peut ainsi revenir à une ancienne version de manière rapide et précise. Au même titre, un correctif à une faille de sécurité critique peut être appliqué, testé et validé en quelques instants.
Le plus important est de pouvoir déployer et répliquer une infrastructure, un environnement, simplement et de manière iso.
Le GitOps est bien différent du DevOps
Les approches GitOps et DevOps reposent sur des principes, des outils et des objectifs communs. Alors que le DevOps incite à un changement culturel dans la manière de collaborer entre les équipes d’exploitation et les développeurs, le GitOps offre plutôt un ensemble d’outils et de bonnes pratiques permettant d’optimiser la collaboration entre les deux équipes, en permettant à chacun de travailler avec leurs propres codes et référentiels, mais avec l’objectif commun d’œuvrer ensemble.
En résumé, les gains sont conséquents dans la mise en place de pratiques GitOps avec notamment le suivi des modifications (qui, quoi, quand ?) et le retour en arrière simple et rapide ; la facilité de gestion dans le cadre de projets complexes et d’équipes larges ; et le dépôt qui contient l’ensemble du code, des configurations, l’inventaire et l’état des environnement. Une source unique de vérité. En revanche, il faudra également veiller à trouver le bon équilibre entre les processus efficaces et les complexités de suivi et de mise en application par les équipes.
