Тесты
Тесты в Jinja — это способ оценки выражений шаблона и возврата значений True или False. Jinja поставляется со многими из них. См. встроенные тесты в официальной документации по шаблонам Jinja.
Основное различие между тестами и фильтрами заключается в том, что тесты Jinja используются для сравнения, а фильтры — для обработки данных, и они имеют различные применения в jinja. Тесты также могут использоваться в фильтрах обработки списков, таких как map() и select(), для выбора элементов в списке.
Как и все шаблоны, тесты всегда выполняются на контроллере Ansible, а не на целевом узле задачи, так как они проверяют локальные данные.
Помимо этих тестов Jinja2, Ansible предоставляет ещё несколько, а пользователи могут легко создавать свои.
- Синтаксис тестов
- Тестирование строк
- Vault
- Проверка истинности
- Сравнение версий
- Тесты теории множеств
- Проверка, содержит ли список значение
- Проверка, является ли значение списка истинным
- Тестирование путей
- Проверка результатов задач
Синтаксис тестов
Синтаксис тестов отличается от синтаксиса фильтров (variable | filter). Раньше Ansible регистрировал тесты как тесты Jinja и фильтры Jinja, позволяя ссылаться на них с помощью синтаксиса фильтров.
Начиная с Ansible 2.5, использование теста Jinja в качестве фильтра будет вызывать предупреждение.
Синтаксис использования теста Jinja выглядит следующим образом:
variable is test_name
Например:
result is failed
Тестирование строк
Для сопоставления строк с подстрокой или регулярным выражением используйте тесты match, search или regex.
vars:
url: "http://example.com/users/foo/resources/bar"
tasks:
- debug:
msg: "matched pattern 1"
when: url is match("http://example.com/users/.*/resources/")
- debug:
msg: "matched pattern 2"
when: url is search("/users/.*/resources/.*")
- debug:
msg: "matched pattern 3"
when: url is search("/users/")
- debug:
msg: "matched pattern 4"
when: url is regex("example.com/\w+/foo")
match выполняется, если он находит шаблон в начале строки, а search выполняется, если он находит шаблон где-либо в строке. По умолчанию regex работает как search, но regex можно настроить для выполнения других тестов путём передачи ключевого аргумента match_type. В частности, match_type определяет метод re, используемый для выполнения поиска. Полный список можно найти в соответствующей документации Python здесь.
Все тесты строк также принимают необязательные аргументы ignorecase и multiline. Они соответствуют re.I и re.M из библиотеки Python re соответственно.
Vault
Новое в версии 2.10.
Вы можете проверить, является ли переменная встроенным зашифрованным значением Vault, используя тест vault_encrypted.
vars:
variable: !vault |
$ANSIBLE_VAULT;1.2;AES256;dev
61323931353866666336306139373937316366366138656131323863373866376666353364373761
3539633234313836346435323766306164626134376564330a373530313635343535343133316133
36643666306434616266376434363239346433643238336464643566386135356334303736353136
6565633133366366360a326566323363363936613664616364623437336130623133343530333739
3039
tasks:
- debug:
msg: '{{ (variable is vault_encrypted) | ternary("Vault encrypted", "Not vault encrypted") }}'
Проверка истинности
Новое в версии 2.10.
Начиная с Ansible 2.10, теперь вы можете выполнять проверки истинности и ложности, подобные Python.
- debug:
msg: "Truthy"
when: value is truthy
vars:
value: "some string"
- debug:
msg: "Falsy"
when: value is falsy
vars:
value: ""
Кроме того, тесты truthy и falsy принимают необязательный параметр, называемый convert_bool, который попытается преобразовать логические значения в фактические булевы значения.
- debug:
msg: "Truthy"
when: value is truthy(convert_bool=True)
vars:
value: "yes"
- debug:
msg: "Falsy"
when: value is falsy(convert_bool=True)
vars:
value: "off"
Сравнение версий
Новое в версии 1.6.
Примечание
В версии 2.5 version_compare было переименовано в version
Для сравнения номера версии, например, для проверки, является ли версия ansible_facts['distribution_version'] больше или равна ‘12.04’, можно использовать тест version.
Тест version также можно использовать для оценки ansible_facts['distribution_version']:
{{ ansible_facts['distribution_version'] is version('12.04', '>=') }}
Если ansible_facts['distribution_version'] больше или равно 12.04, этот тест возвращает True, иначе False.
Тест version принимает следующие операторы:
<, lt, <=, le, >, gt, >=, ge, ==, =, eq, !=, <>, ne
Этот тест также принимает третий параметр, strict, который определяет, следует ли использовать строгое разбор версии, как определено в distutils.version.StrictVersion. Значение по умолчанию False (используя distutils.version.LooseVersion), True включает строгое разбор версии:
{{ sample_version_var is version('1.0', operator='lt', strict=True) }}
Начиная с Ansible 2.11, тест version принимает параметр version_type, который взаимоисключающий с strict, и принимает следующие значения:
loose, strict, semver, semantic
Использование version_type для сравнения семантической версии было бы реализовано следующим образом:
{{ sample_semver_var is version('2.0.0-rc.1+build.123', 'lt', version_type='semver') }}
При использовании version в playbook или роли не используйте {{ }}, как описано в FAQ:
vars:
my_version: 1.2.3
tasks:
- debug:
msg: "my_version is higher than 1.0.0"
when: my_version is version('1.0.0', '>')
Тесты теории множеств
Новое в версии 2.1.
Примечание
В версии 2.5 issubset и issuperset были переименованы в subset и superset
Чтобы проверить, включает ли список другой список или включён в него, можно использовать «subset» и «superset»:
vars:
a: [1,2,3,4,5]
b: [2,3]
tasks:
- debug:
msg: "A includes B"
when: a is superset(b)
- debug:
msg: "B is included in A"
when: b is subset(a)
Проверка, содержит ли список значение
Новое в версии 2.8.
Ansible включает тест contains, который работает аналогично, но в обратном порядке, по сравнению с тестом Jinja2 in. Тест contains предназначен для работы с фильтрами select, reject, selectattr и rejectattr:
vars:
lacp_groups:
- master: lacp0
network: 10.65.100.0/24
gateway: 10.65.100.1
dns4:
- 10.65.100.10
- 10.65.100.11
interfaces:
- em1
- em2
- master: lacp1
network: 10.65.120.0/24
gateway: 10.65.120.1
dns4:
- 10.65.100.10
- 10.65.100.11
interfaces:
- em3
- em4
tasks:
- debug:
msg: "{{ (lacp_groups|selectattr('interfaces', 'contains', 'em1')|first).master }}"
Новое в версии 2.4.
Проверка, является ли значение списка истинным
Вы можете использовать any и all для проверки, являются ли все или некоторые элементы списка истинными:
vars:
mylist:
- 1
- "{{ 3 == 3 }}"
- True
myotherlist:
- False
- True
tasks:
- debug:
msg: "all are true!"
when: mylist is all
- debug:
msg: "at least one is true"
when: myotherlist is any
Тестирование путей
Примечание
В версии 2.5 следующие тесты были переименованы, чтобы удалить префикс is_
Следующие тесты могут предоставить информацию о пути на контроллере:
- debug:
msg: "path is a directory"
when: mypath is directory
- debug:
msg: "path is a file"
when: mypath is file
- debug:
msg: "path is a symlink"
when: mypath is link
- debug:
msg: "path already exists"
when: mypath is exists
- debug:
msg: "path is {{ (mypath is abs)|ternary('absolute','relative')}}"
- debug:
msg: "path is the same file as path2"
when: mypath is same_file(path2)
- debug:
msg: "path is a mount"
when: mypath is mount
Тестирование форматов размеров
Функции human_readable и human_to_bytes позволяют проверить ваши playbooks, чтобы убедиться, что вы используете правильный формат размера в ваших задачах, и что вы предоставляете формат байтов компьютеру и человекочитаемый формат людям.
Человекочитаемый формат
Утверждает, является ли заданная строка удобочитаемой или нет.
Например:
- name: "Human Readable"
assert:
that:
- '"1.00 Bytes" == 1|human_readable'
- '"1.00 bits" == 1|human_readable(isbits=True)'
- '"10.00 KB" == 10240|human_readable'
- '"97.66 MB" == 102400000|human_readable'
- '"0.10 GB" == 102400000|human_readable(unit="G")'
- '"0.10 Gb" == 102400000|human_readable(isbits=True, unit="G")'
Это приведет к:
{ "changed": false, "msg": "All assertions passed" }
Преобразование человекочитаемого формата в байты
Возвращает заданную строку в формате байтов.
Например:
- name: "Human to Bytes"
assert:
that:
- "{{'0'|human_to_bytes}} == 0"
- "{{'0.1'|human_to_bytes}} == 0"
- "{{'0.9'|human_to_bytes}} == 1"
- "{{'1'|human_to_bytes}} == 1"
- "{{'10.00 KB'|human_to_bytes}} == 10240"
- "{{ '11 MB'|human_to_bytes}} == 11534336"
- "{{ '1.1 GB'|human_to_bytes}} == 1181116006"
- "{{'10.00 Kb'|human_to_bytes(isbits=True)}} == 10240"
Это приведет к:
{ "changed": false, "msg": "All assertions passed" }
Проверка результатов задач
Следующие задачи иллюстрируют тесты, предназначенные для проверки статуса задач:
tasks:
- shell: /usr/bin/foo
register: result
ignore_errors: True
- debug:
msg: "it failed"
when: result is failed
# in most cases you'll want a handler, but if you want to do something right now, this is nice
- debug:
msg: "it changed"
when: result is changed
- debug:
msg: "it succeeded in Ansible >= 2.1"
when: result is succeeded
- debug:
msg: "it succeeded"
when: result is success
- debug:
msg: "it was skipped"
when: result is skipped
Примечание
С версии 2.1 вы также можете использовать success, failure, change и skip, чтобы грамматика соответствовала, для тех, кто хочет быть строгим в этом.
См. также
- Введение в playbooks
-
Введение в playbooks
- Условные операторы
-
Условные операторы в playbooks
- Использование переменных
-
Всё о переменных
- Циклы
-
Циклы в playbooks
- Роли
-
Организация playbooks с помощью ролей
- Советы и хитрости
-
Советы и хитрости для playbooks
- Список рассылки пользователей
-
У вас есть вопросы? Зайдите на группу Google!
- irc.freenode.net
-
IRC-чат-канал #ansible
© 2012–2018 Michael DeHaan
© 2018–2021 Red Hat, Inc.
Licensed under the GNU General Public License version 3.
https://docs.ansible.com/ansible/2.11/user_guide/playbooks_tests.html