Gestion de configuration ou création d'images : là où l'idempotence et la dérive font la différence

Ce que c'est

Les outils de gestion de configuration tels que Puppet, Salt et Ansible décrivent de façon déclarative l'état souhaité d'un système et y ramènent le système réel à chaque exécution. La documentation de Puppet nomme explicitement cette propriété : "A key feature of Puppet is idempotency — the ability to repeatedly apply code to guarantee a desired state on a system, with the assurance that you will get the same result every time." Le glossaire de Salt définit une action idempotente de la même manière : une action qui "ensures the system is in a well-known state regardless of the system's state before the action is applied", de sorte que "applying the action multiple times results in no changes to the system" dès que le système a déjà convergé. La documentation d'Ansible précise que ses tâches "achieve a form of idempotence by checking the current state before they begin and doing nothing unless the current state is different from the specified final state."

La création d'images (baking, avec Packer et des outils similaires) suit une autre approche : logiciels et configuration sont installés une seule fois, au moment du build, et le résultat est capturé sous forme d'artefact immuable. Une instance démarrée à partir de cette image ne rejoue pas la logique de configuration : elle est simplement l'état qui a été intégré à l'image.

Pourquoi c'est important

Une gestion de configuration idempotente peut s'exécuter en continu (à intervalle régulier ou à chaque démarrage) et corriger la dérive, par exemple un fichier modifié en dehors du processus ou un service désactivé, en réappliquant la même déclaration. La création d'images, elle, ne peut pas du tout corriger la dérive après le démarrage : dès qu'une instance s'écarte de son image (modification manuelle, correctif ponctuel), seul son remplacement par une instance neuve issue de l'image la ramène à l'état voulu. Le baking sacrifie la capacité d'autocorrection au profit d'un démarrage plus rapide et plus prévisible (aucune exécution de configuration nécessaire) et d'une fenêtre plus étroite dans laquelle une mauvaise configuration ou l'échec d'une étape idempotente peut laisser un hôte à moitié convergé.

Comment l'appliquer

• Intégrer à l'image ce qui change rarement et doit être présent dès la première seconde du démarrage : le système d'exploitation de base, les correctifs de sécurité à la date du build, les agents qui doivent déjà tourner.
• Configurer au démarrage (ou en continu) ce qui varie selon l'environnement ou l'instance : noms d'hôte, secrets récupérés depuis un coffre-fort (vault), feature flags, bref tout ce qui doit refléter l'état souhaité actuel et non celui du dernier build d'image.
• Combiner les deux de façon délibérée : une « golden image » qui exécute encore un outil de gestion de configuration au premier démarrage pour le dernier tronçon, propre à l'environnement, avec une trace explicite de la couche responsable de chaque paramètre.
• Considérer les étapes non idempotentes (une ressource de type exec, un provisioner shell brut) comme un risque dans les deux approches, et les rendre explicitement idempotentes (en vérifiant d'abord un marqueur) plutôt que de supposer qu'une exécution unique est sans danger.

Pièges

• S'appuyer sur « ça a marché la dernière fois » comme preuve d'idempotence : une ressource peut sembler idempotente lors des tests et pourtant modifier un système dont l'état initial est différent.
• Reconstruire l'image à chaque déploiement au lieu de le faire quand son contenu intégré change réellement : une stratégie de démarrage rapide devient lente, sans apporter la correction de dérive que chacune des deux approches est censée offrir.
• Confier le même paramètre à la fois au build et au démarrage, de sorte que deux systèmes se le disputent à chaque exécution de convergence.