厨师烹饪书组织

Question

背景

我们公司最近决定使用Chef来实现部署过程的自动化，而我的任务就是实现这一点。作为一名更多的开发人员，我目前正在努力研究如何组织和构造该方法和菜谱的最佳方法，我也可以在我们的开发环境中使用Vagrant。

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

在阅读了几本教程、学习厨师以及观看了无止境的视频之后，我开始用书架创建几本烹饪书(每本烹饪书都在自己的GIT中)：

• 1x安装基本基础设施的食谱(安装管理用户、安装基本系统工具、sudo、sshd等)
• 1x安装平台的食谱(在我们的例子中: LAMP有固定的PHP版本)
• 10 x设置每个应用程序的食谱

问题/s

这是组织烹饪书的正确方法吗？尽管应用程序菜谱需要先运行基础设施和平台菜谱才能设置基本系统，但这些菜谱(目前)都不相互依赖。现在，每个应用程序都有相同的技术栈要求--因此在每个应用程序食谱中添加相同的依赖性似乎有点奇怪。应用程序的确切依赖性(对于通过平台菜谱安装的软件包，例如apt)是否仍应明确提及？如何将所有这些联系在一起，将其部署到目标计算机上？我还需要另一本“容器”烹饪书(所有机器和烹饪书的单一厨师-回购)吗？哪种方法将特定的应用程序结合在一起？我需要角色来完成这个任务吗？

Answer 1

对厨师的不满之一是，有大约100种方法可以做到这一点，而社会上还没有就哪种方法是最好的形成充分的共识。也就是说，如果你对厨师的介绍是学习厨师长，而你使用的是伯克格，那么你应该看看伯克科的做事方式。在这种情况下：

• 每一本库食谱都应该依赖和include_recipe你的平台食谱和基础设施食谱。
• 每个“应用程序食谱”都应该安装和配置一个应用程序，而只有一个应用程序。
• 您应该创建“角色食谱”，提供安装每个逻辑应用程序组所需的默认配方和属性。

我还建议您查看信息黑猩猩的“银器”食谱 (现在是铁扇柜的一部分)。这是一个很好的方法，可以将食谱联系在一起，而不需要它们之间明确的依赖关系。例如，它允许您在一本食谱中声明数据库服务的主机和端口，然后在其他食谱中搜索。这样，您的应用程序就不需要依赖于数据库菜谱来查找数据库服务。

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

Answer 2

此外，我还会重新推荐每个用例一本菜谱( LAMP，apache，mysql，php)，以便在升级每个部分时具有灵活性。

只有一本食谱，你可能最终会有相互矛盾的版本。

• 基堆栈v1.0.0
• 测试新的php版本v1.1.0
• 安全修复=> v1.0.1需要稍微升级mysql

现在，v1.1.0出现了问题，您需要报告mysql上的更改。

一开始听起来很容易，但是一旦你有3到4个部分通过测试/评审，并且你不想促进一些而不是另一个，如果你不能只允许一个部分的话，它就变成了一个噩梦。

如果你绝对肯定你总是有连续的更新，你可以只在一本食谱中包含所有的部分。