Affordance trompeuse : GitOps
By Damien B on Saturday 2 January 2021, 10:06 - Cyberpunk - Permalink
Dans la lignée de la revalorisation du travail des opérateurs est née la mouvance GitOps, à savoir les relations particulières entre les opérateurs et les connards (traduction littérale de git). En fait pas vraiment, comme le disent les créateurs de GitOps (Weaveworks) dans leur article de 2017, GitOps consiste en la mise en œuvre d'une approche déclarative pour décrire ce que l'on souhaite dans son système, puis de détecter les changements, et d'agir en conséquence en fonction des changements demandés. Vous aurez bien évidemment reconnu l'approche CFEngine de 1993, en un peu moins puissant, dans le sens où en GitOps les différences sont évaluées cible par cible, et pas de manière systémique ; ici on parle de cible d'outillage de déploiement et pas cible finale.
Est-ce que Git est important là-dedans ? L'article nous dit que oui, dans le sens où Git permet d'avoir gratuitement la revue de code, les commentaires dans les fichiers de configuration, de lier les engagements (commit) aux tickets et de gérer les demandes de récupérations d'engagements (pull request). La réponse est donc non, dans le sens où aucune de ces choses n'est spécifique à Git en particulier, les quatre premiers points étant standards à tous les gestionnaires de versions, et le cinquième étant indépendant du gestionnaire de version mais facile à mettre en œuvre dans les gestionnaires distribués de versions.
Ce qui compte donc dans GitOps n'est donc pas Git, mais l'approche déclarative et versionnée, celle qu'on tente de mettre en œuvre depuis plus de vingt ans, et qui est cassée à chaque fois qu'un produit devient à la mode et qui ne sait être configuré qu'en mode impératif (ou pour parler en termes d'affordances trompeuses, par API
). Il se trouve que les créateurs sont partis du gestionnaire de source du moment, sans chercher à utiliser ses spécificités, on prend celui utilisé par les développeurs. Et pour Ops… les opérateurs sont des anonymes, tout va bien de ce côté, on peut le rajouter dans n'importe terme :-)
Certains rétorqueront que l'article séminal a été mis à jour, et que si, Git est bien indispensable. Mais ce que cette mise à jour fait vraiment est de montrer en quoi le modèle actuel du Continuous Deployment (ou CD, pas le disque optique) basé sur un enchaînement de scripts impératifs n'est pas réconciliable avec l'approche déclarative, qui elle travaille à deux niveaux : l'expression du changement dans l'exigence, et la mesure de l'écart entre l'exigence et ce qui est en place. L'approche CD traditionnelle (dite du pipeline, ou en Français de la Tech, du pipeline) s'arrête au moment où l'on propage le changement demandé, et ne comporte pas la boucle de rétroaction qui vient après la mesure de l'écart (qui n'est d'ailleurs pas systématiquement faite). On reste donc bien sur les principes de CFEngine, et Git dans l'affaire n'est qu'un accessoire à ces principes, même s'il se trouve techniquement au milieu de cette mise en œuvre particulière.
Vous pouvez trouver le reste de la série sous l'article d'introduction.
Comments
Il y a une coquille dans cette phrase : "dans le sens où en GitOps les différences sont évaluées outil de répercussion des différences par outil de répercussion des différences"
Pour traduire le mot anglais "commit" j'utilise largement le mot "archive" en français que je préfère à "engagement".
Si on regarde un dictionnaire anglais, le sens qui me semble le plus approprié est "commit something to paper/writing, to write something down" (https://www.oxfordlearnersdictionar...), que je traduirais volontiers par archiver une information.
Si on regarde des traductions françaises des documentation de CVS et Subversion, le terme "archive" semble également légitime :
- https://us191.ird.fr/?article1 : "en ajoutant les lignes suivantes [...] pour permettre automatiquement un archivage correct des fichiers binaires"
- http://svnbook.red-bean.com/fr/1.8/... : "Subversion est-il l'outil approprié ? [...] En premier lieu, vous devez décider si la gestion de versions en général répond à votre besoin. Si vous voulez archiver de vieilles versions de vos fichiers et dossiers, éventuellement de les ressusciter, ou d'examiner les journaux détaillant leurs évolutions, les systèmes de gestion de versions le font très bien."
Et Merci, chouette série d'articles
Pas de coquille dans la phrase, par contre elle n'est pas très lisible, même moi à la vingtième lecture faut que je m'y reprenne à deux fois... Il faut que je trouve une meilleure tournure.
Pour "archive" ça ne me va pas dans le sens où "archives" désigne quelque chose d'ancien, ça vient de la même racine qu'archaïque, et le but du gestionnaire de version n'est pas juste d'avoir le vieux, c'est aussi d'avoir ce qu'il y a de plus récent en-dehors de copies de travail. Et on retrouve ça de manière encore plus forte dans les systèmes qui imposaient le travail exclusif (lock) sur les fichiers. Je préfère "engagement", même s'il est moins courant, car l'acte du commit est lié au "commit oneself", tu as n versions de travail de ton fichier, et tu prends la responsabilité de dire qu'une de ces versions en particuliers a du sens, mérite d'être mise à part. Et c'est aussi ce qu'on retrouve dans le "message de commit", le pourquoi on est en train de "commiter", alors que si c'est un "simple archivage", le pourquoi est "bah j'ai une version, je l'enregistre". Après, si on regarde la doc de notre ancêtre à tous, RCS, le terme commit n'est pas en usage, on parle de check in (contrôle d'entrée, comme à l'hôtel) et de store (magasin), on est vraiment dans la logique d'entreposage. Je ne sais pas si commit est apparu dans CVS ou dans un autre système, mais l'autre usage de commit courant, et je crois que c'est le même, est dans les systèmes transactionnels, quand tu donnes l'ordre final d'exécution de la transaction qui a été préparée (et dans le cas contraire, tu te désengages par un rollback, un retour arrière). Tout ça pour dire que je préfère un terme qui aille au-delà de l'archivage, même si le terme n'est pas inintéressant dans le contexte.