Как точно обрабатывать логические переменные?

В Ansible есть несколько мест, где могут быть определены переменные: в инвентаре, в книжке, в переменных файлах и т.д. Может ли кто-нибудь объяснить следующие наблюдения, которые я сделал?

  1. При определении булевой переменной в инвентаре она ДОЛЖНА быть заглавной (т.е. True/False), в противном случае (т.е. True/false) она не будет интерпретироваться как логическая, а как строка.
  2. В любом из файлов формата YAML (playbooks, ролей и т.д.) Оба True/False и true/false интерпретируются как Booleans.

Например, я определил две переменные в инвентаре:

abc=false
xyz=False

И при отладке типа этих переменных внутри роли...

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

... тогда abc становится unicode но xyz интерпретируется как bool:

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

Однако при определении одних и тех же переменных в playbook, например:

  vars:
    abc: false
    xyz: False

... тогда обе переменные распознаются как bool.

Я должен был осознать это с большим трудом после того, как исполнил пьесу на производстве, запустив что-то, что не должно было запускаться из-за того, что в инвентаре переменная установлена в "ложь" вместо "Ложь". Таким образом, мне бы очень хотелось найти четкий ответ о том, как Ansible понимает логические значения и как он зависит от того, где/как определяется переменная. Должен ли я просто использовать капитализированный True/False, чтобы быть в безопасности? Можно ли сказать, что логические значения в файлах YAML (с key: value формата key: value) не чувствительны к регистру, а в файлах свойств (с key=value формата key=value) они чувствительны к регистру? Любые более глубокие идеи будут высоко оценены.

Ответы

Ответ 1

Переменные, определенные в файлах YAML (playbooks, vars_files, инвентаризации в формате YAML)

Принципы YAML

Playbooks, vars_files и файлы инвентаря, написанные на YAML, сначала обрабатываются парсером YAML. Он допускает несколько псевдонимов для значений, которые будут храниться как Boolean тип: yes/no, true/false, on/off, определенные в нескольких случаях: true/True/TRUE (таким образом, они не учитывают регистр).

Определение YAML определяет возможные значения как:

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

Ansible документы подтверждают, что:

Вы также можете указать логическое значение (true/false) в нескольких формах:

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

Переменные, определенные в файлах инвентаризации в формате INI

Принципы Python

Когда Ansible читает инвентарь в формате INI, он обрабатывает переменные, используя встроенные типы Python:

Значения, передаваемые с использованием синтаксиса key=value, интерпретируются как буквенная структура Python (строки, числа, кортежи, списки, dicts, booleans, None), или как строка. Например, var=FALSE создаст строку, равную FALSE.

Если указанное значение соответствует строке True или False (начиная с заглавной буквы), типу присваивается значение Boolean, в противном случае оно обрабатывается как строка (если не соответствует другому типу).

Переменные, определенные с помощью параметра --extra_vars CLI

Все строки

Все переменные, передаваемые как дополнительные переменные в CLI, имеют строковый тип.