15 мая 2017 г.

ansible host_vars

Оказался в моем inventory старый-старый хост, при работе с которым даже ping падал.

˜# ansible -m ping old.example.com -e ansible_user=ansible
 [WARNING]: Module invocation had junk after the JSON data: usage: sudo -e [-S] [-p prompt] [-u username|#uid] file ...
old.example.com | FAILED! => {
    "changed": false,
    "failed": true,
    "module_stderr": "Shared connection to 192.168.0.1 closed.\r\n",
    "module_stdout": "sudo: illegal option `-n'\r\nusage: sudo -h | -K | -k | -L | -l | -V | -v\r\nusage: sudo [-bEHPS] [-p prompt] [-u username|#uid] [VAR=value]\r\n            {-i | -s | }\r\nusage: sudo -e [-S] [-p prompt] [-u username|#uid] file ...\r\n",
    "msg": "MODULE FAILURE",
    "rc": 1
Дело оказалось в том, что со второй версии изменился набор опций для вызова sudo: добавился параметр -n, которого "старые" sudo могут не знать. Так как подобных хостов у меня пара штук, менять ради них настройки по умолчанию неинтересно. Вместо этого воспользуемся функционалом Host Variables. Идея простая, нам нужно чтобы переменная окружения ansible_sudo_flags не содержала в себе -n для хоста old.example.com. Решение:
# cat /data/ansible/inventory/host_vars/old.example.com.yml
---
## fix ansible regression for old distros (no -n option with sudo)
##
ansible_sudo_flags: "-H"
Почитать о том, какая переменная и откуда важнее при выполнении заданий, можно тут.