我希望推出环境安装 puppet 并希望通过版本控制解决问题。在开始实施我心中认为理所当然的事情之前，我决定阅读一些资料，看看其他人在做什么。
谷歌搜索结果中的第一个是本文讨论动态环境。
虽然动态环境听起来很棒发展，听起来不太安全居住系统。然而，文章暗示，如果你使用动态环境，你将能够摆脱“单一工作流程”。
在我看来，你将会有一个“静态环境集”，无论是否是动态环境，因为在生产中，你将始终使用生产环境. 我会将这个论点扩展到其他重要的实时系统，例如预生产质量保证箱。
我还假设要使动态环境正常工作，您需要在计划测试的代理上运行类似的东西
puppet agent --environment $dev_branch
如果代理尚未被告知使用新环境，谁会在意你是否在 Puppet Master 上公开一个新的开发分支。
我的问题是 - 动态环境是否适用于生产箱、质量保证箱和其他重要系统；还是严格用于开发？
答案1
我认为我没有理解你的问题。“动态环境”只是 puppetmaster 配置和 git 使用的一种样式的名称，它允许你添加和删除 puppet 环境，而无需重新配置 puppetmaster。你可以在动态环境中执行的任何操作都可以在静态环境中执行。puppet 环境的基本概念保持不变，只是在 puppetmaster 上管理它们的过程发生了变化。
您是否需要在“生产”中频繁更改 Puppet 环境实际上取决于您如何管理基础架构。如果您想知道这样做的人，请考虑在 Puppet 邮件列表上提问，而不是在这里提问。
需要记住的一点是，puppet 所称的“环境”不必与您公司所称的环境一一对应。例如，您可以拥有一个“生产”puppet 环境，它对应于您公司生产和 qa 环境中使用的实时 puppet 模块和 hiera 数据，并且您可以拥有一个“开发”puppet 环境，它对应于仍在处理的 puppet 模块和 hiera 数据。
答案2
我们允许不同的组推送到不同的分支，从而控制允许配置的主机/配置集。尽管如此，所有 groupr 共享通用的 puppet 基础架构（以及基本 puppet 脚本）。