Я знаю, что ansible playbooks может установить max_fail_percentage
, чтобы разрешить playbook прогрессировать, если хотя бы этот процент хостов преуспел. Однако я хотел запустить специальную команду, которая завершалась успешно (состояние выхода 0), если хотя бы процент хостов выполнялся без ошибок. Является ли это возможным?
Может ли ansible ad-hoc терпеть сбои некоторых хостов?
Ответы (1)
Если у вас есть playbook, который влияет, скажем, на 10 хостов, и в какой-то момент во время выполнения он дает сбой на 1 хосте, Ansible просто продолжит (если вы вообще не установите max_fail_percentage
) на всех остальных хостах. Это поведение по умолчанию, обычно плейбуки перестают выполнять какие-либо шаги на хосте, на котором произошел сбой.
Это также упоминается в документах Ansible: Ansible — max_failure_percentage
Это поведение точно такое же для специальных команд. Тест, тест, тест...
ИЗМЕНИТЬ:
Просто Ansible не будет этого делать, однако вы можете переопределить статус выхода, перенаправив вывод Ansible, например, в однострочник perl и выйти там с другим кодом, это довольно уродливо, но работает :)
См. пример ниже, он завершается с 0, только если > 65% хостов успешно завершены, в противном случае код выхода равен 2. Чтобы отловить сбои и как-то их проанализировать, вам нужно перенаправить STDERR в STDOUT из команды ansible (таким образом, 2>&1 в конце команды Ansible, иначе Perl ее не увидит)
$ ansible all -i provisioning/vagrant-inventory -u vagrant --private-key=~/.vagrant.d/insecure_private_key -m ping 2>&1 | perl -pe 'BEGIN { $failed=0; $success=0;} END { $exit_code=( $success/($success+$failed) ) > 0.65 ? 0 : 2; exit $exit_code;} $failed++ if /\| FAILED/i; $success++ if /\| success/i;'
192.168.111.210 | success >> {
"changed": false,
"ping": "pong"
}
192.168.111.200 | success >> {
"changed": false,
"ping": "pong"
}
192.168.111.211 | FAILED => SSH Error: data could not be sent to the remote host. Make sure this host can be reached over ssh
$ echo $?
0
max_fail_percentage
останавливает следующее воспроизведение, а не текущее.
- person Capi Etheriel; 26.01.2015