我们计划使用非“预烘焙”的AMI EC2实例。即，当它们旋转时，它们是AWS linux的裸装。我们的引导过程将提取我们需要的各种安装，例如python，tomcat。我们将最少有3个实例，最多8个实例。
鉴于这些要求，使用Puppet / Chef会比使用Amazon Cloud Formation（CloudInit）有用吗？
我所能看到的最好是，如果我们使用了Puppet，那么我们将使用声明式编程，该脚本相对于脚本而言更易于审核，以了解发生了什么。另外，CloudInit的脚本大小限制为16k，我们可能会遇到也可能不会遇到。
是否有人出于特定原因可以从CloudInit迁移到Puppet或Chef，以在此处回答我的问题？
Answers:
与CloudInit相比有优势吗？是的，绝对有很多！
当然，一旦CloudInit脚本配置了服务器，您就可以编写从上到下的运行。但是，当您需要更改配置文件，添加用户，更新程序包或安装新程序包时会发生什么？您最终将登录服务器或编写脚本来这样做，并且不可避免地会导致服务器状态不一致。
CloudInit不是配置管理。如果您选择开始使用配置管理软件，则仅将Cloud Init用于一项任务：引导Puppet / Chef / other代理。
Puppet不仅可以帮助您自动安装软件包，设置ssh密钥或调整Tomcat堆。它确保事物的状态。当开发人员在凌晨3点对Java应用程序进行故障排除并更改Tomcat配置时，Puppet会将其改回。您可以为所有节点或节点组快速更改Python的版本，如果有人安装了其他版本，Puppet会将其重新更改。
当您的应用程序堆栈发生更改并开始使用RabbitMQ或Jetty或新的RDBMS时，您可以轻松地在数十或数千台服务器上测试和部署更改。
使用配置管理软件还有许多其他原因，例如后端报告，审核和安全合规性。
配置管理的重点是可预测地和一致地启动计算机。当您仅限于AWS时，CloudFormation和cloudinit会很棒（尽管调试CloudFormation模板是一种惨痛的经历）），但是同时使用数据中心资源和AWS的应用程序，本地测试环境或开发机器又如何呢？
如果您纯粹存在于AWS中，我想您可以摆脱cloudinit的束缚，但我不相信对于任何规模的应用程序都是现实的（例如，Netflix使用他们编写的OSS技术预先烘焙了AMI）并发布给全世界；请查看此视频以获取详细信息）。高度可用的应用程序是跨区域的，通常基于VPC，它们倾向于通过VPN备份到数据中心，这甚至不涉及演示，登台，测试或开发环境。作为负责预配机器的人，我要做的最后一件事是重复工作或陷入调试多种预配方法的困境。
因此，厨师或木偶。它们对AWS的工作与对我的数据中心的工作以及对运行Vagrant的开发机器的工作以及对我偶尔需要的演示环境的工作一样好。我宁愿从cloudinit启动Chef或Puppet，也不愿同时维护cloudinit和Chef或Puppet。
对于扔掉的服务器，说在自动伸缩组后面运行，我会说cloudinit可能就足够了。linux shell脚本或Windows powershell脚本应该可以解决问题。
如果您的服务器运行时间较长，那么您计划管理厨师，人偶或码头工人可能会给您带来好处，如公认的答案所述。如果使用它们后看不到优势，则可能不需要该工具。