l'idée qu'on lance les playbooks localement, sans pouvoir facilement suivre qui a exécuté quoi, avec quels diffs locaux...
Bref, n'avoir rien compris à l'affaire.
L'outil se dit simple parce-que n'imposant rien (là où Puppet par exemple impose une façon de s'organiser.) Tu peux faire des lancements locaux (et faire tout presque comme tu continuerais à faire avec tes scripts) ou tout centraliser (ce qu'il faudrait faire quand on travaille en équipe.) Forcément, comme ça contraint pas (et en cela ces fidèle à la philosophie unixienne), on a vite fait de voir des gens faire n'importe quoi puis raconter des conneries.
Même en mode perso, j'ai tous mes lancements qui sont journalisés (c'est une bête ligne de configuration qui n'est pas imposée.) Et quand je doit utiliser Ansible en entreprise je demande qu'il y a un serveur commun d'administration (à défaut d'avoir un AWX) où j'active cette journalisation.
Pour les diffs locaux, ça fait des lustres qu'il y a l'option --diff à côté duquel tu es visiblement passé. Partout où je suis passé, je l'ai toujours manqué dans la documentation qui va bien (tout les playbooks n'en ont pas besoin mais pour certains j'estime qu'il faut et c'est consigné noir sur blanc.)
sa syntaxe (coder en yaml... faut être maso),
Cette mécompréhension fait qu'on appréhende l'outil de la plus mauvaise manière qui soit. Ce n'est pas du codage mais de la description : il faut se le répéter jusqu'à ce que ça rentre sinon on va faire et dire n'importe quoi. Tu décris des états, tu ne les codes pas (enfin, tu codes si tu écris toi-même les modules sous-jacent.)
La documentation (bien qu'exécutable, d'où la comparaison avec les recettes) n'est pas du code (ni de la littérature remarque.) On décrit des étapes et non la mécanique sous-jacente (si on veut vraiment faire l'analogie avec la programmation, c'est du descriptif comme SQL ou Prolog et non de l'impératif comme Java ou Rust ou Haskell ou même tes scripts shell...)
Et on était contraints de compléter ansible par des scripts qui remplissaient de l'inventaire automatiquement : sans ça, impossible de représenter proprement une ressource de plus haut niveau (les clusters PostgreSQL dans mon cas)
Ce n'est pas un gestionnaire d'inventaire, au contraire ça s'appuie sur un inventaire. Ceci dit, j'ai déjà fait des playbooks pour mettre à jour divers types d'inventaires.)
J'ai l'impression que vous avez passé le temps à utiliser des outils sans vraiment les comprendre, ce qui est vraiment dommage. (ça s'applique à tout, même aux scripts shells : les gens qui viendront juste les lancer sans comprendre ce qu'ils/elles font iront aussi de ce genre de réponses.)
"It is seldom that liberty of any kind is lost all at once." ― David Hume
[^] # Re: il faudrait le réécrire <s>en Rust</s> !
Posté par Gil Cot ✔ (site web personnel, Mastodon) . En réponse au journal Test de vie et Ansible : un exemple de réalisation pour mieux comprendre l'outil. Évalué à 9. Dernière modification le 24 mars 2022 à 23:35.
Conclure par :
Après s'être plaint que :
Bref, n'avoir rien compris à l'affaire.
L'outil se dit simple parce-que n'imposant rien (là où Puppet par exemple impose une façon de s'organiser.) Tu peux faire des lancements locaux (et faire tout presque comme tu continuerais à faire avec tes scripts) ou tout centraliser (ce qu'il faudrait faire quand on travaille en équipe.) Forcément, comme ça contraint pas (et en cela ces fidèle à la philosophie unixienne), on a vite fait de voir des gens faire n'importe quoi puis raconter des conneries.
Même en mode perso, j'ai tous mes lancements qui sont journalisés (c'est une bête ligne de configuration qui n'est pas imposée.) Et quand je doit utiliser Ansible en entreprise je demande qu'il y a un serveur commun d'administration (à défaut d'avoir un AWX) où j'active cette journalisation.
Pour les diffs locaux, ça fait des lustres qu'il y a l'option
--diffà côté duquel tu es visiblement passé. Partout où je suis passé, je l'ai toujours manqué dans la documentation qui va bien (tout les playbooks n'en ont pas besoin mais pour certains j'estime qu'il faut et c'est consigné noir sur blanc.)Cette mécompréhension fait qu'on appréhende l'outil de la plus mauvaise manière qui soit. Ce n'est pas du codage mais de la description : il faut se le répéter jusqu'à ce que ça rentre sinon on va faire et dire n'importe quoi. Tu décris des états, tu ne les codes pas (enfin, tu codes si tu écris toi-même les modules sous-jacent.)
La documentation (bien qu'exécutable, d'où la comparaison avec les recettes) n'est pas du code (ni de la littérature remarque.) On décrit des étapes et non la mécanique sous-jacente (si on veut vraiment faire l'analogie avec la programmation, c'est du descriptif comme SQL ou Prolog et non de l'impératif comme Java ou Rust ou Haskell ou même tes scripts shell...)
Ce n'est pas un gestionnaire d'inventaire, au contraire ça s'appuie sur un inventaire. Ceci dit, j'ai déjà fait des playbooks pour mettre à jour divers types d'inventaires.)
J'ai l'impression que vous avez passé le temps à utiliser des outils sans vraiment les comprendre, ce qui est vraiment dommage. (ça s'applique à tout, même aux scripts shells : les gens qui viendront juste les lancer sans comprendre ce qu'ils/elles font iront aussi de ce genre de réponses.)
"It is seldom that liberty of any kind is lost all at once." ― David Hume