• [^] # Re: il faudrait le réécrire <s>en Rust</s> !

    Posté par (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.

    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.

    - name: "Ensuregroupsexist"
     group:
     name: "{{item.key}}"
     gid: "{{item.value.id}}"
     with_dict: users
    - name: "Ensureusersexist"
     user:
     name: "{{item.key}}"
     uid: "{{item.value.id}}"
     group: "{{item.key}}"
     groups: "foo,bar"
     comment: "{{item.value.fn}}"
     shell: "/bin/bash"
     with_dict: users

    À 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

    users:
     idi:
     id: 9050
     fn: "IrvinDirby"
     bob:
     id: 8141
     fn: "BarbObiwan"

    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

    "Ensureuseridiexist":
     user.present:
     - name: "idi"
     - uid: "9050"
     - gid_from_name: True
     - shell: "/bin/bash"
     - groups:
     - "foo"
     - "bar"
     - fullname: "IrvinDirby"
    "Ensureuserbobexist":
     user.present:
     - name: "bob"
     - uid: "8141"
     - gid_from_name: True
     - shell: "/bin/bash"
     - groups:
     - "foo"
     - "bar"
     - fullname: "BarbObiwan"

    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