厨师的菜谱组织

Question

背景

公司最近决定采用厨师和我一直负责实施这一我们的部署进程终于自动化。作为一名开发人员，我正在努力应对如何组织和构建方法和烹饪书的最佳方法，以便我们还可以在我们的开发环境中使用Vagrant。我们有10个应用程序，我们需要部署到几个环境（开发，分段，验收，生产，演示）。每个应用程序都运行在相同的基础技术栈和平台上。其中一些应用程序实际上是其他应用程序的子服务。

阅读一些教程后，学习厨师以及观看无尽的视频，我已经开始创建使用berkshelf几个食谱（每个食谱是在它自己的GIT回购）：

• 1个菜谱设置基本的基础设施（设置管理员用户，安装基本系统工具，sudo，sshd等）
• 1 x食谱设置平台（在我们的例子中：LAMP与固定的PHP版本）
• 10 x食谱设置每个应用程序

问题

这是组织食谱的正确方法吗？尽管应用程序菜谱要求首先运行基础架构和平台菜谱以设置基本系统，但这些菜谱都不依赖于对方（现在）。每个应用程序现在都有相同的技术堆栈要求 - 因此在每个应用程序菜谱中添加相同的依赖关系似乎有点奇怪。应该明确提到应用程序的确切依赖性（对于通过平台食谱安装的软件包，例如apt）仍然明确提及？这一切如何结合在一起，将其部署到目标机器上？我是否需要另一个“容器”食谱（所有机器和食谱的单一厨师回购？），它们将特定的应用程序放在一起？我需要角色来完成这项工作吗？

Answer 1

与厨师的挫折之一是，有大约100种方式来做到这一点，社区尚未形成一个最好的完全共识。这就是说，如果你的厨师介绍是学厨师，而你使用的是Berkshelf，那么你应该看看The Berkshelf Way的做事情。在这种情况下：

• 每个库食谱应取决于和include_recipe平台食谱和基础设施食谱
• 每一个“应用程序食谱”应该安装并配置且只有1个应用
• 您应该创建“角色食谱”提供安装的应用程序

每个逻辑组我也建议所需的默认食谱和属性，你看看'silverware' cookbook by infochimps（现在ironfan-pantry一部分）。将烹饪书绑在一起而不需要显式依赖关系是一种很好的方式。例如，它允许您在一本食谱中声明数据库服务的主机和端口，然后在其他食谱中搜索该服务。这样，您的应用程序就不需要依赖于数据库食谱来查找数据库服务。

至于你的食谱的物理布局，你做得很好。每个食谱的回购是一个非常可靠的方法。

Answer 2

另外，我会建议每个用例（LAMP，一个用于apache，一个用于mysql，一个用于php），以便灵活地升级每个部件。

只有一个食谱最终可能会相互冲突的版本的IE

• 垒叠V1.0.0
• 测试一个新的PHP版本V1.1.0
• 孤男寡女的安全修复次要的MySQL升级=> v1.0.1

现在你在v1.1.0有问题了，你需要报告mysql的变化。

听起来很简单，但一旦你有3或4部分移动通过测试/审查，你希望促进刺激一些而不是其他，它成为一个噩梦，如果你不能只允许一个部分。

如果您确定您将始终有顺序更新，则只能将所有部件包含在一本食谱中。