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.
J'oublie souvent qu'il est possible d'utiliser autre chose (certainement parce-que je suis resté à l'usage de Jinja). Mais en prenant juste ces deux composants, je notais juste les deux approches sans entrer dans les détails.
À contrario, Ansible utilise du yaml avec parfois des bouts de jinja dans les chaines. C'est beaucoup plus encadré.
Exactement. Chez Red Hat (c'est l'actuel propriétaire), on fait du YAML avec des bouts de Jinja2 dedans. Cela a obligé à rajouter des mécanismes d'itération pour aller au delà des limitations de YAML.
À l'inverse, chez VMware (c'est l'actuel propriétaire), on fait du YAML à partir de Jinja2 ; du coup pas besoin de rajouter d'équivalent des with_ par exemple.
{%for key,val in pillar['users'].items() %}"Ensureuser{{key}}exist":user.present:-name:"{{key}}"-uid:"{{val.id}}"-gid_from_name:True-shell:"/bin/bash"-groups:-"foo"-"bar"-fullname:"{{val.fn}}"{%endfor %}
C'est à dire que, pour le dictionnaire de users suivant
Ansible va appeler les modules et les exécuter avec le dictionnaire qu'il aura préparé comme il se doit. Il a fallu rajouter des mots-clés pour passer les limitations natives du formation de description.
SaltStack va d'abord évaluer le gabarit Jinja2 pour générer le YAML mis à plat
Comme le Jinja2 est évalué avant le YAML, pour faire les équivalents de when il faut passer par le mini-langage de templating aussi.
{% set myvar = salt[...] %}
{% if myvar %}
#conditionned YAML here
{% endif %}
Par contre quand on dépend du résultat de la tâche d'avant, là où Ansible offre register (pour exploitation dans le when), on n'a pas d'équivalent avec SaltStack. Par contre, quand on est amené à faire de la programmation Python (ou juste du Jinja2), on apprécie mieux Salt qui n'est pas aussi contraignant que l'autre.
C'était juste une réponse illustrative pour les gens qui nous liraient en se demandant de quoi on parlait exactement au sujet de cette différence d'approche.
"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é à 6. Dernière modification le 27 mars 2022 à 20:53.
J'oublie souvent qu'il est possible d'utiliser autre chose (certainement parce-que je suis resté à l'usage de Jinja). Mais en prenant juste ces deux composants, je notais juste les deux approches sans entrer dans les détails.
Exactement. Chez Red Hat (c'est l'actuel propriétaire), on fait du YAML avec des bouts de Jinja2 dedans. Cela a obligé à rajouter des mécanismes d'itération pour aller au delà des limitations de YAML.
À l'inverse, chez VMware (c'est l'actuel propriétaire), on fait du YAML à partir de Jinja2 ; du coup pas besoin de rajouter d'équivalent des
with_par exemple.C'est à dire que, pour le dictionnaire de
userssuivantAnsible va appeler les modules et les exécuter avec le dictionnaire qu'il aura préparé comme il se doit. Il a fallu rajouter des mots-clés pour passer les limitations natives du formation de description.
SaltStack va d'abord évaluer le gabarit Jinja2 pour générer le YAML mis à plat
Comme le Jinja2 est évalué avant le YAML, pour faire les équivalents de
whenil faut passer par le mini-langage de templating aussi.Par contre quand on dépend du résultat de la tâche d'avant, là où Ansible offre
register(pour exploitation dans lewhen), on n'a pas d'équivalent avec SaltStack. Par contre, quand on est amené à faire de la programmation Python (ou juste du Jinja2), on apprécie mieux Salt qui n'est pas aussi contraignant que l'autre.C'était juste une réponse illustrative pour les gens qui nous liraient en se demandant de quoi on parlait exactement au sujet de cette différence d'approche.
"It is seldom that liberty of any kind is lost all at once." ― David Hume