фильтр)

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

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

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

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.

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

Ответы на вопрос(1)

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

файлы инвентаризации, написанные на YAML сначала обрабатываются парсером YAML - он допускает несколько псевдонимов для значений, которые будут храниться как логический тип: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, имеют строковый тип.

 dokaspar19 дек. 2017 г., 08:21
Большое спасибо за подробный ответ. Это действительно очень помогло. Но все же это привело меня к еще одной путанице:Что заставляет Ansible оценивать «ложь и правда» как «истину»?
 JonnyJD18 июн. 2018 г., 19:22
отличный ответ, и это объясняет, что нужно сделать, чтобы переменные были в любом случае булевы:stackoverflow.com/a/37895365/1904815 (использоватьbool фильтр)

Ваш ответ на вопрос