• # Idempotence

    Posté par . En réponse au journal Déploiement et automatisation avec Ansible - partie 1. Évalué à 6.

    Toujours concernant Ansible (bien entendu), on parle souvent d'idempotence, ce qui signifie qu'une opération a le même effet qu'on l'applique une ou plusieurs fois.

    Tu va très vite là dessus alors que c'est un point crucial de ces outils (c'est pas spécifique à ansible).

    L'idempotence est très utile pour appliquer un principe simple mais puissant, utiliser exactement la même configuration lors d'une mise à jour ou lors d'une installation initiale. Ça permet de ne pas prendre de risque et d'avoir des machines que l'on sait correctement configurée. On ne maintiens pas 2 versions de scripts etc... Ça réduit drastiquement les risques tout en étant bien plus simple.

    Et c'est pour avoir cette idempotence que l'on ne fait plus de scripts, mais que l'on décrit l'état objectif. Au lieu de dire : « ajoute la ligne "foo" au fichier bar » on dit : « je souhaite qu'il y ait la ligne "foo" dans le fichier bar ». Ce changement de paradigme est très important. Il est gratuit avec pas mal de module d'ansible (je ne sais pas pour les autres), par exemple si on lui demande d'envoyer un fichier sur le serveur, il vérifie s'il n'y ai pas déjà. Mais il y a pleins d'autres cas où il faut soit même le prendre en compte notamment lors de l'utilisation des modules command et shell. Il y a aussi des modules qui ne peuvent pas faire ce genre de vérification (demander un redémarrage de service) dans ces cas là il faut des fois ajouter sois-même ce qu'il faut pour (vérifier que l'on a bien modifié le fichier de configuration du deamon par exemple).

    C'est entre autre ce qui peut rendre vraiment compliqué la création d'un bon role ansible.

    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)