什么要加入AWS AMI以及使用cloud-init进行配置？

Question

我正在使用AWS Cloudformation为我的Web应用程序设置网络基础结构的许多元素(VPC,安全组,子网,自动调节组等).我希望整个过程自动化.我想点击一个按钮,然后能够启动整个事情.

我已经成功创建了一个Cloudformation模板,用于设置所有这些网络基础架构.但是,EC2实例目前在没有任何所需软件的情况下启动.现在我想弄清楚如何最好地在他们身上获得该软件.

为此,我正在使用Packer.io创建AMI .但有些人反而催促我使用Cloud-Init.我应该使用什么启发式方法来决定将哪些内容融入AMI和/或通过Cloud-Init配置什么？

例如,我想预先配置EC2实例以允许me(saqib)在没有自己笔记本电脑密码的情况下登录.因此EC2必须有用户.该用户必须具有主目录.并且在该主目录中必须存在.ssh/known_hosts包含加密代码的文件.我应该将这些目录烘焙到AMI吗？或者我应该使用cloud-init来设置它们？我该如何决定这个和其他类似的案例呢？

Answer 1

我喜欢将机器配置与环境配置分开.

一般来说,我使用以下作为指南:

构建阶段

• 使用Packer之类的东西构建基本机器映像,包括运行应用程序所需的所有软件.从中创建一个AMI.
• 将应用程序安装到基本机器映像上,创建应用程序映像.标记和版本此工件.不要在这里嵌入特定于环境的东西,例如数据库连接等,因为这使您无法在不同的环境运行时间内轻松地重用此AMI.
• 确保停止所有服务

发布阶段

• 使用像CFN这样的东西来旋转由图像和下面所需的环境组成的环境.
• 使用云初始化user-data到配置的应用环境(数据库连接,日志代理等),然后启动应用程序/服务

这种方法具有最大的灵活性,可以清晰地分离出连续输送管道的各种问题.

Answer 2

决定您应该如何组装服务器、AMI 和基础设施规划的重要因素之一是回答以下问题：在生产中，我需要多快启动新实例？

这个问题的答案将决定您在 AMI 中加入多少与在启动后构建多少。

注意：我的经验是使用 Chef Server，因此我将使用 Chef 术语，但任何其他配置管理堆栈的概念都是相同的。

一般的经验法则是将您的“基础设施即代码”对待。这意味着考虑启动实例、在该机器上创建用户的过程，以及管理 known_hosts 文件和 SSH 密钥的过程，就像您的应用程序代码一样。能够在源代码中跟踪对基础架构的更改使管理、重新部署甚至 CI 变得更加容易。

此 Chef 简介涵盖了 Chef of Cookbooks、Recipes、Resources 等中的术语。它向您展示了如何构建一个简单的 LAMP 堆栈，以及如何使用一个命令轻松地重新启动它。

因此，鉴于您问题中的示例，在较高级别上，我会执行以下操作：

• 使用 Cloudformation 脚本启动基本的 Ubuntu Linux AMI（当前为 14.04）。
• 在实例配置的 UserData 部分，引导 Chef 客户端安装过程。
• 运行配方以创建用户。
• 运行 Recipe 为用户创建 known_hosts 文件

使用 Chef 之类的工具是因为您能够将基础架构分解为执行特定功能的小代码块。有许多已经构建和可用的Cookbook ，它们执行创建服务、安装软件包等的基本构建块。

尽管如此，有时您必须为了您的特定领域和要求而偏离最佳实践。在某些情况下，考虑到基础设施管理的所有优势，您仍然需要将项目烘焙到 AMI 中。

让我们假设您的应用程序进行图像处理并且需要使用 ImageMagick。假设您需要从源代码构建 ImageMagick。如果您要通过 Chef Recipes 执行此操作，这可能会将仅编译 ImageMagick 的另外 7 分钟添加到正常实例启动时间。如果等待 10-12 分钟对于新实例上线来说太长了，那么您可能需要考虑烘焙已经编译并安装了 ImageMagick 的自己的 AMI。

这是一个可接受的解决方案，但您应该记住，管理您自己的预烘焙 AMI 队列会增加额外的基础设施开销。您需要在新 AMI 发布时更新您的自定义 AMI，扩展到不同的实例类型和不同的 AWS 区域。