Ansible 角色依赖项 - 安装但不运行(还) - 如何?

Ste*_*vel 5 dependencies ansible ansible-role

我希望我的角色是可重用的和独立的。为了可重用,每个角色都按照“单一抽象级别”范式完成一项重点工作。这导致了许多小的“原子”角色,在它们之上构建了协调角色层以提供更复杂的抽象。

为了自包含,每个角色都应该声明它对其他角色的依赖。我不希望这种依赖关系与顶级剧本紧密绑定(例如通过 omnibus playbook/roles/requirements.yml)。角色应该完全负责管理(声明)它所依赖的角色。这很容易通过abc_role/meta/main.yml在“依赖项”数组中使用合适的整体来完成。

一切都很好-除了那Ansible塔不仅拉动外部依赖的角色,例如从公共或私人(自定义)库,它也运行中的作用。“拉取外部角色”由 Tower 在 pre-job 中进行,该工作递归地跟踪所有依赖项并将它们收集到剧本的“角色”目录中。这是在启动作业模板本身之前 100%。Ansible 本身也使用相同的依赖声明作为角色的“预任务”序列 - 但没有使用角色的任何协调的好处。这是“供以后使用”功能和“首先执行某些任务”功能的不幸混淆。

想要分离这两个功能的一个简单原因是,我可以有一个可用的角色(即它是从任何地方安装的),但只能根据动态主机值有条件地执行它。(即使可以将角色的任务流放入“dependencies[]”,这些项目似乎也不遵守“when:”条件节。因此,依赖项的条件不在表中。)

根据https://github.com/ansible/ansible/issues/35905 “允许不执行角色依赖项” - 我的这个愿望具有一些公认的价值。不幸的是,#35905 的评论/对话没有提供直接的解决方案或缓解措施(我能找到)。

但我真的想要一个具有我想要的属性的解决方案。是的,我想要我想要的。

所以我撞得头破血流,诅咒我的原生质血统,最后衍生log(deps^tags)为{42}的幂集 -瞧!(见下面我的自拍答案。)

Ste*_*vel 2

只需abc_role/meta/main.yml使用“标签:[从不]”增强〜“依赖项:”的每个元素

这正是我想要的:

  • 角色可以声明它们所依赖的子角色并使它们可用(即从它们来自和安装的任何地方拉下来)
  • 但不强制执行声明序列中的所述子角色作为依赖角色的“前置任务”。

对于“我想看一个实际例子”的人群 -

===== abc_role/meta/main.yml =====

galaxy_info:
  # boring stuff elided...

dependencies: 
  - src: ssh://git@repos-galore.example.com/projectum/subrollio.git
    scm: git
    tags: [never]   # <<<=== This is the key bit
Run Code Online (Sandbox Code Playgroud)

我已经测试过这个并且效果很好。

 _______________ 
<  AWX 6.1.0.0  >
 --------------- 
        \   ^__^
         \  (oo)\_______
            (__)      A )\/\
                ||----w |
                ||     ||

                            Ansible 2.8.2
Run Code Online (Sandbox Code Playgroud)

编辑:实际上,这在实践中不太有效。

它确实按描述工作,但是当通过显式标签(例如从剧本)选择父角色时,尽管有“tags:[never]”元素,但父角色的依赖项数组中列出的子角色将被执行。

我仍在尝试通过摆弄标签或以某种方式操纵它们来恢复我的方法,并且当我有明确的答案时我会更新这篇文章。与此同时,我想澄清我发现和描述的解决方案的(非常)严重的局限性 - 并且(希望永恒)也许可以从我们的社区得到更好的答案......

重新编辑

在通过对角色依赖数组的各种标记组合进行各种敲击以及阅读一些 Ansible 源代码后,我放弃了我的追求。

一年多前,@bcoca(我认为是 Ansible 贡献者之一)表示“安装但不执行”元关键字将是一个不错的选择,但从那时起,该功能请求就没有任何吸引力了。闻起来像死鱼(意思是:这不太可能完成)。

因此,它又回到了(非常烦人的)“用所有需要传递的角色来膨胀剧本的requirements.yml”方法,然后只处理随之而来的疯狂的代码维护。这是一种很糟糕的做事方式,但至少可以让它发挥作用。