【问题标题】：Continuous deployment & Orchestration with Chef使用 Chef 进行持续部署和编排
【发布时间】：2015-01-28 18:21:37
【问题描述】：
我正在研究如何在使用 Chef 的同时跨多个主机部署我的应用程序（Web/DB/应用程序层）。我想出的是使用 Chef 配方将部署的每个步骤表示为单个节点状态。例如，如果有一个步骤处理 X 守护程序的停止和监控，它可以写成一个厨师食谱，只期望停止特定的 X 守护程序。
同样，将工件从共享位置移动到 Web 根目录的部署步骤也可以引用为代表节点特定状态的厨师配方（将工件从 A 点复制到 B 点）。
整个部署过程将包括基本上完成这三件事的各个步骤：
- 根据当前部署修改节点的运行列表
步骤。
- 在每个节点上运行 chef-client
- 记录所有故障并允许在故障节点上重复运行主厨或跳过该步骤，以便继续部署。
问题：
- 以这种方式使用 Chef（不断修改节点的运行列表以更改节点状态）是一种不好的做法吗？如果是这样，为什么？
- 协调这一切的最佳方式是什么？我可以在那里使用任何类型的 CI 工具，但我无法弄清楚如何捕获 chef-client 的输出以及如何重复或忽略特定节点上的 chef-client 运行。
【问题讨论】：
标签：
chef-infra
continuous-deployment
orchestration
【解决方案1】：
这真的不是 Chef 最适合做的事情。 Chef 擅长收敛配置，而在程序位方面则不那么出色。使用 Chef 处理您进行收敛更改的部分，例如部署新代码或重写配置文件，其他部分使用程序工具。
至于协调这一点的工具，如果您想要更多服务性的东西，RunDeck 是一种选择。如果您想要一个命令行工具，请查看 Fabric 或 Capistrano。就我个人而言，我使用 RunDeck 和 Fabric 的组合来获得两者的最佳效果。其他一些不太完整的选项包括 Chef Push Jobs、Mcollective 和 Saltstack。
【解决方案2】：
Puppet 和 Chef 不是编排工具，从这个角度来看，它们做得非常糟糕。它们的设计初衷不是编排，即使某些具有特定利益的各方正在推动编排定义的界限以使 Chef 被考虑进行编排，但他们忽略了关键事实/需求。不幸的是，我不知道有一个严肃的大型环境编排解决方案——大多数工具都非常特定于某些需求，而有些工具实际上还没有准备好生产。我不得不发明自己的解决方法来完成这项工作，但这样做并不优雅。