全局 vs 本地傀儡管理

Question

有没有人用 Puppet 管理过几个地理分布的系统？

我有几个几乎完全相似的部署（服务器 IP 除外），我希望将其管理转换为 Puppet。

我有两个选择：

• 让每个部署托管它自己的 PuppetMaster 以提供本地配置，然后以某种方式同步 PuppetMasters（可能再次与 puppet 同步）

• 在 AWS EC2 上托管 PuppetMaster 以获得高可用性，并从单点为所有部署提供配置

有没有人尝试过第二种选择，结果如何？我对这种环境下的高可用性性能特别感兴趣。

谢谢。

Answer 1

您提出的任何一种方法都没有错。我们有三个 puppetmaster，它们都位于一个站点，并且为世界各地的节点提供服务——我们根据连接的 puppet 节点是否在 dev/test/prod 中将它们分开。其他人更喜欢在每个地理区域运行一个傀儡大师。其他人有很多傀儡大师，有些人只管理一个节点！

关键是在版本控制系统中存储和管理 puppetmaster 清单树至关重要- 将其视为您公司维护的任何其他代码。我推荐 Git，但如果你更习惯的话，Subversion 也可以解决这个问题。Puppetmaster 只是一个服务，它提供 VCS 的特定视图，而不是一个中央数据库本身。

在 VCS 中使用您的内容，然后您可以将所需的清单/模块部署到相应的 puppetmaster，并轻松保持它们同步。约定似乎是为了让每个 puppet 模块都有一个 git/svn repo/module，尽管没有什么能阻止你将整个树放在一个 repo/module 下。

我对你的问题是：

• 每个部署中有多少个节点？如果您说的是 50 岁以上，那么当然值得拥有一位当地的傀儡大师。
• 除了贵公司之外，部署是否有任何第三方使用它们？puppetmaster 需要有非常高的安全性——把它当作打开你所有系统门的钥匙，并且会包含非常敏感的信息。
• 同样，对于基于部署的 PM，您是将它们托管在他们自己的服务器/VM 上，还是需要为现有机器分配任务？为了安全起见，我强烈建议 puppetmaster 服务器单独扮演这个角色。
• 您如何期望 EC2 为您提供更高的可用性？根据我的理解，EC2 实例不是 HA，但应该可以在 AWS 负载均衡器服务后面运行 2 个以上的 puppetmaster。
• 部署有很大不同吗？您想在一天中的不同时间更改它们吗？多个木偶大师为您提供更精细的控制。