厨师食谱组织

Question

背景

我们公司最近决定使用Chef最终自动化我们的部署流程，我的任务是实现这一目标。作为一名开发人员，我目前正在努力采用最佳方法来组织和构建方法和烹饪书，我也可以在Vagrant的开发环境中使用它们。

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

在阅读了几个教程，学习厨师以及观看无尽的视频后，我开始使用berkshelf创建几本烹饪书（每本食谱都在其自己的GIT回购中）：

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

问题

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

Answer 1

厨师的一个挫败感是，有大约100种方法可以做到这一点，社区仍然没有就哪种方式达成最佳共识。也就是说，如果您对Chef的介绍是 learn chef ，并且您正在使用Berkshelf，那么您应该选择 The Berkshelf Way 做事。在这种情况下：

• 每个图书馆食谱都应该依赖于include_recipe您的平台食谱和您的基础架构食谱
• 每个“app cookbook”应该安装并配置1个且只有1个应用程序
• 您应该创建“角色烹饪书”，提供安装每个逻辑应用程序组所需的默认配方和属性

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

至于烹饪书的实际布局，你做得很好。每个食谱的一个回购是一个非常可靠的方法。

Answer 2

此外，我建议每个用例使用一本食谱（LAMP，一个用于apache，一个用于mysql，一个用于php），以便灵活升级每个部分。

只有一本食谱可能会导致版本冲突，即

• Base stack v1.0.0
• 测试新的php版本v1.1.0
• 需要对安全修复程序进行次要的mysql升级=＆gt; V1.0.1

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

一开始听起来很容易，但是一旦你有3或4个部分通过测试/评论，并且你希望推广一些而不是另一个，如果你不能只允许一个部分它就会成为一场噩梦。

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