我似乎遇到了两种在多种环境中使用 Puppet 的方法：
1）在每个环境中安装一个 puppetmaster，并且仅在准备在该环境中部署配方时从该环境的源代码控制中更新配方。
2）使用一个 puppetmaster 并在每个客户端的 puppet.conf 中使用一个变量来指定环境，然后在 puppetmaster 中为每个环境指定不同的模块路径，并且每个路径都更新到用于该环境的配方存储库的分支（例如 dev、staging、production）。
只运行一个 puppetmaster 似乎可以减少需要运行的基础设施，但配置上会有一些额外的复杂性。
这些方法中是否还有其他优点或缺点，或者我完全没有注意到什么？
答案1
选项 #1 无法扩展。管理起来会很麻烦。Puppet 正是出于这个原因才支持环境 :)
让一个 Puppetmaster 服务多个环境，每个环境都有自己的manifest指令modulepath。这是许多人使用的非常常见的方法。还要记住：
- Puppet 可以管理您的
puppetmasterd.conf配置puppet.conf文件。 - 根据您的调用方式，
puppetd您还可以使用--environment参数。
答案2
您可以使用 --environtment 从命令行调用 puppetd。但是，如果您想将许多服务器从一个环境移动到另一个环境，那么管理起来会很麻烦。
这领班项目充当“外部节点”界面，允许您从 Web 前端将环境分配给主机/主机组。然后，您可以为不同的主机设置不同的模块路径。您甚至可以从界面更改节点的环境，从而允许您从 Dev->Prod 移动模块路径，或者按照您想要的方式移动。
答案3
我认为你应该看看傀儡标签
答案4
使用 Puppet 环境有几个缺点：
- 您只能从代理可靠地设置 Puppet 环境 — 如果您将密码等明文存储在模块/模板中，这可能会产生一些漏洞。
- 自定义函数仅从 puppetmaster 上默认使用的单一环境加载——这意味着您无法在不同的环境中保留不同版本的自定义函数（如果您使用它们）。
在我工作的一家公司中，我们将使用 2 个 puppetmaster 服务器 — — 一个用于生产，一个用于其余环境。
为了方便管理多个 puppetmaster 上的 puppet 模块，您可以将模块保存在 git 等 VCS 中，并通过 capistrano 等将新版本部署到 puppetmaster。
如果您需要多个环境，不是为了对您的 puppet 模块进行版本控制，而是为了根据环境（不同的变量、节点类等）向不同的节点提供不同的数据，那么还有更多选项：*从基本“环境”节点继承不同环境的节点*通过 ENC（Puppet Dashboard、Foreman）为每个节点提供一组针对每个环境的参数和类，在其中为每个环境创建一个组，并设置所需的参数，然后将您的节点添加到其中。*创建一个返回您的环境的自定义事实或自定义函数（基于本地文件/AWS 标签/数据库查询/等等），并使用该事实使用条件/extlookup/hiera 在您的清单中提供不同的数据。