问题描述
在使用Ansible开发Playbooks时，有人提到最佳实践是使用可重用的Roles来组织。然而，有些人认为将所有Roles放入一个复杂的文件中也是可以的。他们认为，这种方式并没有解决问题，甚至可能导致更多的管理工作，与编写多个独立Playbooks的效果相当。特别是考虑到可以通过Ansible Tower Workflow重用Playbooks并将它们组合在一起，他们质疑是否有必要引入额外的抽象和复杂性来使用Roles。这个问题是他们的想法是否合理。
解决方案
以下是对于为什么使用Roles进行Ansible Playbooks开发的优势的解释，以及如何以及何时使用Roles的一些指导。
优势和原因
使用Roles相较于编写单一长Playbook有许多优势，而使用单一长Playbook的优势则相对较少，这在特定规模下通常更加明显。团队规模、工作负载数量、复杂性以及执行频率都会影响这种选择。在这些因素逐渐增大的情况下，将事物按照层次结构和模块化的方式组织成Roles将是正确的选择。
重用性
从Awsible文档中可以看到，有一个强调“重用性”的观点：
Roles are ways of automatically loading certain vars_files, tasks, and handlers based on a known file structure. Grouping content by roles also allows easy sharing of roles with other users.
这也是为什么Ansible Galaxy潜在有用的原因。它可以将一长串任务的“效果”总结为一个概念 – 即一个Role。尽管这个Role可能只是一长串任务的列表，但它的主要好处来自于它的变量作用范围。可以采用面向对象的比喻来理解，一个Role就像一个类，而在Playbook中使用该Role就像是实例化一个类为一个对象。如果你认为面向对象编程有用，你也会认为面向对象的基础架构配置是有用的。
测试
对于我个人而言，Roles的选择还与测试有关。Playbook是“战术性”的，适用于“特定情况”。而好的Role是“战略性”的，旨在解决通用问题。由于良好的Roles是模块化的，它们应该包含各种场景的单元测试，以向下游用户证明它们确实解决了更一般的问题，并明确了测试覆盖的范围。典型的Roles应该得到良好的维护，并具有适当的文档：
– 它们使用哪些变量？
– 它们适用于哪些场景？
以及广泛的测试覆盖：
– 几个基本操作系统
– 几种部署场景（Docker、AMIs、裸机等）
并且将任务进行清晰的组织：
– 使用标签
– 基于执行条件和用户提供的变量动态导入任务
等等。
如何使用Roles
在编写Playbooks时，将它们转化为更可维护和具有良好组织结构的Roles可以带来诸多好处。以下是使用Roles的一些建议：
1. 创建Role结构：将Playbook拆分为一个个功能块，并将它们组织成Roles。这将使得每个Role只关注特定的任务，使得代码更加模块化和易于维护。
2. 复用性：Roles可以在不同的Playbooks中重用。这有助于避免重复编写代码，提高效率。
3. 变量作用范围：Roles可以在自己的变量作用域内定义变量，避免了变量之间的冲突。这使得代码更加可靠。
4. 模块化的测试：Roles应该包含单元测试，确保它们按预期工作。这有助于保障Roles的质量。
5. 文档：为每个Role提供清晰的文档，说明它的用途、输入变量、输出效果等。这有助于其他人理解和使用Roles。
综上所述，当项目的规模变得较大，或涉及多个不同场景的部署时，使用Roles能够更好地组织和管理代码，提高代码的可维护性和复用性。在开发Playbooks时，考虑将其拆分为可重用的Roles将会对整个工作流程产生积极影响。
编辑：
在使用Roles时，还要注意一些特定情况：
1. 不希望将Ansible-Galaxy的Roles转换为Playbooks，或要求与之共享的人将Playbooks转换为Roles。
2. 并非所有与你共享或协作的人都能访问Ansible Tower。
3. 测试的重要性，良好的Roles应该进行充分的测试，以保证其在不同场景下的可用性。
通过将这些因素综合考虑，Roles的使用对于规模较大、复杂性较高的项目是有益的。