c'est du scripting, mais avec un vocabulaire dégueu (playbook = script, role = fonction, task = instruction), la syntaxe est atroce (yaml beurk);
Si tu veux comparer à du scripting, une tâche/action (task) est plutôt une fonction, et le rôle serait un/une module/classe/etc. Perso, j'ai tendance à voir Ansible comme un cadriciel pour orchestrer des déploiements de configuration (à ne pas confondre avec du maintien de configuration que ça peut faire aussi mais où ce n'est pas mieux que d'autres.)
Pour la syntaxe, malgré ton aversion, YAML est le choix le plus judicieux plutôt que de devoir inventer un nouveau langage de balisage et réinventer la roue (pardon, tous les outils pour faire le boulot)
on mélange du descriptif et de l'impératif;
Je crois qu'il y a une confusion parce-que ce n'est pas de l'impératif mais du déclaratif. Comme en SQL où tu indiques dans ton SELECT quoi requête et où sans te préoccuper de programmer toutes les opérations sous-jacentes, chaque tâche Ansible est un appel de module (dans le jargon —ou le vocabulaire dégueu si ça te fait plaisir) auquel tu indique que tu souhaites par exemple qu'un compte soit présent ou basent sans te préoccuper des opérations relatives au user (franchement ça fait le boulot beaucoup mieux que les adduser et compagnie dans tout ce que j'ai pu voir comme script shell, et cerise sur le gâteau : ça s'adapte bien mieux à un parc hétérogène car on n'a pas que des RHEL 8 par exemple.)
Maintenant, si tu lui reproche son côté séquentiel (une tâche après l'autre aulieu de vouloir faire de la magie de Poupée) —est-ce de là que vient la confusion avec un langage impératif ?— il se trouve que c'est ce qui fait sa simplicité et sa force : on sait/suit point par point ce qui est fait et n'impose pas de vision (avec bémol car il y a toujours des limites, mais je me casse moins la tête pour y adapter mes idées là où d'autres outils font une forte résistance)
Le côté descriptif vient juste de ce YAML qui t'insupporte, et c'est un bénéfice indéniable car on n'a pas à se farcir une longue documentation à côté (il en faut quand même mais beaucoup moins et du coup on a moins de souci de ce côté là.)
l'exécution dépends trop de ce qui est présent sur la machine cible (on installe souvent pleins de paquets juste pour faire marcher un module).
Bah justement, ça ne prétend pas faire de magie ou te faire de gamin dans le dos. Ça ne prétend pas non plus remplacer des fonctionnalités existantes mais veut juste les exploiter proprement et prévisiblement (raison pour laquelle j'ai comparé Ansible à cadriciel) Pour reprendre le cas de la gestion des comptes, ça s'appuie sur les bibliothèques/commandes système qui font le job au lieu de prétendre vouloir réinventer l'eau chaude. La base de la solution veille aussi à réduire les dépendances, donc je suis étonné que tu ais besoin d'installer « souvent pleins de paquets juste pour faire marcher un module » Ceci dit, tu peux écrire tes propres modules facilement ou améliorer ceux existant...
"It is seldom that liberty of any kind is lost all at once." ― David Hume
[^] # Re: Encore de l'Ansible...
Posté par Gil Cot ✔ (site web personnel, Mastodon) . En réponse à la dépêche Pile de logiciels libres de déploiement et gestion de grappes de serveurs ou de parc. Évalué à 2.
Objection votre honneur
(:Si tu veux comparer à du scripting, une tâche/action (task) est plutôt une fonction, et le rôle serait un/une module/classe/etc. Perso, j'ai tendance à voir Ansible comme un cadriciel pour orchestrer des déploiements de configuration (à ne pas confondre avec du maintien de configuration que ça peut faire aussi mais où ce n'est pas mieux que d'autres.)
Pour la syntaxe, malgré ton aversion, YAML est le choix le plus judicieux plutôt que de devoir inventer un nouveau langage de balisage et réinventer la roue (pardon, tous les outils pour faire le boulot)
Je crois qu'il y a une confusion parce-que ce n'est pas de l'impératif mais du déclaratif. Comme en SQL où tu indiques dans ton
SELECTquoi requête et où sans te préoccuper de programmer toutes les opérations sous-jacentes, chaque tâche Ansible est un appel de module (dans le jargon —ou le vocabulaire dégueu si ça te fait plaisir) auquel tu indique que tu souhaites par exemple qu'un compte soit présent ou basent sans te préoccuper des opérations relatives auuser(franchement ça fait le boulot beaucoup mieux que lesadduseret compagnie dans tout ce que j'ai pu voir comme script shell, et cerise sur le gâteau : ça s'adapte bien mieux à un parc hétérogène car on n'a pas que des RHEL 8 par exemple.)Maintenant, si tu lui reproche son côté séquentiel (une tâche après l'autre aulieu de vouloir faire de la magie de Poupée) —est-ce de là que vient la confusion avec un langage impératif ?— il se trouve que c'est ce qui fait sa simplicité et sa force : on sait/suit point par point ce qui est fait et n'impose pas de vision (avec bémol car il y a toujours des limites, mais je me casse moins la tête pour y adapter mes idées là où d'autres outils font une forte résistance)
Le côté descriptif vient juste de ce YAML qui t'insupporte, et c'est un bénéfice indéniable car on n'a pas à se farcir une longue documentation à côté (il en faut quand même mais beaucoup moins et du coup on a moins de souci de ce côté là.)
Bah justement, ça ne prétend pas faire de magie ou te faire de gamin dans le dos. Ça ne prétend pas non plus remplacer des fonctionnalités existantes mais veut juste les exploiter proprement et prévisiblement (raison pour laquelle j'ai comparé Ansible à cadriciel) Pour reprendre le cas de la gestion des comptes, ça s'appuie sur les bibliothèques/commandes système qui font le job au lieu de prétendre vouloir réinventer l'eau chaude. La base de la solution veille aussi à réduire les dépendances, donc je suis étonné que tu ais besoin d'installer « souvent pleins de paquets juste pour faire marcher un module » Ceci dit, tu peux écrire tes propres modules facilement ou améliorer ceux existant...
"It is seldom that liberty of any kind is lost all at once." ― David Hume