Une comparaison de l'idempotence et de l'immuabilité

Beaucoup dans les DevOps appliquent la mentalité du bétail et non des animaux de compagnie en mettant en œuvre une infrastructure immuable et en se redéployant lorsque des changements sont nécessaires (au lieu de les modifier).

La gestion de la configuration a un principe similaire d' idempotence . Quels sont les avantages comparatifs, les similitudes et les inconvénients de l'immuabilité par rapport à l'impuissance et lequel est plus efficace? Peut-on les utiliser de manière synergique (par exemple, suppression et redéploiement périodiques de machines virtuelles ou de conteneurs Docker à l'aide de la gestion de la configuration?)

Les deux termes sont très différents.

Commençons par immutability, ce qui signifie littéralement «pas de mutations» ou «pas de changements». Dans le sens DevOps, cela signifie qu'une fois que vous avez créé un artefact, qu'il s'agisse d'une image de conteneur, ou d'une image de machine virtuelle, ou peut-être d'un package à partir du code compilé - vous déclarez que vous ne le modifierez jamais. Souvent, si des modifications sont nécessaires, vous déclarez qu'une nouvelle version de "chose" sera créée à la place.

Le terme idempotencesignifie que lorsque les modifications sont appliquées plusieurs fois, l'état est muté (modifié) une seule fois . Premièrement, il suppose déjà que des changements vont être appliqués, ce qui signifie que vous ne pouvez pas avoir quelque chose à la fois immuable et que des actions idempotentes lui sont faites (aucune action ne lui est faite par contrat).

Dans l'utilisation des outils de gestion de configuration, idempotenceest utilisé dans certains cas lors de l'application du même changement plusieurs fois. Comme pour ajouter la ligne qui dit localhostau /etc/hostsfichier, vous n'avez pas vraiment besoin de plusieurs lignes de ce type et si une existe déjà, il est sûr de ne pas essayer d'ajouter à nouveau.

Est également idempotentun terme utilisé pour décrire les actions qui tentent de changer les choses, tandis que immutableest utilisé pour décrire les noms (objets) qui sont définis par rapport aux modifications qui leur sont apportées.

Pourquoi un immutableobjet est-il utile? Parce que lorsque vous le copiez, par exemple d'un environnement de développement vers qa vers la production. Vous en savez déjà beaucoup (mais pas tout) sur la manière dont il va se comporter. Dans de nombreux cas, les pièces qui fonctionnent seront cohérentes et les pièces cassées seront également cohérentes.

Pourquoi les idempotentactions sont-elles utiles? Parce que lorsque vous souhaitez modifier l'état d'un objet, dans de nombreux cas, il est utile de vérifier uniquement que la modification a été appliquée et d'appliquer les modifications au cas où cela serait nécessaire. Par exemple, lorsqu'un élément de configuration dans un fichier est manquant ou a la mauvaise valeur, il est utile de l'ajouter une seule fois ou de le modifier une seule fois tout en appliquant l'action plusieurs fois. Dans de nombreux autres cas, comme les fichiers journaux , vous ne voulez pas avoir d'actions idempotentes car vous voulez souvent ajouter une autre ligne chaque fois qu'un événement se produit.

L'infrastructure immuable est, à mon avis, un modèle différent de la gestion de la configuration. Bien qu'ils puissent être utilisés ensemble, ils abordent les problèmes par nature de deux manières différentes.

Le concept des objets immuables a une longue histoire, les systèmes Unix les utilisent depuis des décennies pour déployer des progiciels. Mais une fois qu'ils ont été déployés, les fichiers de configuration ont été modifiés afin que les choses deviennent mutables. Idempotency fournit de belles garanties avec les fichiers mutables, nous pouvons savoir quand les choses ont changé et ne mettre à jour que les choses qui ont besoin d'être mises à jour. Cependant, cela ne résout pas tous les problèmes des objets mutables, nous devons encore répondre à un nombre apparemment infini de cas de bord. Parce que les choses sont mutables et que nous sommes idempotents, nous devons d'abord déterminer quels changements doivent être apportés, puis les exécuter généralement dans un ordre très spécifique. Lors du déploiement de packages logiciels, en particulier avec des déploiements sans interruption de service, nous devons soigneusement orchestrer les modifications pour empêcher toute demande d'être abandonnée.

Cette complexité peut finalement être évitée en déployant des artefacts immuables au lieu de les muter en place, car nous remplaçons simplement un objet par un autre (que ce soit un binaire, ou un conteneur ou une machine virtuelle), le mettons en service et retirons l'ancien. . Ceci n'est qu'un exemple de déploiement sans temps d'arrêt.

Avec les progrès de l'outillage pour nous permettre de déployer des artefacts immuables sur des milliers de systèmes en très peu de temps, nous constatons que l'utilisation d'outils immuables pour gérer les systèmes est beaucoup plus réalisable que la gestion de configuration. Cependant, l'outillage n'est pas encore là et il existe encore un cas d'utilisation pour les deux. J'ai fait un exposé sur ce sujet qui explique la progression linéaire de entièrement mutable à entièrement immuable, c'est un spectre et chaque entreprise choisira où elle lui convient le mieux.