La plupart d'entre nous, remarquant un autre nouveau terme dans la blogosphère ou lors d'une conférence informatique, posent tôt ou tard une question similaire : « Qu'est-ce que c'est ? Juste un autre mot à la mode, un « mot à la mode » ou quelque chose qui mérite vraiment d’être étudié de près et de promettre de nouveaux horizons ? Il m'est arrivé la même chose avec le terme GitOps il y a quelque temps. Armé de nombreux articles existants, ainsi que des connaissances de collègues de l'entreprise , j'ai essayé de comprendre de quel genre de bête il s'agit et à quoi pourrait ressembler son utilisation dans la pratique.
Au fait, à propos de la nouveauté du terme GitOps Notre récente enquête le dit également : plus de la moitié des personnes interrogées n’ont pas encore commencé à travailler avec ses principes.
Le problème de la gestion des infrastructures n’est donc pas nouveau. De nombreux fournisseurs de cloud sont accessibles au grand public depuis une bonne douzaine d'années et auraient dû, semble-t-il, simplifier et simplifier le travail des équipes en charge de l'infrastructure. Cependant, comparés au processus de développement d'applications (où l'automatisation atteint des niveaux toujours plus élevés), les projets d'infrastructure impliquent encore souvent de nombreuses tâches manuelles et nécessitent des connaissances et une expertise spécialisées, en particulier compte tenu des exigences actuelles en matière de tolérance aux pannes, de flexibilité, d'évolutivité et d'élasticité.
Les services cloud ont répondu à ces exigences avec beaucoup de succès et ce sont eux qui ont donné une impulsion significative au développement de l'approche. IaC. C'est compréhensible. Après tout, ils ont permis de configurer un centre de données entièrement virtuel : il n'y a pas de serveurs physiques, de racks ou de composants réseau ; l'ensemble de l'infrastructure peut être décrit à l'aide de scripts et de fichiers de configuration.
Alors, quelle est exactement la différence ? GitOps à partir de IaC? C'est par cette question que j'ai commencé mon enquête. Après avoir discuté avec des collègues, j'ai pu arriver à la comparaison suivante :
GitOps
IaC
Tout le code est stocké dans un référentiel git
La gestion des versions du code est facultative
Code déclaratif Description / Idempotence
Les descriptions déclaratives et impératives sont acceptables
Les modifications prennent effet à l’aide des mécanismes Merge Request / Pull Request
L'accord, l'approbation et la collaboration sont facultatifs
Le processus de déploiement des mises à jour est automatisé
Le processus de déploiement des mises à jour n'est pas standardisé (automatique, manuel, copie de fichiers, utilisation de la ligne de commande, etc.)
En d'autres termes GitOps est né précisément de l'application des principes IaC. Premièrement, l'infrastructure et les configurations pourraient désormais être stockées de la même manière que les applications. Le code est facile à stocker, à partager, à comparer et à utiliser les capacités de gestion des versions. Versions, branches, historique. Et tout cela dans un lieu accessible au public à toute l’équipe. Par conséquent, l’utilisation de systèmes de contrôle de version est devenue une évolution tout à fait naturelle. En particulier, git, comme le plus populaire.
D’autre part, il est devenu possible d’automatiser les processus de gestion des infrastructures. Cela peut désormais être fait plus rapidement, de manière plus fiable et à moindre coût. De plus, les principes du CI/CD étaient déjà connus et appréciés des développeurs de logiciels. Il suffisait de transférer et d'appliquer des connaissances et des compétences déjà connues à un nouveau domaine. Ces pratiques allaient cependant au-delà de la définition standard de l'infrastructure en tant que code, d'où le concept GitOps.
Curiosité GitOps, bien sûr, également dans le fait qu’il ne s’agit pas d’un produit, d’un plugin ou d’une plate-forme associée à un fournisseur. Il s’agit plutôt d’un paradigme et d’un ensemble de principes, semblable à un autre terme que nous connaissons bien : DevOps.
La société nous avons développé deux définitions de ce nouveau terme : théorique et pratique. Commençons par le théorique :
GitOps est une méthodologie qui reprend les meilleurs principes DevOps utilisés pour le développement d'applications, tels que le contrôle de version, la collaboration, l'orchestration, le CI/CD, et les applique aux défis de l'automatisation de la gestion de l'infrastructure.
Tous les processus GitOps Je travaille avec les outils existants. Tout le code d'infrastructure est stocké dans le référentiel 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é, ce qui minimise les erreurs humaines et augmente la fiabilité et la reproductibilité.
D'un point de vue pratique, nous décrivons GitOps comme suit:
Nous avons déjà discuté de l'infrastructure en tant que code comme l'un des éléments clés de cette formule. Présentons le reste des participants.
Demande de fusion (nom alternatif Pull Request). En termes de processus, MR est une demande d'application de modifications de code, puis de fusion de branches. Mais en termes d'outils que nous utilisons, c'est plutôt l'occasion d'avoir une vision complète de toutes les modifications apportées : non seulement les différences de code collectées à partir d'un certain nombre de commits, mais aussi le contexte, les résultats des tests et les résultat final attendu. Si nous parlons de code d'infrastructure, nous nous intéressons alors à la manière exacte dont l'infrastructure va changer, au nombre de nouvelles ressources qui seront ajoutées ou supprimées, modifiées. De préférence dans un format plus pratique et facile à lire. Pour les fournisseurs de cloud, c'est une bonne idée de connaître quel sera l'impact financier de ce changement.
Mais la RM est aussi un moyen de collaboration, d’interaction et de communication. Le lieu où le système de freins et contrepoids entre en jeu. Des simples commentaires aux approbations et approbations formelles.
Eh bien, le dernier composant : CI/CD, comme nous le savons déjà, permet d'automatiser le processus de modification et de test de l'infrastructure (de la simple vérification de la syntaxe à l'analyse de code statique plus complexe). Et aussi dans la détection ultérieure des dérives : différences entre l'état réel et souhaité du système. Par exemple, à la suite de modifications manuelles non autorisées ou d'une panne du système.
Oui, le terme GitOps ne nous présente rien de complètement nouveau, ne réinvente pas la roue, mais applique simplement l'expérience déjà accumulée dans un nouveau domaine. Mais c’est là que réside sa force.
Et si tout à coup vous êtes intéressé par la façon dont tout cela se présente dans la pratique, alors je vous invite à consulter notre , dans lequel je vous explique étape par étape comment utiliser GitLab :
-
Mettre en œuvre les principes de base de GitOps
-
Créer et apporter des modifications à l'infrastructure cloud (en utilisant l'exemple de Yandex Cloud)
-
Automatisez la détection de la dérive du système par rapport à un état souhaité grâce à la surveillance active
https://bit.ly/34tRpwZ
Source: habr.com