Определить `становиться = да 'за роль с помощью Ansible

В моей системе с помощью Ansible я не хочу указывать become=yes в каждой задаче, поэтому я создал следующий файл ansible.cfg в основном каталоге проекта, а Ansible автоматически запускает все как root:

[privilege_escalation]
become = True

Но по мере роста проекта некоторые новые роли не должны запускаться с правами root. Я хотел бы знать, возможно ли иметь какую-то инструкцию внутри той роли, что все задачи в этой роли должны выполняться как root (например, что-то в vars/), а не глобальное решение ansible.cfg выше!

ОТВЕТЫ

Ответ 1

Я нашел решение, хотя, думаю, лучшее решение должно быть реализовано командой Ansible. Переименуйте main.yml в tasks.yml, а затем напишите следующее в main.yml:

---
- { include: tasks.yml, become: yes }

Другим решением является передача параметра непосредственно в site.yml, но основная идея вопроса заключалась в повторном использовании роли в других проектах, не забывая, что ей нужен root:

---
- hosts: localhost
  roles:
    - { role: name, become: yes }

Ответ 2

Вы также можете обернуть свои задачи в блок и поместить become: yes в блок. Итак, внутри вашего roles/role_name/tasks/main.yml вы сделаете следующее:

- block:

  - name: Tasks go here as normal
    ...

  become: yes

Это запустит все задачи внутри блока с правами root. Подробнее о Ansible blocks здесь.

Ответ 3

Есть способ сделать то, что вы просите, но вам нужно быть осторожным с тем, как вы его используете, потому что 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 будет работать без старта, потому что у него есть собственное определение.