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

我正在寻找有关厨师食谱版本管理的想法。我知道您将特定版本固定在环境中，但是我不确定该怎么做。

我们使用图书馆管理员来将3rd party社区书籍安装到cookbooks文件夹中。我们从不碰那些书，而只是不时更新到最新版本。

我们还提供了针对特定地点的自定义菜谱，其中包括社区菜谱（include_recipe）。

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

因此，没有保证，当您将食谱上传到Chef服务器时，它不会中断生产，因为从属食谱也可能会发生变化。

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

我们还会不时地进行图书管理员检查更新，我想这可能会变得很难跟踪已更改的版本，并且不要忘记及时更新环境中的版本。

请分享您的经验和最佳做法。我相信这对其他人将非常有用。

在我开始认真使用Chef之后不久，我就遇到了这些相同的问题。当我开始做四件事时，我才变得有些理智。请注意，Chef社区中的某些人可能不会将它们视为“最佳做法”。尽管如此，这就是我如何为我的世界带来理智，可重复性和秩序。

1. 创建自己的食谱。我完全停止使用社区食谱，只是按照自己的规范创建了自己的食谱。这样，我可以管理和控制自己的依赖关系。许多人会对此表示反对，但是说实话-如果我先阅读一些Opscode和社区食谱，那么我可能就不会选择Chef作为我的解决方案。我保持食谱简单，并与我的工作方式保持一致。我的存储库中的社区食谱恰好为零。
2. 遵守有关升级的纪律。如果我更新了一个食谱，我会确保它在任何地方都可以使用，并且会麻烦地将其部署到任何地方，即使它破坏了我的工作流程并增加了摩擦。从长远来看，这是保持厨师理智的关键。在极端情况下，如果我需要某些主机的版本（例如测试与生产环境），则可以将它们编码到菜谱中。但是我的理念是，每本食谱的最新版本都应该能够安全地应用于需要的任何地方。
3. 使用Chef Solo完成所有工作。每隔几个月，我就会以某种方式让我重新尝试使用Chef Server。社区版正在改进，但是整个范例似乎永远无法适应我的世界。而且每次我尝试时，我都会脸部疼痛并踢自己。Chef Server范例非常适合需要长期更换系统的长期服务器。我很少进行系统更改，以至于让我的服务器不断地检查厨师服务器以进行更新只是愚蠢的。而且我拥有更好的工具来确保主机健康。我的工作是在一个一次性虚拟机的世界中，在这些虚拟机中，它们只能承受一两个配置更改。我现在专门使用Chef Solo，并将更改推送到我的主机，同时还将完全相同的食谱推送到需要它们的所有主机。
4. 避免在Chef运行期间编译软件。对我而言，最极端（即愚蠢）的案例涉及每次我引导一个新盒子时从源代码编译ruby-1.9.3。但是创建自定义程序包通常会很麻烦。一旦我发现了出色的工具fpm，就可以打包我自己的rpm，deb和gems变得微不足道了，这使我的生活变得更加高效和轻松。

希望这对某人有帮助！

-更新-

近三年后，这些原则仍然对我有所帮助。但是，我还会再添加一条建议，这是出于与我偏爱厨师独奏而不是厨师的相同原因。

5. 使用可替代指令

有两个问题：

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

文章菜谱版本的要点是食谱版本的最佳参考。根据＃1，您说对了，因为管理不同版本的菜谱以提供不同的配置集是一项艰巨的工作，特别是将它与菜谱依赖项混合在一起时，菜谱站点中的大多数菜谱都无法很好地完成这项工作。因此配置可能会中断。如果您没有通过测试任何组件的运行时行为来管理版本，那么它将中断。因此，上传菜谱而不在环境对象中指定版本号是一个坏主意。因此，请在环境对象中管理食谱版本，并在升级任何新食谱的版本时进行仔细测试。我通常在SCM中管理环境对象，直到更改后的菜谱可以与其他现有组件一起正常工作后，我才通过自动化作业将其上传到厨师服务器。

根据＃2，这是一个棘手的主题，因为这是实际配方依赖项在每个节点上起作用的地方。简而言之，对于关键节点，最好通过在节点/角色运行列表中指定配方版本来控制配方的依赖性。我很难做到这一点，因为它可以很好地控制砂砾，并且会花费更多的测试/推广费用。但是，对于关键角色/节点，这不是一个坏主意，但可以为配置更改提供保证。