2

我正在研究在使用 Chef 的同时跨多个主机部署我的应用程序（Web / DB / 应用程序层）的方法。我想出的是使用 Chef 配方将部署的每个步骤表示为一个单独的节点状态。例如，如果有一个处理停止 X 守护进程和监控的步骤，则可以将其编写为简单地期望特定 X 守护进程停止的厨师食谱。同样，将工件从共享位置移动到 Web 根目录的部署步骤也可以引用为代表节点特定状态的厨师配方（将工件从 A 点复制到 B 点）。

整个部署过程将包括基本上完成这三件事的各个步骤：

  1. 根据当前部署步骤修改节点的运行列表。
  2. 让 chef-client 在每个节点上运行
  3. 记录任何失败并允许在失败的节点上重复运行主厨或跳过该步骤，以便继续部署。

问题：

  • 以这种方式使用 Chef（不断修改节点的运行列表以更改节点状态）是一种不好的做法吗？如果是这样，为什么？
  • 协调这一切的最佳方式是什么？我可以在那里使用任何类型的 CI 工具，但是我无法弄清楚如何捕获 chef-client 的输出并能够重复或忽略在特定节点上运行的 chef-client。
4

2 回答 2

3

这真的不是 Chef 最适合做的事情。Chef 擅长收敛配置，而在程序位方面则不那么出色。使用 Chef 处理您进行收敛更改的部分，例如部署新代码或重写配置文件，使用程序工具处理其他部分。

至于协调这一点的工具，如果您想要更多的服务，RunDeck 是一种选择。如果您想要一个命令行工具，请查看 Fabric 或 Capistrano。就我个人而言，我使用 RunDeck 和 Fabric 的组合来获得两者的最佳效果。其他一些不太完整的选项包括 Chef Push Jobs、Mcollective 和 Saltstack。

于 2014-12-01T00:40:35.877 回答
1

Puppet 和 Chef 不是编排工具，从这个角度来看，它们做得非常糟糕。它们的设计初衷不是编排，即使某些具有特定利益的各方正在推动编排定义的界限以使 Chef 被考虑进行编排，但他们忽略了关键事实/需求。不幸的是，我不知道有一个严肃的大型环境编排解决方案——大多数工具都非常特定于某些需求，而有些工具实际上还没有准备好生产。我不得不发明自己的解决方法来完成这项工作，但这样做并不优雅。

于 2015-04-23T23:30:31.323 回答