Pour compléter : cela permet aussi, lorsque certains éléments techniques ne sont pas centralisés, où le dry run ou une exécution réelle, retourne la "réalité" dans la définition des variables (cf. "Gather facts").
Si l'enjeu de sécurité est fort, Ansible est alors parfait pour "ré-aligner" un serveur / un service d'après un gabarit centralisé et remonter l'alerte.
À titre personnel, je mettrais en premier l'interface ok/changed/failed plus riche que le ok/ko historique du code de retour shell/C.
En Shell ou C, un processus retourne un entier (signé ou non), donc tu as par convention tu as 0 qui vaut "tout va bien"... et 255 autres valeurs pour dire qu'un truc s'est plus ou moins mal passé (ou bien passé, mais avec un truc en plus).
Cependant la richesse relative d'un entier, ne vaut évidemment l'aspect de retours complexes et faciles d'états d'Ansible.
[^] # Re: Ansible
Posté par JulienG . En réponse au journal Test de vie et Ansible : un exemple de réalisation pour mieux comprendre l'outil. Évalué à 4.
Pour compléter : cela permet aussi, lorsque certains éléments techniques ne sont pas centralisés, où le dry run ou une exécution réelle, retourne la "réalité" dans la définition des variables (cf. "Gather facts").
Si l'enjeu de sécurité est fort, Ansible est alors parfait pour "ré-aligner" un serveur / un service d'après un gabarit centralisé et remonter l'alerte.
En Shell ou C, un processus retourne un entier (signé ou non), donc tu as par convention tu as 0 qui vaut "tout va bien"... et 255 autres valeurs pour dire qu'un truc s'est plus ou moins mal passé (ou bien passé, mais avec un truc en plus).
Cependant la richesse relative d'un entier, ne vaut évidemment l'aspect de retours complexes et faciles d'états d'Ansible.