在另一个配置文件中包含[puppet]配置文件是否会破坏模块配置文件角色模式？

我对puppet还不熟悉，我正试图弄清楚如何组织模块、配置文件和角色。我对模块概要文件角色模式的一般理解是，每个服务器都有一个角色，角色是从概要文件构建的，概要文件是从模块构建的。下面是我制作的一个粗略的图表，帮助我将其形象化：

我有一个配置文件，我想在其中包含另一个配置文件（使用上面的示例：wordpress服务器可以包含服务器核心，因为我永远不会部署没有服务器核心的wordpress服务器）

这是否打破了这种模式

---

编辑：

为了根据反馈进一步阐述我的问题，这里有一组假设的个人资料。我将以一种特殊的方式命名，这样我们就可以看到它们是如何相互继承的：下划线将用于表示一个概要文件是从另一个（子）概要文件继承的

|-资料/舱单/
|----基地
|----基本linux
|----基本linux服务器
|----基本linux工作站
|----基本窗口
|----基本windows工作站
|----基本windows服务器

现在，让我们添加一个名为“硬化”的概要文件，它是跨平台的，我们希望在所有服务器上都使用它。这稍微打乱了我们的命名方案，但我们可以做到：

|-资料/舱单/
|----基地
|----基本linux
|----基本+强化\u linux\u服务器
|----基本linux工作站
|----基本窗口
|----基本windows工作站
|----基本+强化\u windows\u服务器
|----硬化

aa现在让我们把事情搞砸，为工作站和服务器创建一个配置文件：

|-资料/舱单/
|----基地
|----基本linux
|----基本+强化\u linux\u服务器
|----基本linux工作站
|----基本窗口
|----基本windows工作站
|----基本+强化\u windows\u服务器
|----硬化
|----基本+强化\u linux\u服务器\u基本\u linux

好吧，这有点乱，但我真正关心的是，如果我们不使用这个命名方案，新员工会怎么想：

|-资料/舱单/
|----基地
|----linux_内核
|----linux_服务器
|----linux_工作站
|----窗户
|----台式机
|----win_服务器
|----硬化
|----服务器和工作站

如果新员工的任务是创建一个新的角色，那么没有办法理解这一点，即查看每个个人资料。在其他概要文件中包含概要文件打破了我们可以查看模块/概要文件/以查看角色中包含的内容的假设

所以，重新表述一下我最初的问题：

---

这种配置文件混乱是典型的和预期的，还是因为我打破了模块配置文件角色模式而发生的？

配置文件很多，角色是单一的。所以您的角色仍然应该是单例的，但是在概要文件中有概要文件是可以的，因为您仍然保持代码的干性

你说你担心可能会有后果，但我想不出有什么真正糟糕的事情发生，除了它可能会增加你控制权回购中的清单数量

重要的是要记住，角色和配置文件模式不是福音。它是一个框架，可以确保您的代码保持干燥，并使您的开发人员/系统管理员能够更轻松地可视化各个部分是如何组合在一起的。有时，如果这对你的组织或团队有效，那么你可以改变甚至打破规则

例如，我和一个团队一起工作，这个团队有一个非常大的基本概要文件，其中包含所有组件模块，而且管理起来越来越困难。因此，我帮助将其重构为如下内容：

class profiles::base {

  # include all base profiles
  include ::profiles::base::issue
  include ::profiles::base::motd
  include ::profiles::base::ntp
  include ::profiles::base::postfix
  include ::profiles::base::resolver
  include ::profiles::base::selinux
  include ::profiles::base::snmpd
  include ::profiles::base::sshd
  include ::profiles::base::sysctl

  # include all hardening profiles
  include ::profiles::base::hardening::auditd
  include ::profiles::base::hardening::firewall
  include ::profiles::base::hardening::limits
  include ::profiles::base::hardening::networking
  include ::profiles::base::hardening::shadow
  include ::profiles::base::hardening::xconfig
}

---

这意味着您在基本配置文件中有子配置文件，否则基本配置文件可能会很快变得非常复杂。

角色和配置文件都是基于意见的，因此，如果您增加了使用代码库的复杂性/难度，您只会“破坏”或“做错”。另外，你当前的设计有什么问题，你想改变它吗？我正在戏剧性地扩展我当前的设计，并试图在最大干燥度（包括另一个侧面中的另一个侧面）和最小认知负荷（易于理解的设计模式）之间取得平衡。我希望有一个对木偶有更多经验的人能够指导我的决定，因为我还不清楚这两种选择的全部后果。这是一个很好的图表，似乎表明你对这个模式有很好的总体把握。然而，我倾向于同意@MattSchuchard的观点，即你所询问的细节是一个观点问题——不同的人可能会合理地以不同的方式解释这个模式。实际上，这也是一个你选择称之为“模块”的问题（从技术上讲，所有东西，包括你的角色和概要文件类，都应该在模块中），以及你称之为概要文件的问题。如果你不想把一个配置文件包含在另一个配置文件中，那么你可以考虑将前者改写为“模块”状态。谢谢你的建议和例子。通过“后果”，我并不太担心事情会破裂，而是让下一个查看此代码库的人感到困惑。我认为在另一个配置文件中包含一个配置文件是有意义的，但到目前为止，我只是在我的主要假装架构中尝试使用简单的配置文件。例如，我会发现该配置文件中的模块数量大大增加了代码库维护的难度。所以，所有的观点都是基于你的团队想要什么。@PeterSouter：在考虑了更多之后，我认为你的例子与我的问题有点不同。相反，假设您想要两个轮廓：上面的轮廓和一个没有硬化的轮廓（仅基础轮廓）。为此，您可以将基本配置文件复制粘贴到新的配置文件中，或者将它们放入“核心”配置文件中，然后将其包含在上面。但是：现在你有两个个人资料