为许多项目管理Ansible角色[关闭]

Question

描述

Ansible content organization documentation仅讨论具有多个临时环境的单个项目。

这很棒，但我需要管理许多将重复使用大量相同Ansible角色的项目。我应该构建一个角色目录，并让所有项目特定的playbook指向“共享”角色目录。或者每个项目是否都有一个专用角色目录，其中只包含与项目相关的角色。以下是我为两者考虑的一些优缺点：

共享角色目录

优点：

• 所有角色都在一个位置。
• 对于跨多个项目共享的角色，角色版本升级将应用于依赖于它的所有项目。

缺点：

• 对于跨多个项目共享的角色，需要在每个项目中测试角色版本更改，即使它不是您正在处理的项目。

专用角色目录

优点：

• 很清楚运行特定项目需要哪些角色。
• 角色版本升级可应用于需要升级的特定项目。

缺点：

• 常见角色被复制/克隆多次。但是，将ansible-galaxy与requirements.yml文件一起使用将处理角色和角色依赖关系的管理。

题

有没有人在这种组织策略中取得成功？

Answer 1

你的分析已经做得很好，概述了要做出决定的大部分要素。

请允许我补充几点注意事项。

一般来说，我正确的答案与ansible关系不大，而与你如何组织脚本和角色的开发有关。特别是在......不同的项目以及不同的角色时会发生什么变化。

在一切都与其他一切都脱节的环境中，你可能想要像ansible-galaxy一样（但是你自己的本地存储库）。在这种情况下，您可以独立开发项目的手册，并重用项目的requirements.yml中定义的角色。对角色的更改可以发布到您的私有星系并进行版本化，以便其他项目可以决定升级或保留其当前版本。可以从一个或不同的存储库中提取角色，但只使用galaxy命令为每个项目提取所需的角色。

在另一个极端情况下，如果您环境中的所有项目都是同步进化的，那么中央方法将更好地工作，因为您将拥有更少的移动部件。一切（所有角色和不同项目的剧本）都可以存储在一个存储库中。

Answer 2

在我之前的工作场所，我们为每个微服务实现了不同的手册。生产中约有30项服务，另有15项正在开发中。更新和管理.yml文件并不是一个太大的问题，因为yaml文件通常很短且易于阅读。

我想说这可能取决于您使用的服务，环境以及开发人员的数量！