Chr*_*oph 5 linux git puppet best-practices foreman
我有一个在 Debian 7 上运行的 puppet/foreman 服务器来管理我的系统。我使用的是 puppet and foreman 1.6.0 的社区版本 3.7。我使用目录环境。
目前，我对自己编写的模块使用了相当复杂的工作流程，在我的开发环境中创建它们，这是颠覆控制的，然后将它们导出到外部目录，构建它们的木偶模块（木偶模块构建...）和在生产中安装它。我考虑过使用 subversion 将它们分支/标记到生产中，但由于我不记得的原因，当时排除了这一点。
同时我学习了一点 git 并且宁愿使用 git 而不是 subversion。我的问题是现在是否有最佳实践可以这样做？我可以想象至少两种方法都有其优缺点。一种方法是将环境开发置于版本控制之下，然后将其克隆/分支到生产环境中。其次是制作每个模块的 git repo 并将它们克隆到环境中。
正如我所说，我是 git 的新手，所以我对它的优点和缺点没有真正的了解。此外，我只使用木偶和工头大约 8 个月。
干杯，克里斯托夫
答案实际上取决于您希望如何进行版本控制。主要有以下几种方法：
将所有内容都放在一个单一的平面 Git 存储库中，然后将其克隆到您的主人（或节点，如果您运行的是无主人）。
这是迄今为止最简单的选项，但意味着您将在生产和开发环境中拥有同一模块的多个副本（尽管您可以使用符号链接来解决它）。
将您的主要 Puppet 代码放在一个 Git 存储库中，其中 Git 子模块指向您的自定义模块。部署是与上述相同，通过添加--recursive到git clone。
这种方法的优点是您可以轻松引用外部模块（例如PuppetLabs Apache e 模块），并且相对容易引入上游更改，但您也有必须处理 Git 子模块的开销，这是众所周知的混乱.
运行您自己的 Puppet Forge，并使用Librarian-puppet或R10K来管理模块的安装。
这样做的好处是能够通过SemVer完全控制模块的版本，而无需公开发布它们——尽管运行你自己的 Puppet Forge 仍然被一些人认为是“流血边缘”。