EBS AMI 上的 MySQL 和持久性

Question

我正在尝试在支持 EBS 的 AMI 上安装 MySQL。

EBS 支持的 AMI 是指存储在 EBS 中而不是 S3 中的 AMI。

• 我选择了一个由 Amazon/Ubuntu 提供的现有 EBS 支持的 Ubuntu AMI，我启动它，对其进行自定义并创建一个新的 AMI，以满足我的特定需求。应该使用什么流程来创建这个新的 AMI？我是否应该小心任何公钥和 .SSH 文件夹（我这么说是因为我尝试过但无法登录）

• 一旦我有了新的 AMI ID，原始 EBS 的快照就会添加到卷列表中，这是新的自定义 AMI 所在的位置。从 AMI 列表中，我现在可以启动这个新的 AMI。 当我启动新创建的 AMI（自定义）时，快照大小（根卷大小）与原始 AMI 的根大小相同。我想增加这个大小以获得更多的存储空间。我该怎么做？

• 一旦我有足够的存储空间，我想在这个 AMI 上安装 MySQL。在此之后，我是否应该重新创建另一个新的 AMI 来保存这个新安装？还是会自动保存在根 EBS 卷中。

Answer 1

以下是与您描述的问题和情况相关的一些要点：

• 如果您要创建供其他人或公众使用的 AMI，那么您需要非常小心地处理涉及磁盘的任何信息。其他人甚至可以从已删除的文件中恢复信息。这是我写的一篇文章，涉及到这一点：http://alestic.com/2011/06/ec2-ami-security

• 如果您要创建一个 AMI 供您自己使用（而不是供其他人使用），那么您不必对敏感信息非常小心。请记住，您不能永远将曾经包含敏感信息的私有实例转换为公共 AMI。

• 您应该能够使用 ec2-create-image 命令或 AWS 控制台中的等效命令从正在运行的实例创建私有 AMI。新的 AMI 应该支持传入新的 ssh 密钥，并且（正如您所提到的）可能允许您使用创建 AMI 时放置的任何 ssh 密钥进行 ssh。

• EBS 启动 AMI 存储在 EBS 快照中。 EBS 快照存储在 S3 的幕后，但您无法通过标准 S3 API 访问它们。当您运行 EBS 启动 AMI 时，它会启动一个 EBS 启动实例，其中根磁盘是一个 EBS 卷（从 AMI 的 EBS 快照创建）。

• 您可以在运行实例时使用块设备映射参数来启动具有比 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 卷进行快照，尤其是那些包含数据的卷。

• 始终准确记录/自动化您如何启动新实例，包括软件安装和配置。将来能够重现这一点会派上用场，尤其是在某些紧急情况下。

我对你的问题思考得越多，我认为你可能越是认为你需要做一些你不需要做的事情。这是我的建议：

1. 启动一个 EBS 启动实例，并开始记录您在以下步骤中所做的一切。

2. 为 MySQL 和其他数据附加单独的 EBS 卷（请参阅上面的文章）。

3. 安装和自定义所有其他软件。

4. 为两个 EBS 卷设置常规 EBS 快照。

您可能不需要创建自定义 AMI，也可能不需要调整根磁盘的大小。

Answer 2

实际上，EBS ami 是指实例将从 EBS 卷而不是实例存储启动的 ami。无论如何，实际的 ami 都以相同的方式存储。

您确实需要注意 ami 中的数据 - 不要在其中留下任何您不希望 ami 的用户看到的内容。

当您启动 ami 时，其中一个选项是块设备映射。您可以使用它来增加引导设备的大小，添加额外的设备。请注意，这不会改变分区本身 - 你仍然需要运行 resize2fs 之类的东西来扩大分区（一些 Amis 已设置为你运行它）

对从 ami 启动的实例所做的任何更改都不会影响 ami 本身。