我正在寻找有关 Chef Cookbooks 版本管理的想法。我知道您会在环境中固定特定版本，但我不知道该怎么做。
我们使用 librarian-chef，它将第三方社区书籍安装到 cookbooks 文件夹中。我们从不碰这些书籍，只是不时更新到较新的版本。
我们还有我们自己定制的特定站点食谱，其中包括社区食谱（include_recipe）。
理论上，我们可以指定自定义书籍所依赖的社区书籍的特定版本，然后在环境配置中设置我们的食谱版本，但问题是这些社区书籍可能会依赖一些没有指定版本的其他书籍。而且这种深度嵌套依赖关系可能会一直持续下去。
因此，无法保证当您将食谱上传到 Chef 服务器时不会破坏产品，因为依赖的食谱也可能会发生变化。
目前我能想到的唯一解决方案是在环境配置中指定我们使用的每个食谱版本，包括社区和自定义版本。但随后我必须浏览每本食谱并找出这些版本。
我们也会不时地进行图书管理员厨师更新，我想追踪更改的版本可能会变得困难，并且在时间到来时不要忘记在环境中更新版本。
请分享您的经验和最佳实践。我相信这对其他人来说会非常有用。
答案1
我开始认真使用 Chef 后不久，就遇到了同样的问题。当我开始在操作上做四件事时，我才有点理智。请注意，Chef 社区中的某些人可能不认为这些是“最佳实践”。尽管如此，这就是我如何为我的世界带来理智、可重复性和秩序的方式。
- 创建您自己的食谱。我完全停止使用社区食谱，而是根据自己的要求创建自己的食谱。这样我就可以管理和控制自己的依赖项。很多人会反对这一点，但老实说 - 如果我先阅读一些 Opscode 和社区食谱，我可能不会选择 Chef 作为我的解决方案。我的食谱保持简单，并符合我的工作方式。我的存储库中没有社区食谱。
- 对升级要有纪律。如果我更新了一个菜谱，我会确保它在任何地方都有效，并且我会不辞辛劳地将它部署到任何地方，即使这会打乱我的工作流程并增加摩擦。从长远来看，这是 Chef 理智的关键。在极端情况下，如果我需要某些主机的变体，例如测试环境与生产环境，那么我会将它们编码到菜谱中。但我的理念是，每个菜谱的最新版本都应该能够安全地应用于任何需要它们的地方。
- 一切事都使用 Chef Solo。每隔几个月，我就会莫名其妙地想到我应该再次尝试使用 Chef Server。社区版正在改进，但整个模式似乎永远不适合我的世界。每次我尝试，我都会感到尴尬和自责。Chef Server 模式适合需要频繁更改系统的长期服务器的世界。我很少进行系统更改，以至于让我的服务器不断检查 Chef 服务器以获取更新简直是愚蠢的。而且我有更好的工具来确保我的主机健康。我的工作是在一次性虚拟机的世界中，它们可能只能在一次或两次配置更改中存活下来。我现在只使用 Chef Solo，并将更改推送到我的主机，同时将完全相同的食谱推送到所有需要它们的主机。
- 避免在 Chef 运行期间编译软件。对我来说最极端（即愚蠢）的情况是每次启动新机器时都要从源代码编译 ruby-1.9.3。但创建自定义包通常是一件很麻烦的事。一旦我发现了优秀的工具平均流量，打包我自己的 rpm、deb 和 gem 变得非常简单，让我的生活变得更加高效和轻松。
希望这对某人有帮助！
- 更新 -
近三年后，这些原则仍然对我有帮助。但我还要补充一条建议，这其实与我更喜欢 chef-solo 而不是 chef 的原因相同。
- 改用 ANSIBLE
答案2
有两个问题：
- 管理食谱版本在不同的环境对象中
- 管理菜谱版本在节点 run_list 中。
文章食谱版本要点是食谱版本的最佳参考。根据#1，你是对的，因为管理不同版本的食谱以提供不同的配置集是一项艰巨的工作，特别是它与食谱依赖项混合在一起，而食谱站点上的大多数食谱都不能很好地完成这项工作。所以配置可能会中断。如果你没有通过测试任何组件的运行时行为来管理版本，它就会中断。因此，在环境对象中未指定版本号就上传食谱是个坏主意。因此，请在环境对象中管理食谱版本，并在推广任何新食谱版本时仔细测试。我通常在 SCM 中管理环境对象，并且直到更改后的食谱可以与其他现有组件很好地协同工作时才通过自动化作业上传到 chef 服务器。
根据 #2，这是一个棘手的话题，因为这是每个节点上实际配方依赖性起作用的地方。简而言之，对于关键节点，您最好通过在节点/角色运行列表中指定配方版本来控制配方的依赖性。我很少这样做，因为它是精细的控制，并且在测试/推广上花费更多。但是，对于关键角色/节点，这不是一个坏主意，但可以为配置更改提供保险。