厨师食谱组织

Question

背景

我们公司最近决定最终使用 Chef 自动化我们的部署流程，而我的任务是实施这一点。作为一名开发人员，我目前正在努力寻找如何组织和构建方法和食谱的最佳方法，以便我也可以在 Vagrant 的开发环境中使用它们。

我们有大约 10 个应用程序需要部署到多个环境（开发、登台、验收、生产、演示）。每个应用程序都在相同的基本技术堆栈和平台上运行。其中一些应用程序实际上是其他应用程序的子服务。

在阅读了几篇教程、学习厨师以及观看无尽的视频之后，我开始使用 berkshelf 创建几本食谱（每本食谱都在它自己的 GIT 存储库中）：

• 1 x 用于设置基本基础架构的说明书（设置管理员用户、安装基本系统工具、sudo、sshd 等）
• 1 x 设置平台的说明书（在我们的例子中：具有固定 PHP 版本的 LAMP）
• 10 份说明书来设置每个应用程序

问题

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

Answer 1

Chef 的挫折之一是大约有 100 种方法可以做到这一点，而社区仍然没有就哪种方法最好形成完整的共识。也就是说，如果您对 Chef 的介绍是learn chef，并且您正在使用 Berkshelf，那么您可能应该看看 Berkshelf 方式 做事。在这种情况下：

• 每个库说明书都应依赖于 include_recipe 您的平台说明书和基础架构说明书
• 每个“应用说明书”应安装和配置 1 个且仅 1 个应用
• 您应该创建“角色说明书”，提供安装每个逻辑应用程序组所需的默认配方和属性

我还建议您查看'silverware' cookbook by infochimps（现在是ironfan-pantry 的一部分）。这是将食谱捆绑在一起而不需要它们之间显式依赖关系的好方法。例如，它允许您在一本说明书中声明数据库服务的主机和端口，然后在其他说明书中搜索。这样，您的应用程序就不需要依赖于您的数据库说明书来找到您的数据库服务。

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

Answer 2

此外，我会为每个用例推荐一本说明书（用于 LAMP，一本用于 apache，一本用于 mysql，一本用于 php），以便灵活地升级每个部分。

只有一本食谱，您最终可能会得到相互冲突的版本，即

• 基础堆栈 v1.0.0
• 测试新的php版本v1.1.0
• 需要对 mysql 进行次要升级以进行安全修复 => v1.0.1

现在v1.1.0有问题，需要在mysql上报告更改。

一开始听起来很容易，但是一旦您有 3 或 4 个部分正在通过测试/审查，并且您希望促进一些而不是其他部分，如果您不能只允许一个部分，它就会成为一场噩梦。

如果您绝对确定您将始终进行顺序更新，您可以将所有部分都包含在一本食谱中。