我很好奇，是预制二进制文件（安装软件包）和只使用厨师进行configurationpipe理的好策略。 理论上讲，当我们需要新的机器（stream量尖峰）时，应该加快初始化过程，特别是如果我们使用像AWS这样的云来创build我们自己的AMI（图像），同时在其他食谱工作..
我期待着您对这个问题的看法，以及最佳实践，经验和想法！
两端都有其优点和缺点，中间的区域也是如此。
A.在启动时使用带有dynamic系统configuration的标准公共AMI
（+）不需要学习如何构buildAMI。
（+）不需要学习如何pipe理一个稳定的历史AMIs。
（+）通过编辑configuration并运行新的实例，可以轻松更改和testing系统configuration。
（+）易于跨地区pipe理，通过共享configuration文件帐户。
（+）通过调整启动configuration规则，轻松运行configuration的变体。
（ – ）根据启动configuration过程需要完成多less工作，系统的初始启动可能很慢或很慢。
（ – ）需要了解如何自动启动configuration，尤其是在与Auto Scaling或Spot实例一起使用时。
B.预先构build自定义的AMIS
（+）初始启动速度很快，因为不需要进行configuration步骤。
（+）适用于Auto Scaling和Spot实例。
（ – ）需要学习如何有效地构build和pipe理AMI。
（ – ）每当所需的configuration更改时，都需要创build一个新的AMI。
（ – ）每次发布操作系统安全补丁时，都需要构build新的AMI。
（ – ）更改configuration时长编辑/编译/testing循环
（ – ）不同地区所需的多个AMI，不同的帐户（除非共享），不同的configuration变体，不同的实例体系结构。
C.在两者之间的东西
你可以通过在中间做一些事情来获得这两种策略的一些好处（和一些缺点）：创build一个基本的自定义AMI，它拥有你实例所需的大部分内容，然后在运行时运行一个dynamicconfiguration，并完成configuration，应用所需的任何特定变化。
这可能会大大加快启动时间，但也提供了一些灵活性，而不必经常重buildAMI。
build议
首先创build自动脚本（或厨师食谱），将采取公共AMI并将其configuration到您所需的系统。
使用公共AMI的自动化configuration（上面的方法A）只要适用于您。
何时何地遇到启动性能问题，请使用自动configuration来创build自定义AMI（上面的方法B）。 尽可能自动执行此过程，以便可以根据需要随时运行此过程。
如果您在同一基本基础之上有多个系统变体，则构build一个自定义基础AMI并使用上述方法C运行不同的系统风格。