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

Question

我正在使用AWS Cloudformation为我的Web应用程序设置网络基础架构的许多元素（VPC，安全组，子网，自动扩展组等）。我希望整个过程自动化。我想点击一个按钮，然后能够启动整个事情。

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

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

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

Answer 1

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

一般来说，我使用以下内容作为指南：

构建阶段

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

发布阶段

• 使用像CFN这样的东西来旋转由所需的图像和红外线组成的环境。
• 使用Cloud-Init user-data 配置应用程序环境（数据库连接，日志转发器等），然后启动应用程序/服务

这种方法具有最大的灵活性，可以清晰地分离出连续交付管道的各种问题。

Answer 2

决定如何组装服务器，AMI和基础架构规划的一个重要因素是回答这个问题：在生产中，我需要多快才能启动新实例？

这个问题的答案将决定你加入AMI的程度与你在开机后的数量之间的关系。

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

一般的经验法则是将您的“基础设施视为代码”。这意味着要考虑启动实例，在该计算机上创建用户以及管理known_hosts文件和SSH密钥的过程与应用程序代码相同。能够在源代码中跟踪基础架构的更改，使管理更容易，重新部署甚至CI更容易。

This Chef Introduction涵盖了Cookbook，Recipes，Resources等主厨的术语。它向您展示了如何构建一个简单的LAMP堆栈，以及如何使用一个命令轻松地重新启动它。

所以在你的问题中给出了一个例子，在高级别我会做以下事情：

• 使用Cloudformation脚本启动基础Ubuntu Linux AMI（目前为14.04）。
• 在Instance配置的UserData部分中，引导Chef Client Install过程。
• 运行配方以创建用户。
• 运行配方以为用户创建known_hosts文件

使用像Chef这样的工具，因为您可以将基础架构分解为执行特定功能的小块代码。已经有许多Cookbook built and available执行创建服务，安装软件包等的基本构建块。

所有这一切，有时您必须为了特定领域和要求而偏离最佳实践。在某些情况下，如果基础架构管理具有所有优势，您仍需要将项目烘焙到AMI中。

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

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