我们计划使用未经“预先烘焙”的AMI EC2实例。也就是说，当它们被启动时，它们是裸装的AWS Linux安装。我们的引导程序将拉取我们需要的各种安装，例如Python，Tomcat。我们将至少有3个实例和最多8个实例。
鉴于这些要求，与使用Amazon Cloud Formation（CloudInit）相比，使用Puppet / Chef是否有用?
我所能看到的最好的办法是，如果我们使用Puppet，那么我们将拥有易于审核以查看发生了什么的声明式编程，而不是脚本。此外，CloudInit有一个16k的脚本大小限制，可能会遇到或者可能不会遇到。
是否有人因为特定原因从CloudInit转移到Puppet或Chef，并可以在此回答我的问题?
CloudInit有优势吗？是的，绝对有很多！
当然，您可以编写一次性的CloudInit脚本来配置服务器。但是，当您需要更改配置文件、添加用户、更新软件包或安装新的软件包时会发生什么？您将不得不登录服务器或编写脚本来完成这些操作，并且最终会导致服务器状态不一致。
CloudInit不是配置管理。如果您选择开始使用配置管理软件，请只使用cloud init来引导Puppet/Chef/其他代理程序。
Puppet不仅可以帮助您自动安装软件包、设置ssh密钥或调整Tomcat堆栈，还可以确保事物的状态。当开发人员在凌晨3点调试Java应用程序并更改Tomcat配置时，Puppet会将其更改回来。您可以快速更改所有或一组节点的Python版本，如果有人安装了不同的版本，Puppet会将其更改回来。
当您的应用程序堆栈发生变化并开始使用例如RabbitMQ、Jetty或新的关系数据库管理系统时，您可以轻松测试和部署跨数十甚至数千个服务器的更改。
使用配置管理软件的其他原因包括后端报告、审核和安全合规性。
配置管理的整个目的是以可预测和一致的方式启动机器。当您仅限于使用AWS时，CloudFormation和cloudinit非常好用（尽管调试CloudFormation模板是一种痛苦的经历），但对于同时使用数据中心资源和AWS、本地测试环境或开发机器的应用程序来说呢？
如果您完全在AWS中存在，我想您可以只使用cloudinit而不需要其他任何东西，但我并不认为这对于任何规模的应用程序都是现实的（例如Netflix会使用他们编写并发布给世界的开源技术来预先制作他们的AMIs；请参考此视频了解详情）。高度可用的应用程序是跨区域的，通常基于VPC，并倾向于通过VPN备份到数据中心，甚至还涉及演示、暂存、测试或开发环境。作为负责提供机器的人，我最不想做的事情就是重复工作或陷入多个提供方法的调试中。
因此，Chef或Puppet。它们在AWS上和我的数据中心上同样有效，在运行Vagrant的开发机器上同样有效，对于我偶尔需要临时环境的演示环境也同样有效。我更愿意从cloudinit启动Chef或Puppet，而不是同时维护cloudinit和Chef或Puppet。如果是一些临时服务器，比如在自动扩展组后运行的服务器，我认为cloudinit可能已经足够了。Linux shell脚本或Windows PowerShell脚本应该可以完成任务。
如果您计划管理长时间运行的服务器，那么像chef、puppet或docker可能会给您带来优势，正如接受答案中所提到的那样。如果您在使用它们后看不到任何优势，那么您可能不需要这个工具。
