我似乎遇到了在多种环境中使用木偶的两种方法：
1）在每个环境中安装puppetmaster，只准备在该环境中部署配方时更新该环境的源代码pipe理的配方。
2）使用一个puppetmaster，并在每个客户端的puppet.conf中使用一个variables来指定环境，然后在puppetmaster中为每个环境指定一个不同的模块path，并且每个path都被更新到配方库的分支，环境（如开发，分期，生产）。
只有运行一个木偶大师似乎是一个less运行的基础设施，但是在configuration上还有一些额外的复杂性。
这些方法之一还有其他的优缺点吗？或者我完全错过了什么？
选项＃1不会缩放。 这将是一个痛苦的pipe理。 木偶支持环境这个原因:)
让一个傀儡大师服务于多个环境，每个环境都有自己的manifest和modulepath指令。 这是很多人使用的一种很常见的方法。 还要记住：
puppetmasterd.conf和puppet.confconfiguration文件。 puppetd你也可以使用--environment参数。 你可以用–environtment从命令行调用puppetd。 但是，如果要将许多服务器从一个Env移动到另一个，这可能是一个痛苦。
工头项目是一个“外部节点”界面，可让您从Web前端为主机/主机组分配环境。 您可以为不同的主机有不同的模块path。 您甚至可以从界面更改节点的环境，让您从Dev-> Prod或不pipe您想要的移动模块path。
我想你应该看看木偶标签
使用木偶环境有两个缺点：
在我工作的一家公司里，我们将使用2个puppetmaster服务器 – 一个用于生产，另一个用于其他环境。
为了简化几个傀儡pipe理员的傀儡模块pipe理，你可以将你的模块保存在VCS中，比如git，并通过capistrano等等将它们的新版本部署给傀儡主。
如果你需要几个环境不要对你的木偶模块进行版本控制，而是根据环境（不同的variables，节点类等）向不同的节点提供不同的数据，还有更多的select：*从基本的“环境”节点*通过ENC（Puppet Dashboard，Foreman）为每个节点提供每个环境的参数和类的集合，您可以在其中为每个需要参数设置的环境创build一个组，并为其添加节点。 *创build一个自定义的事实或一个返回你的环境的自定义函数（基于本地文件/ AWS标签/数据库查询/不pipe），并使用这个事实来使用条件/ extlookup / hiera在你的清单中提供不同的数据。