使用Ansible定义每个角色的`become = yes'

Ter*_*ior 25 ansible

在我使用Ansible的系统配置中,我不想become=yes在每个任务中指定,所以我在项目主目录中创建了以下ansible.cfg,Ansible自动以root身份运行所有内容:

[privilege_escalation]
become = True
Run Code Online (Sandbox Code Playgroud)

但随着项目的不断发展,一些新角色不应该以root身份运行.我想知道是否有可能在角色中有一些指令,该角色中的所有任务都应该以root身份运行(例如,在vars /中运行),而不是上面的全局ansible.cfg解决方案!

Ter*_*ior 45

我找到了一个解决方案,虽然我认为Ansible团队应该实施更好的解决方案.将main.yml重命名为tasks.yml,然后将以下内容写入main.yml:

---
- { include: tasks.yml, become: yes }
Run Code Online (Sandbox Code Playgroud)

另一个解决方案是直接在site.yml中传递参数,但问题的主要思想是在其他项目中重用该角色而不忘记它需要root:

---
- hosts: localhost
  roles:
    - { role: name, become: yes }
Run Code Online (Sandbox Code Playgroud)


Dun*_*ock 29

您还可以将任务包装在一个块中并放在become: yes块上.所以,在你的内心roles/role_name/tasks/main.yml,你会这样做:

- block:

  - name: Tasks go here as normal
    ...

  become: yes
Run Code Online (Sandbox Code Playgroud)

这将以root身份运行块内的所有任务.这里有Ansible的块的更多细节.

  • 为什么"成为"必须在阻止的最后?我希望能够把它放在" - name"之前的开头,但后来我得到了YAML语法错误. (2认同)
  • 虽然我比我更喜欢这种方法,但是我发现了块具有一些局限性的困难方式:[您不能在块内使用块](https://github.com/ansible/ansible/ansible/issues/14222)和[您无法循环播放代码](https://github.com/ansible/ansible/issues/13262),两者都可以通过include来完成。 (2认同)

use*_*170 10

并不是真正完全不同的答案,而是对已经说过的内容进行外观重新格式化。对我来说看起来最短、最干净、最接近 YAML:

- name: My play
  hosts: myhosts
  roles:
    - role: role1
      become: yes

    - role: role2
Run Code Online (Sandbox Code Playgroud)

Role1 将以 root 身份运行,而 role2 不会。