В моей системе с помощью Ansible я не хочу указывать become=yes в каждой задаче, поэтому я создал следующий файл ansible.cfg в основном каталоге проекта, а Ansible автоматически запускает все как root:
[privilege_escalation]
become = True
Но по мере роста проекта некоторые новые роли не должны запускаться с правами root. Я хотел бы знать, возможно ли иметь какую-то инструкцию внутри той роли, что все задачи в этой роли должны выполняться как root (например, что-то в vars/), а не глобальное решение ansible.cfg выше!
Я нашел решение, хотя, думаю, лучшее решение должно быть реализовано командой Ansible. Переименуйте main.yml в tasks.yml, а затем напишите следующее в main.yml:
---
- { include: tasks.yml, become: yes }
Другим решением является передача параметра непосредственно в site.yml, но основная идея вопроса заключалась в повторном использовании роли в других проектах, не забывая, что ей нужен root:
---
- hosts: localhost
roles:
- { role: name, become: yes }
Вы также можете обернуть свои задачи в блок и поместить become: yes в блок. Итак, внутри вашего roles/role_name/tasks/main.yml вы сделаете следующее:
- block:
- name: Tasks go here as normal
...
become: yes
Это запустит все задачи внутри блока с правами root. Подробнее о Ansible blocks здесь.
Есть способ сделать то, что вы просите, но вам нужно быть осторожным с тем, как вы его используете, потому что Ansible оценивает большинство vars перед запуском любых задач. Если вы используете этот трюк, вы должны обязательно использовать его последовательно или вы можете непреднамеренно использовать become, где вы не хотите.
Под капотом Ansible использует переменную ansible_become, чтобы определить, использовать ли ее для этой задачи. В рамках вашей роли вы можете создать defaults/main.yml и установить ansible_become: [true/false]. Это приведет к тому, что целая роль примет это значение, если не будет заменена более высоким приоритетом (важно понять приоритет переменной)
Критическая "gotcha" здесь заключается в том, что если вы используете роль, где это определено, она будет влиять на все другие роли, которые называются ниже в игре, если они также не определены.
Примеры:
role_default_become_true имеет ansible_become: true, определяемый как true по умолчанию
role_default_become_false имеет ansible_become: false, определяемый как true по умолчанию
role_no_default не имеет значения по умолчанию ansible_become
---
- name: test1
hosts: localhost
connection: local
roles:
- role_default_become_true
- role_default_become_false
- role_no_default
- name: test2
hosts: localhost
connection: local
roles:
- role_default_become_false
- role_default_become_true
- role_no_default
- name: test3
hosts: localhost
connection: local
roles:
- role_default_become_false
- role_default_become_true
- { role: role_no_default, become: false }
В test1, role_no_default будет работать без старта, потому что предыдущая роль определяла его как ложную, и у нее нет собственного определения.
В test2, role_no_default будет запущен со статьем, потому что предыдущая роль определяла его как true, и у него нет собственного определения.
В test3, role_no_default будет работать без старта, потому что у него есть собственное определение.