最好的策略，以保持厨师食谱版本的控制

在我开始认真使用厨师之后不久，我就碰到了这些相同的问题。 当我开始做四件事情的时候，我只是觉得有一点理智。 请注意，Chef社区中的某些人可能不会将这些视为“最佳做法”。 但是，这就是我带来的理智，可重复性和秩序，以我的世界。

1. 创build你自己的食谱。 我停止使用社区食谱，并根据我的规格简单地创build了我自己的食谱。 这样我pipe理和控制我自己的依赖关系。 许多人会反对这个，但老实说 – 如果我先读了一些Opscode和社区食谱，我可能不会selectChef作为我的解决scheme。 我保持简单的食谱，并符合我的工作方式。 我的存储库中恰好有零社区食谱。
2. 对纪律升级。 如果我更新一个配方，我确保它在任何地方都能正常工作，即使它扰乱了我的工作stream程并增加了摩擦，我也经历了将它部署到各处的额外麻烦。 从长远来看，这是厨师理智的关键。 在极端情况下，如果我需要某些主机的变体，比如testing和生产环境，那么我将它们编码到食谱中。 但我的理念是，每一本食谱的最新版本应该能够安全地应用到需要的地方。
3. 使用厨师独奏的一切。 每过几个月，我都会想方设法地再次尝试使用Chef Server。 社区版本正在改进，但整个范例似乎从来不适合我的世界。 每次我尝试时，我都会面无表情地踢自己。 Chef Server范例适用于需要频繁更改系统的长寿命服务器的世界。 我很less进行系统更改，以至于让我的服务器经常检查一下厨师服务器的更新是愚蠢的。 我有更好的工具来确保我的主人健康。 我的工作是在一次性虚拟机的世界，他们可能只能经历一两个configuration的变化。 我现在只使用Chef Solo，并将更改推送给我的主机，同时也向所有需要它们的主机推送完全相同的菜谱。
4. Chef运行时避免编译软件。 对于我来说，最极端（即愚蠢）的情况是每次引导一个新的盒子时从源代码编译ruby-1.9.3。 但是创build定制软件包往往是一个痛苦的屁股。 一旦我发现了优秀的工具fpm ，将自己的RPM，DEB和gem打包起来变得微不足道，让我的生活变得更加高效和简单。

希望这可以帮助别人！

– 更新 –

差不多三年后，这些原则对我仍然有帮助。 但是我会再增加一条build议，而且这也是出于同样的原因，我更喜欢厨师独奏。

5. 使用ANSSTLE INSTEAD

有两个问题：

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

食谱版本的文章是食谱版本的最佳参考。 根据＃1，你是对的，因为pipe理不同版本的食谱来服务于不同的configuration集合是一件困难的工作，尤其是与食谱依赖关系混合在一起，其中大部分来自食谱站点的食谱不能很好地完成这项工作。 所以configuration可能会中断。 如果你没有通过testing任何组件的运行时行为来pipe理版本，它就会中断。 因此，不用在您的环境对象中指定版本号就可以上传食谱。 因此，在环境对象中pipe理食谱版本，并在推广任何新食谱的版本时仔细testing。 我通常在SCM中pipe理环境对象，没有通过自动化的工作上传到厨师服务器，直到改变后的食谱可以和其他现存的组件一起工作。

根据＃2，这是一个棘手的话题，因为这是每个节点上的实际配方依赖性的作用。 简而言之，对于关键节点，您最好通过在节点/angular色运行列表中指定配方版本来控制配方的依赖性。 我很难做到这一点，因为这是很好的控制和更多的testing/推广成本。 但是，对于关键angular色/节点来说，这不是一个坏主意，而是为configuration更改提供保险。