chef-infra - 为什么人们将 Puppet/Chef 与 Amazon Cloud Formation 结合使用，而不是仅仅使用 CloudInit？

Question

我们计划使用非“预烘焙”的 AMI EC2 实例。 IE。当它们启动时，它们是 AWS linux 的裸安装。我们的引导过程将引入我们需要的各种安装，例如 python ，汤姆猫。我们的实例最少为 3 个，最多为 8 个。

考虑到这些要求，使用 Puppet/Chef 比使用 Amazon Cloud Formation (CloudInit) 有用吗？

我能想到的最好的结果是，如果我们使用 Puppet，那么我们将拥有声明式编程，与脚本相比，它更容易审核以查看发生的情况。此外，CloudInit 有 16k 脚本大小限制，我们可能会也可能不会遇到这一点。

是否有人出于特定原因从 CloudInit 迁移到 Puppet 或 Chef，他们可以在此处提供来回答我的问题？

Answer 1

与CloudInit相比有优势吗？是的，绝对有很多!

当然，您可以编写从上到下运行一次的 CloudInit 脚本来配置服务器。但是，当您需要更改配置文件、添加用户、更新软件包或安装新软件包时会发生什么？您最终将登录服务器或编写脚本来执行此操作，并且不可避免地会出现服务器状态不一致的情况。

CloudInit 不是配置管理。如果您选择开始使用配置管理软件，请使用 cloud init 仅执行一项任务:引导 Puppet/Chef/其他代理。

Puppet 不仅可以帮助您自动安装软件包、设置 ssh key 或调整 Tomcat 堆。它确保事物的状态。当开发人员在凌晨 3 点对 Java 应用程序进行故障排除并更改 Tomcat 配置时，Puppet 会将其更改回来。您可以快速更改所有节点或节点组的 Python 版本，如果有人安装了不同的版本，Puppet 会将其更改回来。

当您的应用程序堆栈发生变化并且您开始使用 RabbitMQ、Jetty 或新的 RDBMS 时，您可以轻松地在数十或数千台服务器上测试和部署更改。

使用配置管理软件还有很多其他原因，例如后端报告、审核和安全合规性。