我正在尝试在EBS支持的AMI上安装MySQL。
EBS支持的AMI意味着，AMI存储在EBS而不是S3中。
我选择了由Amazon / Ubuntu提供的现有EBS支持的Ubuntu AMI，我启动它，定制它并创建一个特定于我需要的新AMI。应该使用什么过程来创建这个新的AMI？我应该小心任何公钥和.SSH文件夹（我说这是因为我试过这个并且无法登录）
获得新的AMI ID后，原始EBS的快照会添加到卷列表中，这是新的自定义AMI所在的位置。从AMI列表中，我现在可以启动这个新的AMI。 当我启动新创建的AMI（自定义）时，快照大小（根卷大小）与原始AMI的根大小相同。我想增加这个大小以获得更多的存储空间。我该怎么做？
一旦我有足够的存储空间，我想在这个AMI上安装MySQL。在此之后，我应该重新创建另一个新的AMI来保存这个新安装吗？或者这将自动保存在根EBS卷中。
答案 0 :(得分：2)
以下是与您描述的问题和情况相关的一些要点：
如果您正在创建供其他人或公众使用的AMI，那么您需要特别注意触及磁盘的任何信息。其他人通常可以从已删除的文件中恢复信息。这是我写的一篇文章，其中涉及到：http://alestic.com/2011/06/ec2-ami-security
如果您正在创建一个供自己专用的AMI（不能供其他人使用），那么您不必非常关注敏感信息。请记住，您永远不会将曾经包含敏感信息的私有实例转变为公共AMI。
您应该能够使用ec2-create-image命令或AWS控制台中的等效命令从正在运行的实例创建私有AMI。新的AMI应支持传入新的ssh密钥，并且（正如您所提到的）可能允许您使用创建AMI时放置的任何ssh密钥。
EBS启动AMI存储在EBS快照中。 EBS快照存储在S3的幕后，但不能通过标准S3 API访问它们。当您运行EBS引导AMI时，它会启动EBS引导实例，其中根磁盘是EBS卷（从AMI的EBS快照创建）。
运行时，可以使用block-device-mapping参数启动比AMI指定的引导磁盘更大的实例。这是我写的一篇文章，解释了这一点：http://alestic.com/2009/12/ec2-ebs-boot-resize
您可以通过停止它来更改已经运行的实例的根磁盘大小，用更大的副本替换EBS卷，然后重新启动它。我在此处提供了示例步骤：http://alestic.com/2010/02/ec2-resize-running-ebs-root
我建议将MySQL数据库文件分离到单独的数据EBS卷上。我写了一篇文章，描述了执行此操作的步骤：http://aws.amazon.com/articles/1663
如果您使用单独的数据EBS卷，则可能不需要调整根EBS卷的大小。
无论您使用一个还是两个EBS卷，无论您是否创建新的AMI，都会保留卷及其上安装的软件和数据。实际上，创建一个包含完整数据库的AMI有点奇怪，因为数据库中的信息将很快变得陈旧。也就是说，您应定期对EBS卷进行快照，尤其是包含数据的卷。
始终记录/自动完成启动新实例的方式，包括软件安装和配置。能够在将来重现这一点将会派上用场，特别是在某些紧急情况下。
我越是想到你的问题，我越想你可能认为你需要做你不需要做的事情。这是我的建议：
启动EBS启动实例，并开始记录您在以下步骤中执行的所有操作。
为MySQL和其他数据附加单独的EBS卷（参见上文）。
安装并自定义所有其他软件。
为两个EBS卷设置常规EBS快照。
您可能不需要创建自定义AMI，也可能不需要调整根磁盘的大小。
答案 1 :(得分：0)
实际上，EBS ami表示实例将从EBS卷而不是实例存储引导的ami。无论如何，实际的ami都以相同的方式存储。
你确实要小心ami中的数据 - 不要在那里留下任何你不希望ami的用户看到的东西。
当您启动ami时，其中一个选项是块设备映射。您可以使用它来增加引导设备的大小，添加额外的设备。请注意，这不会更改分区本身 - 您仍然需要运行resize2fs之类的东西来增长分区（一些Amis设置为为您运行）
对从ami开始的实例所做的任何更改都不会对ami本身产生任何影响。