web-dev-qa-db-fra.com

Comment Ansible analyse-t-il les variables booléennes?

Dans Ansible, il existe plusieurs endroits où les variables peuvent être définies: dans l'inventaire, dans un playbook, dans des fichiers de variables, etc. Quelqu'un peut-il expliquer les observations suivantes que j'ai faites?

  1. Lors de la définition d'une variable booléenne dans un inventaire, elle DOIT être capitalisée (c'est-à-dire vrai/faux), sinon (c'est-à-dire vrai/faux) elle ne sera pas interprétée comme un booléen mais comme une chaîne.
  2. Dans tous les fichiers au format YAML (playbooks, rôles, etc.), True/False et true/false sont interprétés comme des booléens.

Par exemple, j'ai défini deux variables dans un inventaire:

abc=false
xyz=False

Et lors du débogage du type de ces variables dans un rôle ...

- debug:
    msg: "abc={{ abc | type_debug }}  xyz={{ xyz | type_debug }}"

... alors abc devient unicode mais xyz est interprété comme un bool:

ok: [localhost] => {
    "msg": "abc=unicode  xyz=bool"
}

Cependant, lors de la définition des mêmes variables dans un playbook, comme ceci:

  vars:
    abc: false
    xyz: False

... alors les deux variables sont reconnues comme bool.

J'ai dû le réaliser à la dure après avoir exécuté un playbook sur la production, en exécutant quelque chose qui n'aurait pas dû s'exécuter en raison d'une variable définie sur "false" au lieu de "False" dans un inventaire. Ainsi, j'aimerais vraiment trouver une réponse claire sur la façon dont Ansible comprend les booléens et comment cela dépend où/comment la variable est définie. Dois-je simplement utiliser toujours les majuscules Vrai/Faux pour être sûr? Est-il valable de dire que les booléens dans les fichiers YAML (au format key: value) ne respectent pas la casse, tandis que dans les fichiers de propriétés (au format key=value) ils sont sensibles à la casse? Des informations plus approfondies seraient très appréciées.

booleanansibleyamlansible-inventory
15
dokaspar

Variables définies dans les fichiers YAML (playbooks, vars_files, inventaires au format YAML)

Principes YAML

Les playbooks, vars_files et fichiers d'inventaire écrits en YAML sont d'abord traités par un analyseur YAML. Il autorise plusieurs alias pour les valeurs qui seront stockées sous la forme Boolean: yes/no, true/false, on/off, défini dans plusieurs cas: true/True/TRUE (ils ne sont donc pas vraiment insensibles à la casse).

définition YAML spécifie les valeurs possibles comme:

y|Y|yes|Yes|YES|n|N|no|No|NO
|true|True|TRUE|false|False|FALSE
|on|On|ON|off|Off|OFF

Les documents Ansible confirment que :

Vous pouvez également spécifier une valeur booléenne (vrai/faux) sous plusieurs formes:

create_key: yes
needs_agent: no
knows_oop: True
likes_emacs: TRUE
uses_cvs: false

Variables définies dans les fichiers d'inventaire au format INI

Principes de Python

Quand Ansible lit un inventaire au format INI, il traite les variables en utilisant Python types intégrés :

Valeurs transmises en utilisant le key=value la syntaxe est interprétée comme Python structure littérale (chaînes, nombres, tuples, listes, dict, booléens, None), ou comme chaîne. Par exemple var=FALSE créerait une chaîne égale à FALSE.

Si la valeur spécifiée correspond à la chaîne True ou False (commençant par une majuscule), le type est défini sur Boolean, sinon il est traité comme une chaîne (sauf s'il correspond à un autre type).

Variables définies par --extra_vars Paramètre CLI

Toutes les chaînes

Toutes les variables passées comme extra-vars dans CLI sont de type chaîne.

28
techraf