La plupart d'entre nous, en remarquant un nouveau terme dans la blogosphère IT ou lors d'une conférence, se posent tôt ou tard la question suivante : « Qu'est-ce que c'est ? Un mot à la mode, un “buzzword” ou vraiment quelque chose qui mérite une attention particulière, une étude et promet de nouveaux horizons ? » Il en a été de même pour moi avec le terme GitOps il y a quelque temps. Armé de nombreux articles déjà existants, ainsi que des connaissances de mes collègues de l'entreprise , j'ai essayé de comprendre ce qu'est cet animal et à quoi pourrait ressembler son application en pratique.
D'ailleurs, la nouveauté du terme GitOps est également confirmée par une enquête récente que nous avons menée : plus de la moitié des personnes interrogées n'ont pas encore commencé à travailler avec ses principes.
Ainsi, le problème de la gestion des infrastructures n'est pas nouveau. De nombreux fournisseurs de services cloud sont accessibles au grand public depuis déjà une bonne dizaine d'années et, en théorie, devraient avoir simplifié le travail des équipes en charge des infrastructures. Cependant, comparé au processus de développement d'applications (où le niveau d'automatisation atteint de nouveaux sommets), les projets d'infrastructure impliquent encore souvent de nombreuses tâches manuelles et nécessitent des compétences et des spécialistes particuliers, surtout compte tenu des exigences modernes en matière de résilience, de flexibilité, de scalabilité et d'élasticité.
Les services cloud ont très bien répondu à ces exigences et c'est eux qui ont donné un coup d'accélérateur au développement de cette approche. IaCC'est compréhensible. En effet, c'est grâce à eux qu'il est possible de configurer un centre de données entièrement virtuel : pas de serveurs physiques, de racks, de composants réseau, toute l'infrastructure peut être décrite à l'aide de scripts et de fichiers de configuration.
Alors quelle est la véritable différence GitOps à partir de IaC? Именно с этого вопроса я и начал свое расследование. Пообщавшись с коллегами, у меня получилось выработать следующее сравнение:
GitOps
IaC
Tout le code est conservé dans un dépôt git
La versionnage du code n'est pas obligatoire
Description déclarative du code / Idempotence
Il est acceptable d'utiliser à la fois une description déclarative et impérative
Les changements prennent effet en utilisant les mécanismes de Merge Request / Pull Request
L'approbation, la validation et la collaboration ne sont pas obligatoires
Le processus de déploiement des mises à jour est automatisé
Le processus de déploiement des mises à jour n'est pas régulé (automatique, manuel, copie de fichiers, utilisation de la ligne de commande, etc.)
En d'autres termes GitOps est né précisément grâce à l'application de ces principes IaC. Tout d'abord, l'infrastructure et les configurations pouvaient désormais être stockées exactement comme les applications. Le code est facile à conserver, à partager, à comparer et à utiliser grâce aux fonctionnalités de gestion de version. Versions, branches, historique. Et tout cela dans un endroit accessible à toute l'équipe. Il était donc tout à fait logique d'en venir à utiliser des systèmes de contrôle de version. En particulier, git, en tant que le plus populaire.
D'autre part, il est désormais possible d'automatiser les processus de gestion de l'infrastructure. Cela peut maintenant se faire plus rapidement, plus fiablement et à moindres coûts. D'autant plus que les principes CI/CD étaient déjà connus et populaires parmi les développeurs de logiciels. Il ne restait plus qu'à transférer et appliquer les connaissances et compétences déjà acquises dans ce nouveau domaine. Toutefois, ces pratiques dépassaient le cadre standard de l'Infrastructure en tant que code, d'où est né le concept GitOps.
La curiosité GitOps, bien sûr, réside aussi dans le fait qu'il ne s'agit pas d'un produit, d'un plugin ou d'une plateforme liée à un quelconque fournisseur. C'est plutôt un paradigme et un ensemble de principes, semblable à un autre terme qui nous est familier : DevOps.
Dans l'entreprise , nous avons élaboré deux définitions de ce nouveau terme : théorique et pratique. Commençons par la théorique :
GitOps est une méthodologie qui utilise des principes avancés de DevOps, utilisés pour le développement d'applications, tels que le contrôle de version, la collaboration, la mise en correspondance, CI/CD, et les applique pour automatiser la gestion de l'infrastructure.
Tous les processus GitOps fonctionnent en utilisant des outils déjà existants. Tout le code d'infrastructure est stocké dans un dépôt git familier, les modifications passent par le même processus d'approbation que tout autre code logiciel, et le processus de déploiement est automatisé, minimisant ainsi les erreurs humaines, tout en améliorant la fiabilité et la reproductibilité.
D'un point de vue pratique, nous décrivons GitOps comme suit :
L'infrastructure en tant que code a déjà été abordée, comme l'un des éléments clés de cette formule. Présentons les autres participants.
Les demandes de fusion (appelées aussi Pull Request) sont des requêtes pour l'application de modifications de code et la fusion de branches. C'est aussi une manière d'obtenir une vue d'ensemble des modifications apportées : non seulement le diff de code provenant de plusieurs commits, mais aussi le contexte, les résultats des tests et le résultat final attendu. Si nous parlons de code d'infrastructure, il est important de comprendre comment l'infrastructure va changer, combien de nouvelles ressources seront ajoutées ou supprimées, ou changées. Idéalement, cela devrait être sous un format plus pratique et lisible. Pour les fournisseurs de cloud, il serait également utile de savoir quelles sont les implications financières de ce changement.
Mais la demande de fusion est aussi un outil de collaboration, d'interaction et de communication. C'est l'endroit où le système de checks and balances entre en jeu. Des simples commentaires aux approbations formelles et aux validations.
Et enfin, le dernier élément : CI/CD, comme nous le savons, permet d'automatiser le processus de mise à jour de l'infrastructure, de test (de la simple vérification de syntaxe à une analyse de code statique plus complexe). Cela permet également de détecter par la suite des dérives : les différences entre l'état réel et l'état souhaité du système. Par exemple, à la suite de changements manuels non autorisés ou de défaillances système.
Oui, le terme GitOps ne nous présente rien de complètement nouveau, il ne réinvente pas la roue, mais applique simplement l'expérience accumulée dans un nouveau domaine. Mais c'est là que réside sa force.
Et si cela vous intéresse de voir comment tout cela fonctionne en pratique, je vous invite à découvrir notre , où j'explique étape par étape comment utiliser GitLab pour :
Mettre en œuvre les principes fondamentaux de GitOps
Créer et apporter des modifications à l'infrastructure cloud (avec Yandex Cloud en exemple)
Automatiser la détection des dérives du système par rapport à l'état souhaité grâce à une surveillance active
https://bit.ly/34tRpwZ
Source : habr.com
