Petite correction : Salt-stack utilise aussi YAML et Jinja
mais avec un paradigme un peu différent.
Je dirais plus qu'un peu différent. Salt utilise un langage de template (jinja, mais d'autres sont dispos) qui va générer du yaml (ou d'autres). Tu as le choix des armes, et tu peux faire tout en python par exemple.
À contrario, Ansible utilise du yaml avec parfois des bouts de jinja dans les chaines. C'est beaucoup plus encadré.
SSH comme transport au lieu de réinventer quelque avec toutes
les contraintes, inconvénients et avantages. Mais ce choix a
aussi ses bons et mauvais côtés qui sont connus et maîtrisés
par les admins sys et la plupart des devs...
Ansible est en parti inspiré de Taboot, qui a lui même été fait pour aider à l'usage de Func. Le département IT de RH utilisait Taboot et Func il y a 10/15 ans pour l’exécution de commandes (en plus de Puppet), et Fedora utilisait Func/Puppet avant de passer à Ansible.
Func avait son propre bus de messages, et Ansible pouvait l'utiliser via un plugin. Pour le fun, j'ai aussi écrit un plugin pour utiliser celui de Salt (vu que j'ai fait Ansible => Salt => Ansible sur un projet).
Donc le choix de ssh a sans doute été fait en prenant en compte l'expérience acquise d'avoir un bus à maintenir.
Python comme langage pour les modules ...parce-que justement
c'est présent partout (y avait aussi l'alternative PERL mais
comme il faut faire des choix et que ce n'était certainement
pas connu des équipes qui ont créé l'outil, ou pas assez, en
plus d'être un peu en perte de vitesse tandis que l'autre en
gagne.)
RH, à l'époque ou Michael Dehaan y a bossé (eg, 2008/2010) était 4 à 10 fois plus petite que maintenant, et fortement orienté python. Les projets de l'époque comme Yum, Anaconda, Bodhi, Func, c’était du python.
Ensuite, on peut faire des modules en perl ou en bash. Ou des binaires directement en go si on veut. C'est juste que l'upstream ne va pas accepter le code dans le dépôt principal pour des questions de maintenance.
[^] # Re: il faudrait le réécrire <s>en Rust</s> !
Posté par Misc (site web personnel) . En réponse au journal Test de vie et Ansible : un exemple de réalisation pour mieux comprendre l'outil. Évalué à 4.
Je dirais plus qu'un peu différent. Salt utilise un langage de template (jinja, mais d'autres sont dispos) qui va générer du yaml (ou d'autres). Tu as le choix des armes, et tu peux faire tout en python par exemple.
À contrario, Ansible utilise du yaml avec parfois des bouts de jinja dans les chaines. C'est beaucoup plus encadré.
Ansible est en parti inspiré de Taboot, qui a lui même été fait pour aider à l'usage de Func. Le département IT de RH utilisait Taboot et Func il y a 10/15 ans pour l’exécution de commandes (en plus de Puppet), et Fedora utilisait Func/Puppet avant de passer à Ansible.
Func avait son propre bus de messages, et Ansible pouvait l'utiliser via un plugin. Pour le fun, j'ai aussi écrit un plugin pour utiliser celui de Salt (vu que j'ai fait Ansible => Salt => Ansible sur un projet).
Donc le choix de ssh a sans doute été fait en prenant en compte l'expérience acquise d'avoir un bus à maintenir.
RH, à l'époque ou Michael Dehaan y a bossé (eg, 2008/2010) était 4 à 10 fois plus petite que maintenant, et fortement orienté python. Les projets de l'époque comme Yum, Anaconda, Bodhi, Func, c’était du python.
Ensuite, on peut faire des modules en perl ou en bash. Ou des binaires directement en go si on veut. C'est juste que l'upstream ne va pas accepter le code dans le dépôt principal pour des questions de maintenance.