Не удается обнаружить переменные по умолчанию в своем обработчике
Передает ли ansible переменные по умолчанию для роли в обработчики в той же роли?
Вот минимальная выдержка из пьесы, в которой есть проблема:
Ролевая иерархия
- playbook.yml
- roles/
- gunicorn/
- defaults/
- main.yml
- handlers/
- main.yml
- code-checkout/
- tasks/
- main.yml
Вот содержимое файла
gunicorn / по умолчанию /main.yml
---
gu_log: "/tmp/gunicorn.log"
gunicorn / погрузчики /main.yml
---
- name: Clear Gunicorn Log
shell: rm {{ gu_log }}
завершить разработку / задачи /main.yml
---
- name: Test Handlers
shell: ls
notify:
- Restart Gunicorn
playbook.yml
---
- name: Deploy
hosts: webservers
tasks:
- include: roles/finalize/tasks/main.yml
handlers:
- include: roles/gunicorn/handlers/main.yml
AFAIK все выглядит хорошо. Тем не менее, я получаю эту ошибку во время выполнения playbook
НЕ УДАЛОСЬ! => {"failed": true, "msg": "поле 'args' имеет недопустимое значение, которое, по-видимому, содержит переменную, которая не определена. Ошибка была: 'gu_log' не определено \ n \ n Ошибка был в /roles/gunicorn/handlers/main.yml: строка 3, столбец 3, но может находиться в другом месте файла в зависимости от точной синтаксической проблемы.\n\n Остранная строка выглядит так:\n\n\n- name: перезапустите Gunicorn\n ^ here\n"}
Использование Ansible 2.2 в Ubuntu 12.04 LTS
Вот модифицированная версия скрипта techraf, которая создает все каталоги и демонстрирует мою проблему
#!/bin/bash
mkdir -p ./rtindru-test/roles/gunicorn
mkdir -p ./rtindru-test/roles/gunicorn/defaults
mkdir -p ./rtindru-test/roles/gunicorn/handlers
mkdir -p ./rtindru-test/roles/finalize/tasks
cat >./rtindru-test/roles/finalize/tasks/main.yml <<HANDLERS_END
---
- name: Test Handlers
shell: rm {{ gu_log }}
HANDLERS_END
cat >./rtindru-test/roles/gunicorn/handlers/main.yml <<HANDLERS_END
---
- name: Clear Gunicorn Log
shell: rm {{ gu_log }}
HANDLERS_END
cat >./rtindru-test/roles/gunicorn/defaults/main.yml <<DEFAULTS_END
---
gu_log: "/tmp/gunicorn.log"
DEFAULTS_END
cat >./rtindru-test/playbook.yml <<PLAYBOOK_END
---
- name: Deploy
hosts: localhost
tasks:
- include: roles/finalize/tasks/main.yml
handlers:
- include: roles/gunicorn/handlers/main.yml
PLAYBOOK_END
touch /tmp/gunicorn.log
ls -l /tmp/gunicorn.log
ansible-playbook ./rtindru-test/playbook.yml
ls -l /tmp/gunicorn.log
Выход
ИГРАТЬ [развернуть]
ЗАДАЧА [настройка] ******************************************************************* нормально: [localhost]
ЗАДАЧА [Обработчики тестов] ********************************************* ************** фатально: [localhost]: не удалось! => {"failed": true, "msg": "поле 'args' имеет недопустимое значение, которое, по-видимому, содержит переменную, которая не определена. Ошибка была: 'gu_log' не определено \ n \ n Ошибка был в /rtindru-test/roles/finalize/tasks/main.yml: строка 2, столбец 3, но может \ n находиться в другом месте файла в зависимости от точной проблемы синтаксиса.\n\n Остранная строка выглядит так::\n\n---\n- name: обработчики тестов \ n ^ here \ n "}, чтобы повторить попытку, используйте: --limit @ / rtindru-test / playbook.retry
PLAY RECAP ************************************************* ********************* localhost: ok=1 изменено =0 недоступно =0
не удалось = 1
1 ответ
Вы не определяете и не используете какие-либо роли. Со следующей задачей:
- include: roles/finalize/tasks/main.yml
Вы только включаете файл задач в свою игровую книгу. Это не имеет ничего общего с ролями.
Чтобы назначить роль, вы должны указать список ролей для игры (одна или несколько):
role:
- my_role1
- my_role2
Пожалуйста, ознакомьтесь с документацией по ролям и не стесняйтесь использовать playbook и структуру, созданную с помощью приведенного ниже сценария.
Передает ли ansible переменные по умолчанию для роли в обработчики в той же роли?
Да, это так.
Для доказательства запустите следующий bash-скрипт, который создает и запускает минимальный пример. Он принимает содержимое gunicorn/defaults/main.yml
а также gunicorn/handlers/main.yml
Из вопроса нетронутым и добавляются недостающие компоненты: задачи и сборник пьес. Он создает файл для удаления и запускает playbook.
#!/bin/bash
mkdir -p ./so41285033/roles/gunicorn
mkdir -p ./so41285033/roles/gunicorn/defaults
mkdir -p ./so41285033/roles/gunicorn/handlers
mkdir -p ./so41285033/roles/gunicorn/tasks
cat >./so41285033/roles/gunicorn/tasks/main.yml <<TASKS_END
---
- debug:
changed_when: true
notify: Clear Gunicorn Log
TASKS_END
cat >./so41285033/roles/gunicorn/handlers/main.yml <<HANDLERS_END
---
- name: Clear Gunicorn Log
shell: rm {{ gu_log }}
when: "'apiservers' not in group_names"
HANDLERS_END
cat >./so41285033/roles/gunicorn/defaults/main.yml <<DEFAULTS_END
---
gu_log: "/tmp/gunicorn.log"
DEFAULTS_END
cat >./so41285033/playbook.yml <<PLAYBOOK_END
---
- hosts: localhost
gather_facts: no
connection: local
roles:
- gunicorn
PLAYBOOK_END
touch /tmp/gunicorn.log
ls -l /tmp/gunicorn.log
ansible-playbook ./so41285033/playbook.yml
ls -l /tmp/gunicorn.log
Результат:
-rw-r--r-- 1 techraf wheel 0 Dec 23 07:57 /tmp/gunicorn.log
[WARNING]: Host file not found: /etc/ansible/hosts
[WARNING]: provided hosts list is empty, only localhost is available
PLAY [localhost] ***************************************************************
TASK [gunicorn : debug] ********************************************************
ok: [localhost] => {
"msg": "Hello world!"
}
RUNNING HANDLER [gunicorn : Clear Gunicorn Log] ********************************
changed: [localhost]
[WARNING]: Consider using file module with state=absent rather than running rm
PLAY RECAP *********************************************************************
localhost : ok=2 changed=2 unreachable=0 failed=0
ls: /tmp/gunicorn.log: No such file or directory
Интерпретация:
Перед запуском playbook файл
/tmp/gunicorn.log
был создан и его существование подтверждено:-rw-r--r-- 1 techraf wheel 0 Dec 23 07:57 /tmp/gunicorn.log
После запуска playbook файл
/tmp/gunicorn.log
не существует:ls: /tmp/gunicorn.log: No such file or directory
Ansible правильно передал переменную
gu_log
значение дляClear Gunicorn Log
обработчик, который удалил файл.
Последнее замечание:
Описанную проблему невозможно воспроизвести, поскольку вопрос не содержит полного и поддающегося проверке примера в значении MCVE.