Ansible: 角色默认目录中的多个文件

你可以在tasks有一个main.yml ，它包括其他文件，甚至在tasks子目录中，例如配置你的主要两个组件 foo 和 bar 的那个大角色：

- include: foo/main.yml
- include: bar/main.yml

对默认角色变量使用include_vars模块首先可以消除默认变量存在的原因，即用于提供“最后的默认值”，它可以很容易地被角色/剧本的其他部分覆盖。

defaults/目录中多个文件的想法之前在 IRC 上讨论过，我们得出结论，解析defaults/目录类似于inventory/group_vars/和inventory/host_vars/目录将是很高兴有。 所需的代码已经存在，希望可以轻松适应角色默认值。

+1

+1

拥有它就好了！

+1

是的，只是假设 defaults/* 被发现并自动加载，如上所述。 由于变量优先级，建议的解决方法（包括任务中的其他默认文件）似乎会覆盖库存

Ansible 2.x 变量优先级

    role defaults [1] (loading all role defaults here critical)
    inventory vars [2]
    inventory group_vars
    inventory host_vars
    playbook group_vars
    playbook host_vars
    host facts
    registered vars
    set_facts
    play vars
    play vars_prompt
    play vars_files
    role and include vars (hack coming in here will override everything above)
    block vars (only for tasks in block)
    task vars (only for the task)
    extra vars (always win precedence)

这可能与#8121有关

+1

+1

由于可变优先级约束，绝对是必须具备的功能。
这也允许为每类变量定义一个默认文件并保持干净的分离； 例如，在网络中，这将允许我为 IPv4 定义一个默认文件，一个为 IPv6 定义一个默认文件，一个为 SNMP 定义一个等等......
最后，似乎有必要将这些文件放入“defaults”下的不同文件夹中。

自己打这个，所以，绝对+1

这真的是一个 PITA。
如果我可以提出一个解决方案，那就是添加一个选项，类似于include_vars ，但在meta/main.yml ，以指定加载顺序。

- dependencies: []
- default_vars:
  - "main.yml"
  - "{{ ansible_os_family }}-{{ ansible_distribution_major_version }}.yml"

这将允许选项默认为["main.yml"]而不会破坏现有代码，同时使开发人员能够根据他们选择的上下文定义粒度变量。

奇怪的。 我完全怀疑这会开箱即用。 少数几次ansible之一实际上违反了最少惊讶的原则......

绝对+1

对于vars/相同，但似乎 #2958 决定反对这个

@cornfeedhobo的示例与我的用例完全匹配。 通过使用 include_vars，我可以防止通过播放轻松覆盖任何单个变量。

另一个接口选项是：

• 向 include_vars 模块添加一个选项，'as_default'，它将处理包含的文件，就像它处于默认值一样。

对我来说，有一个包含单个文件的目录“defaults”确实看起来很奇怪/违反直觉。
我的意思是，你有没有见过一个只有一个__main__.py文件的 python 模块？

这正是我凭直觉认为这张票上谈到的功能已经存在的原因。 “当然我可以有多个默认文件，它有一个目录”

include_role允许您通过defaults_from选项指定“替代”文件http://docs.ansible.com/ansible/include_role_module.html

刚进入需要defaults/main.yml拆分的情况。 将我的 👍 添加到问题中。

一样的，我也需要
+1

+1

@bcoca这是一个很好的补充，增加了灵活性，但没有解决这里的问题，而是将责任放在剧本作者

请查看我上面的评论

是的，这是一个非常有用的功能，可以避免使用 2k 行的文件。
+1

+1

+1

👍

+1

+1

+1
同样的问题在这里。 main.yml 太大，拆分成多个文件。 我们假设它会“正常工作”并在 defaults/ 下的文件中加载所有变量，因为它是一个目录。 不快乐。

+1

+1

+1

👍

+1

+1

👍

你们可以不赞成每条 +1 评论，但我非常怀疑您是否可以跟踪订阅者数量，因此添加 +1 仍然是表示所需支持的不错方式。

在问题的关注度与问题的订阅者数量明确相关之前，永远希望看到 +1 评论。

你可以期待的是 ansible 团队会锁定问题评论，所以不要成为垃圾邮件发送者，也不要为他们辩护。

你可以期待的是 ansible 团队会锁定问题评论，所以不要成为垃圾邮件发送者，也不要为他们辩护。

他们可以这样做，但这是能够正确开发角色的核心问题，尤其是因为在 2.x 中引入了include_role以及旧的roles包含方法。 如果您将角色设计为与include_role兼容，这是可取的，因为它使开发比单独使用旧的roles方法更加模块化和灵活，那么您将剩下跟踪要么将自己的默认设置作为您的剧本中的任务，将责任转嫁给最终用户，他们不应该知道如何执行此操作才能使您的角色正常工作，或将平台/发行版/发布作为您的嵌套级别进行跟踪角色变量使开发变得复杂（尽管我在这里创建了一个可以支持 20 个不同平台版本的角色）。 您是否真的尝试过编写一个实际上支持多个平台的角色？ 毫不奇怪为什么 Ansible Galaxy 上的大多数角色都没有，这个问题可能是 IMO 列表中的第一个问题。

因此，如果他们去锁定这个，根本不回应一个一年前的问题，并向社区发出信号，表明他们对讨论阻止人们创造真正解决方案的关键问题不感兴趣，那么他们绝对可以期望人们不会坚持下去周围并继续使用该产品。 如果他们回复并说明他们是否同意这是一个问题，那么也许人们会停止 +1 以引起对问题的关注。

这只是一个问题，因为他们发布include_role没有考虑在实践中实际使用它会如何影响默认值。 强迫某人在使用roles和include_role之间进行选择以使角色正常工作或添加额外工作以使两者同时工作是这里问题的核心。

我的 2 美分。

PS 如果你因为不想要通知而拒绝 +1 的投票……点击右上角的取消订阅按钮，你就不会再收到它们了。

好的，这个问题对你很重要。 我明白了。 对我来说也是。 这就是我订阅的原因，顺便说一句，这就是我不想取消订阅的原因，这就是我拒绝垃圾邮件发送者的原因，这就是我投票支持原始评论的原因，这是显示 _lazy_ 支持的文明方式。

我想将我的声音添加到对这种能力的请求中，并详细说明我的用例。 除了分解大型 main.yml 的简单能力之外，做这样的事情的能力也会很棒：

- name: Some name
  include_default_vars:
  with_first_found:
    - "{{ ansible_os_family }}-{{ ansible_distribution_major_version }}.yml"
   - main.yml

我希望用它完成的是 [作为示例] 一个支持所有ssh_config 和 sshd_config 选项的 openssh 角色，并支持多个操作系统和版本 [即。 Debian 8/9、EL6/7 等]，但如果用户没有设置 vars 的情况下调用，将安全地将配置构建为 OS_majorversion 默认设置，但可以有任何可用选项被用户覆盖。

就目前而言，如果我将这些操作系统默认值放在 include_vars 中，则优先级太高，用户无法覆盖清单中、group_vars/all 中、group_vars/groupname 中或 host_vars 中的这些设置。

我确信现在有一种方法可以做到这一点，但我能想到的任何东西都非常不雅和丑陋，并且难以维护。 此外，至少到目前为止，我遇到的#ansible 没有人对如何以优雅、可维护的方式做到这一点有更好的想法。

添加此功能将允许这样做，并可能有助于在 github/galaxy 中提供更高质量的角色。

@ ralphie02不，这不是该线程的解决方案。 这只是普通的基于主机的变量，它不同于为多平台角色设置默认值的要求。

类似瓦尔/ feature_idea： https://github.com/ansible/ansible/issues/11639

这真的是一个 PITA。
如果我可以提出一个解决方案，那就是添加一个选项，类似于include_vars ，但在meta/main.yml ，以指定加载顺序。

- dependencies: []
- default_vars:
  - "main.yml"
  - "{{ ansible_os_family }}-{{ ansible_distribution_major_version }}.yml"

这将允许选项默认为["main.yml"]而不会破坏现有代码，同时使开发人员能够根据他们选择的上下文定义粒度变量。

我真的认为这是一个很好的解决方案，现在没有真正简单的方法可以通过 os/version/etc 获得一组不同的默认值。 此实现还保持向后兼容性，因此它也是一个不错的选择。

与@abedwardsw （之前的评论）一致：
来自@cornfeedhobo (15 :+1: !)（或来自@doubletwist13 的更新）的> 2y 旧提案对于我知道的许多角色真的很有用，特别是足够复杂的：
https://github.com/hortonworks/ansible-hortonworks

直接参考他们的评论：

• https://github.com/ansible/ansible/issues/14248#issuecomment -254059046
• https://github.com/ansible/ansible/issues/14248#issuecomment -329027052

另请参阅@geerlingguy的提案（从 2016 年开始！），以及我在那里的评论（试图收集相关问题）： https :