控制厨师食谱版本的最佳策略

Question

我正在寻找有关厨师食谱版本管理的想法。我知道您在环境中固定了特定版本，但我不确定如何去做。

我们使用librarian-chef 将第3 方社区书籍安装到cookbooks 文件夹中。我们从不碰这些书，只是不时更新到最新版本。

我们还提供自定义站点特定食谱，其中包含社区食谱 ( include_recipe)。

理论上我们可以指定自定义书籍所依赖的社区书籍的特定版本，然后在环境配置中设置我们的食谱版本，但问题是这些社区书籍可能依赖于其他一些没有指定版本的书籍。并且这种深度嵌套的依赖可能会持续下去。

因此，无法保证当您将食谱上传到厨师服务器时，它不会破坏产品，因为依赖的食谱也可能会发生变化。

目前我能看到的唯一解决方案是指定我们在环境配置中使用的每个食谱版本，包括社区和自定义版本。但后来我必须仔细阅读每本食谱并找出那些版本。

我们还不时进行图书管理员-厨师更新，我想可能会很难追踪更改的版本，并且在时间到来时不要忘记更新环境中的版本。

请分享您的经验和最佳实践。我相信它对其他人非常有用。

Answer 1

在我开始认真使用 Chef 后不久，我就遇到了同样的问题。当我开始在操作上做四件事时，我才开始理智起来。请注意，Chef 社区中的某些人可能不会将这些视为“最佳实践”。尽管如此，这就是我为我的世界带来理智、可重复性和秩序的方式。

1. 创建您自己的食谱。我完全停止使用社区食谱，只是根据我的规格创建了自己的食谱。通过这种方式，我可以管理和控制自己的依赖项。许多人会反对这一点，但老实说 - 如果我先阅读一些 Opscode 和社区食谱，我可能不会选择 Chef 作为我的解决方案。我保持我的食谱简单，并符合我的工作方式。我的存储库中的社区食谱恰好为零。
2. 对升级有纪律。如果我更新一个配方，我会确保它在任何地方都有效，并且我会经历将它部署到任何地方的额外麻烦，即使它扰乱了我的工作流程并增加了摩擦。从长远来看，这是 Chef 理智的关键。在极端情况下，如果我需要一些主机的变化，例如测试与生产环境，然后我将它们编码到食谱中。但我的理念是，每本食谱的最新版本都应该能够安全地应用于任何需要它们的地方。
3. 使用 Chef Solo 做所有事情。每隔几个月，我就会想我应该再次尝试使用 Chef Server。社区版正在改进，但整个范式似乎永远不适合我的世界。每次我尝试时，我都会用手掌踢自己。Chef Server 范例适用于需要频繁更改系统的长期服务器。我很少进行系统更改，以至于让我的服务器不断检查厨师服务器以进行更新是愚蠢的。而且我有更好的工具来确保我的主机健康。我的工作是在一个一次性虚拟机的世界中，它们可能只能在一两次配置更改中幸存下来。我现在只使用 Chef Solo，并将更改推送给我的主机，同时还将完全相同的食谱推送给所有需要它们的主机。
4. 避免在 Chef 运行期间编译软件。对我来说最极端（即愚蠢）的情况涉及每次引导新盒子时从源代码编译 ruby​​-1.9.3。但是创建自定义包通常是一件麻烦事。一旦我发现了优秀的工具fpm，打包我自己的 rpms、debs 和 gems 就变得微不足道了，让我的生活变得更加高效和轻松。

希望这可以帮助某人！

- 更新 -

近三年后，这些原则对我仍然有帮助。但我会再添加一条建议，这真的是出于同样的原因，我更喜欢厨师独奏而不是厨师。

5. 使用 ANSIBLE 代替

Answer 2

有2个问题：

1. 管理不同环境对象中的食谱版本
2. 管理节点 run_list 中的配方版本。

菜谱版本要点一文是菜谱版本的最佳参考。根据#1，你是对的，因为管理不同版本的说明书来提供不同的配置集是一项艰巨的工作，特别是它与说明书依赖项混合在一起，其中说明书网站上的大多数说明书都不能很好地完成这项工作。所以配置可能会中断。如果您没有通过测试任何组件的运行时行为来管理版本，它就会崩溃。因此，在环境对象中不指定版本号的情况下上传说明书是一个坏主意。因此，管理环境对象中的食谱版本，并在推广任何新食谱的版本时仔细测试。我通常在 SCM 中管理环境对象，并且不会通过自动化作业上传到厨师服务器，直到更改后的食谱可以与其他现有组件的其余部分很好地配合使用。

根据#2，这是一个棘手的主题，因为这是每个节点上实际配方依赖关系起作用的地方。简而言之，对于关键节点，最好通过在节点/角色运行列表中指定配方版本来控制配方的依赖关系。我几乎不这样做，因为它的粒度控制很好，而且测试/推广的成本更高。然而，对于关键角色/节点来说，这不是一个坏主意，而是为配置更改提供了保障。