背景
我们公司最近决定最终使用Chef来自动化我们的部署过程，我的任务是执行此任务。作为开发人员，我目前正在努力以最佳方法来组织和构造方法和食谱，以便我也可以在Vagrant的开发环境中使用它们。
我们有大约10个应用程序需要部署到多个环境（开发，暂存，验收，生产，演示）。每个应用程序都在相同的基本技术堆栈和平台上运行。这些应用程序中的某些实际上是其他应用程序的子服务。
在阅读了一些教程，学习厨师以及观看无尽的视频之后，我开始使用berkshelf创建一些烹饪书（每个烹饪书都在它自己的GIT存储库中）：
问题
这是组织菜谱的正确方法吗？尽管该应用程序食谱要求首先运行基础结构和平台食谱以设置基本系统，但这些食谱都不相互依赖（暂时）。目前，每个应用程序都具有相同的技术堆栈要求-因此将相同的依赖关系添加到每个应用程序手册中似乎有些奇怪。是否应该明确提及应用程序的确切依赖关系（对于通过平台食谱安装的软件包，例如apt）？然后如何将所有这些捆绑在一起以将其部署到目标计算机？我是否需要另一本包含特定应用程序的“容器”食谱（所有机器和食谱的单个厨师仓库）？我需要角色来完成这项工作吗？
对厨师的不满之一是，大约有100种方法可以做到这一点，而社区仍未就哪一种是最好的达成共识。就是说，如果您对Chef的介绍是学习厨师，并且您正在使用Berkshelf，那么您应该考虑使用Berkshelf的做事方式。在这种情况下：
include_recipe您的平台食谱和基础结构食谱我还建议您查看infochimps（现在是ironfan-pantry的一部分）的“银器”食谱。这是将菜谱捆绑在一起而无需它们之间显式依赖的一种好方法。例如，它使您可以在一本食谱中声明数据库服务的主机和端口，然后在其他食谱中进行搜索。这样，您的应用程序无需依赖数据库食谱即可查找数据库服务。
至于食谱的物理布局，您做得很棒。每本食谱一个回购是一种非常可靠的方法。
本文收集自互联网，转载请注明来源。
如有侵权，请联系 [email protected] 删除。
我来说两句