我很好奇预构建二进制文件（安装包）并仅使用 chef 进行配置管理是否是一种好策略。理论上，当我们需要新机器（流量高峰）时，它应该会加快初始化过程，特别是如果我们使用像 AWS 这样的云，我们可以在其中创建自己的 AMI（图像），同时它可能在其他食谱的工作方式方面不够灵活。
我期待您对这个问题的看法以及最佳实践、经验和想法！
答案1
频谱的两端都有其优点和缺点，中间的区域也同样如此。
A. 使用具有启动时动态系统配置的标准公共 AMI
(+) 不需要学习如何构建 AMI。
(+) 不需要学习如何管理稳定的历史 AMI。
(+) 通过编辑配置和运行新实例，轻松更改和测试系统配置。
(+) 通过共享配置文件，可以轻松跨地区、跨账户进行管理。
(+) 通过调整启动配置规则，可以轻松运行配置的变化。
(-) 系统初始启动可能很慢，或者非常慢，这取决于启动配置过程需要完成多少工作。
（-）需要了解如何自动化启动配置，特别是与 Auto Scaling 或 Spot 实例一起使用时。
B. 预构建自定义 AMIS
(+) 初始启动速度很快，因为不需要采取任何配置步骤。
(+) 与 Auto Scaling 和 Spot 实例配合良好。
(-) 需要学习如何有效地构建和管理 AMI。
(-) 每次所需配置发生变化时都需要构建一个新的 AMI。
(-) 每次发布操作系统安全补丁时都需要构建新的 AMI。
(-) 更改配置时较长的编辑/构建/测试循环
(-) 不同区域、不同账户（除非共享）、不同配置变化、不同实例架构需要多个 AMI。
C. 介于两者之间
通过采取中间措施，您可以获得这两种策略的一些好处（和一些缺点）：创建一个包含您实例所需的大部分内容的基本自定义 AMI，然后在运行时运行动态配置以更新和完成配置，应用所需的任何特定变化。
这可能会加快启动时间，但同时也提供了一些灵活性，而不必经常重建 AMI。
建议
首先创建自动脚本（或 Chef 配方），它将采用公共 AMI 并将其配置为所需的系统。
只要对您有用，就使用公共 AMI 的自动配置（上述方法 A）。
当您遇到启动性能问题时，请使用自动配置创建自定义 AMI（上述方法 B）。尽可能自动执行此过程，以便您可以根据需要经常运行它。
如果您在同一个基本基础上有多个系统变体，请构建自定义基础 AMI 并使用上面的方法 C 来运行不同的系统版本。