1

遵循环境说明书模式（特别是使用app.rb 部署配方），如果我有一个由前端客户端、后端 API 和一些服务组成的应用程序（每个不同的 Visual Studio 项目和可能在不同的节点）每个组件应该是整个环境食谱中的一个食谱还是每个组件都有自己的食谱？

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

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

我是否正确地考虑了这一点？其他人如何使用 Chef 实现分布式应用程序？

编辑：在考虑了几天之后，我正在退后并确定一个环境食谱模式：

思维练习——“MyApp”

“MyApp”由两个分别编译并驻留在不同节点上的软件组件组成：

  1. 网络应用
  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”生产环境要求与位于开发和测试环境的 v1.1.0 说明书不同。

可能的解决方案
  1. 删除没有 API 功能的 1.0.2 版本，并在环境中升级它。然后将 1.1.0 推广回 dev 和 test；现在我们回到了我们开始的地方，但是错误修复是根据需要在生产中的。
  2. 重新架构说明书：使 webapp 和 API 组件成为单独的说明书。
    • 每个都有自己的版本（API 1.0.0 可以与产品中的 webapp 1.0.1 一起使用）
    • 他们像以前一样生成自己的部署工件，但工件被发布到特定于应用程序的存储库（例如 myapp-webapp）而不是“MyApp”工件存储库。
    • 新的“myapp”环境将只定义它需要的每个应用程序组件说明书的版本。
    • 结果：API v1.0.0 将与 webapp v1.0.1 一起部署在生产环境中。
    • 问题：
      • 即使这些软件是同一个逻辑分布式应用程序的一部分，它们的共享数据也没有在逻辑上组合在一起。例如：两者都可能需要在属性中定义 API 端点（default[:myapp][:api][:endpoint]）。
      • 可能很难跟踪交叉兼容性。“webapp 的 1.0.1 版本是否与 API 的 v1.2.0 兼容？”

似乎有很多方法可以给这只猫剥皮，但如果你看不出来，我更喜欢选项#1。在决定答案之前，我很想获得更多反馈。这有意义吗？

4

1 回答 1

0

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

环境说明书是包含环境所有实例的特定内容的说明书，例如每个节点都使用 ruby​​ 或 python 并需要安装。

应用程序说明书是每个应用程序特定的东西，所以你的思考过程是正确的，这不应该在它应该在应用程序级别的环境中。另请注意，应用程序配置可以在环境级别完成并逐渐下降，但它本身的实际部署应该是应用程序说明书。

于 2014-12-18T21:12:58.887 回答