更好的是：在启动时配置实例或启动预先支持的映像？

Question

我正在开发一个云解决方案。我没有这方面的经验，所以我想向一些专业人士询问最佳实践。当前的问题主要与自动缩放组功能有关。

我阅读了很多操作指南和指南，并得出结论，在 ASG 中预配/配置实例的唯一方法是：

• 预烘焙 AMI；
• 使用 user_data 字段。

所以，假设我有一个自动缩放组。我想配置它启动的实例，例如，使用chef-solo（或ansible-local，但据我了解，厨师是aws的更好选择）。

我只看到了两种方法：

• 使用 packer 并在本地预烘焙映像（使用 chef-solo 提供程序），然后使用全新创建的 AMI 更新 ASG 配置；
• 使用基本 Amazon AMI 并在启动时配置映像，使用 user_data 脚本：安装 chef-solo，从 git 获取食谱，在机器上运行 chef-solo。

您认为什么是更好的选择，为什么？我还对如何在我的厨师食谱配置更改时更新 ASG 中已经运行的实例感兴趣。

另外，如果您知道更好的选择，请将它们留在这里。我愿意讨论。

Answer 1

这取决于您的用例。

在扩展时，预烘焙的 AMI 可能会更快启动，但如果您需要对代码或配置进行微小的更改，则需要烘焙另一个 AMI。如果您正在安装应用程序服务器和部署应用程序，使用用户数据（无论是使用直接的 OS 命令还是 Chef 或其他）可能需要更长的时间，并且您还可能会引入外部依赖项以进行扩展：如果 GitHub 存储库离线或必要的下载被阻止了？

因此，如果放大速度很重要，请考虑使用预烘焙 AMI。如果您可以容忍合理的扩大规模，请考虑采用混合方法：

• 将 Chef DK 和您需要的任何其他大型对象放入您的 AMI。例如，您可以将应用服务器安装烘焙到 AMI 中，然后让 Chef 通过用户数据对其进行配置。
• 确保您的依赖项、脚本和可部署文件（例如 WAR 文件）位于可靠的存储库（例如 S3）中。

最好的建议是尝试这两种方法来获取一些指标，看看它们如何适合您的用例。