Chef：我应该使用环境菜谱模式部署多节点应用程序吗？

Question

关注environment cookbook pattern（特别是使用app.rb recipe for deployment），如果我有一个由前端客户端，后端API和一些服务组成的应用程序（每个不同的Visual Studio项目）并且可能在不同节点上运行）每个组件应该是整个环境食谱中的配方还是每个组件都有自己的食谱？

我认为每个组件本身都是一个不同的应用程序，因此应该有自己的环境手册。

否则我无法想象考虑到有多个节点，环境的app.rb配方将如何部署应用程序。

我是否通过正确思考？其他人如何使用Chef实现分布式应用程序？

编辑： 在仔细研究了几天后，我正在回归并解决 one environment cookbook 模式：

思考练习 - “MyApp”

“MyApp”包含两个单独编译并驻留在不同节点上的软件组件：

1. Web应用程序
2. REST API

当前的食谱设置：

myapp environment cookbook
- recipes
  - webapp.rb
  - restapi.rb

这是合乎逻辑的，还是每个软件组件都应该是自己的食谱？

在当前系统中，发布工件看起来像（每个配方都知道如何部署其工件）：

myapp-vX.X.X artifact
- webapp.tar.gz
- restapi.tar.gz
- cookbooks.tar.gz

目前的版本：
• 1.0.0 - 初步开发
• 1.0.1 - webapp中的错误修复
• 1.1.0 - 添加到API中的新功能和webapp中的错误修复
目前的环境

Dev        Test        Prod
1.1.0      1.1.0       1.0.1

  

“我们需要将1.1.0中的webapp修复程序转移到prod，但我们还没有测试新的API功能。” - 经理

问题：“MyApp”生产环境要求与环境中的dev和test中的v1.1.0 cookbook不同。

可能的解决方案
1. 在没有API功能的情况下剪切1.0.2版本并在环境中进行升级。然后将1.1.0提升回dev并测试;现在我们回到了我们开始的地方，但是错误修复是按照需要进行的。
2. 重新设计烹饪书：使webapp和API组件成为单独的烹饪书。
   • 每个版本都有自己的版本（API 1.0.0可以与prod中的webapp 1.0.1一起使用）
   • 他们像以前一样制作自己的部署工件，但工件会发布到特定于应用程序的存储库（例如myapp-webapp）而不是“MyApp”工件存储库。
   • 新的“myapp”环境只定义了所需的每个应用程序组件手册的版本。
   • 结果：API v1.0.0将与生产中的webapp v1.0.1一起部署。
   • 问题：
     • 即使这些软件是同一逻辑分布式应用程序的一部分，它们的共享数据也不会在逻辑上组合在一起。例如：两者都可能需要在属性中定义API端点（默认[：myapp] [：api] [：endpoint]）。
     • 可能难以跟踪交叉兼容性。 “webapp的1.0.1版本是否与API的v1.2.0兼容？”

似乎有很多方法可以让这只猫受到伤害，但如果你不知道，我更喜欢选择＃1。在决定答案之前，我想获得更多反馈。这有意义吗？

Answer 1

我认为你是对的。由于每个都是独立的VS项目，它应该是它自己的应用程序食谱。这允许您对每个单独的食谱进行版本控制并更改其各自的部署。这将它们彼此分离，允许您对每个部署代码进行更改，而不会意外地影响其他工作代码。

环境食谱是一本食谱，其中包含特定于env的所有实例的内容，例如每个节点都使用ruby或python并且需要安装。

应用程序指南是特定于每个应用程序的东西，因此您的思维过程是正确的，这不应该在应用程序级别的环境中。另请注意，应用程序配置可以在环境级别完成并逐渐减少，但实际部署应该是应用程序手册。