C'est un mauvais langage de script parce que c'est justement pas censé être un langage de script.
Ça ce discute. À partir du moment où cela gère des instructions, des variables, des conditions, des entrées et des sortie, je ne vois pas ce qui le différencie d'un langage de programmation.
En soi Ansible ne gère rien, sinon du déclaratif : on lui donne une liste d'états désirés, et ce sont les modules (Python, PS1, ou autres) qui font le taff. La machine distante (qui peut être localhost à l'occasion), renvoie des états post-opération, et Ansible va donc superviser la suite en fonction de ce retour.
Ansible n'a même pas connaissance des valeurs réelles sur les machines, vu qu'il envoie une charge utile à la machine distante et qu'il n'intervient donc pas durant cette phase (à de rares exceptions près, mais subsidiaires).
Bash peut faire le même travail effectivement : tu gères tes accès à la machine distante, les commandes à envoyer, etc. Mais un dry run ou des opérations un peu complexes (au sens "métier" j'entends), dans une phase d'industrialisation du SI, c'est inimaginable avec Bash. Non que ça soit impossible - par Bash ou par le langage x -, mais parce que c'est juste imbitique par conception, car pas la finalité première.
[^] # Re: il faudrait le réécrire <s>en Rust</s> !
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.
En soi Ansible ne gère rien, sinon du déclaratif : on lui donne une liste d'états désirés, et ce sont les modules (Python, PS1, ou autres) qui font le taff. La machine distante (qui peut être localhost à l'occasion), renvoie des états post-opération, et Ansible va donc superviser la suite en fonction de ce retour.
Ansible n'a même pas connaissance des valeurs réelles sur les machines, vu qu'il envoie une charge utile à la machine distante et qu'il n'intervient donc pas durant cette phase (à de rares exceptions près, mais subsidiaires).
Bash peut faire le même travail effectivement : tu gères tes accès à la machine distante, les commandes à envoyer, etc. Mais un dry run ou des opérations un peu complexes (au sens "métier" j'entends), dans une phase d'industrialisation du SI, c'est inimaginable avec Bash. Non que ça soit impossible - par Bash ou par le langage x -, mais parce que c'est juste imbitique par conception, car pas la finalité première.