我们的基础设施：我们为大约 250 个节点（大约 100 台硬件服务器）运行一个 Puppet Master。节点上的操作系统本身已完全 Puppet 化。
现在我们正在考虑将这个傀儡设置扩展到以下领域：
- IP/DHCP 管理
- APC 配置
- 交换机配置（通过 SNMP，我们有 Arista 交换机）
- 库存管理（服务器 x 机架在哪里？保修还能持续多久？）
有没有软件（开源与否无关）可以让我们实现这一点？我猜想它有一个关系数据模式，例如server或switch可以通过 Web UI 填写。然后，对于这 4 个点中的每一个，都有脚本从表中提取数据并将其推送到设备。
对了，我们为什么不直接用傀儡来做这件事呢？
我们很乐意这样做，因为我们希望将所有配置集中在一个地方，但是......
1+2可以在 puppet 中完成，但对于 250 个节点来说，这看起来像是一个庞大的 puppet 清单。此外，我们希望很快通过 puppet foreman 添加 VM 配置，因此“IP 预留系统”需要“反应灵敏”，因此在我看来需要在 puppet 之外。3
可能不可行，因为交换机尚未准备好用于 puppet，
4 是大概当我们在 Puppet 中的节点层上方添加一个“硬件”层时，使用 Puppet 是有可能的。
有什么想法吗？
答案1
据我所知，领班已经引领了正确的方向，所以也许你应该开始玩弄它。
除此之外，看看定制事实。它们是访问各种数据并使其在 Puppet 清单中可用的强大方法。例如，创建一个自定义事实，$::inventory_ipaddress或者甚至$::ipaddress用用于配置的规范事实覆盖该事实。
对于 1：对于大量主机，通常建议不要有数百个node定义，而是有一组角色和简介。
这里的一般设计挑战是让信息从单一事实来源清晰地流向供应。
对于 2+3：您可以使用 puppet 调用各种辅助脚本和工具，但我怀疑它是否是完成这项工作的最佳工具，因为它可能不是“真相的来源”。
对于 4：这介于两者之间。我自己在 EC2 实例上使用 puppet 定期触发 Zabbix 清单更新，并使用 facter 填充角色、操作系统版本、安全组等。此处需要注意：我的规范事实来源是一个配置工具，我的 puppet 清单中可以更改设置；另一方面，这个清单只是验证结果的最终结果。
答案2
可以使用在交换机本身的 EOS 操作系统上运行的 Puppet 来配置 Arista 交换机。Arista 甚至提供了如何自行安装 Puppet 的教程：在 EOS 上安装 Puppet所以这不是一个问题。
对于库存任务（IP、位置、保修），我推荐 Zabbix。