构建自定义 AMI 时软件位置的最佳实践

Question

我一直在尝试使用 AWS，并了解 AMI、它们的运行方式以及如何构建它们。我很好奇这里是否有人对以下内容有任何想法：

构建一个 AMI 并在映像中预装所有所需软件，还是通过 EBS 提供该软件更好？我认为最好有一个集中位置来存放 apache 或 mysql 二进制文件之类的东西，假设您希望有多个 Web/数据库服务器可用，以便轻松启动。我比较老派，所以我想使用 EBS 为我的所有 AMI 构建一个看起来有点像 NFS 导出的 /usr/local 的东西。

这似乎是 EBS 的一个很好的用途 - 也是降低 AMI 大小的一种方式。但也许有理由不这样做。

Answer 1

您的问题似乎是一个经常出现的问题。

最终的答案似乎是每个人的环境都不同，有不同的要求等等。但是，以下是我进行的方式以及哪些有效/无效。

1. 使用 EBS 支持的实例，除非您确实永远不需要该实例，它可以使捆绑和数据传输等许多事情变得更加简单。

2. 假设您将使用相当静态的软件版本（即您不使用该软件的夜间最新版）在图像上安装软件但不安装配置。

3. 对配置进行版本控制，并在实例启动时更新这些配置。在 Linux 和 Windows 中，在启动时运行脚本、联系中央存储库并更新代码、配置等相当容易。这甚至可以扩展到启动新服务器，只需让它们从存储库中提取基本配置并就地修改即可。这使得管理较小的服务器更改变得更加容易，而无需重新捆绑所有内容并重新测试。

4. 将数据存储在附加的 EBS 卷上。在 Linux 上，主操作系统应该可以轻松放入默认的 8GB EBS 根卷中，并有足够的空间容纳一些简单的脚本等。大型代码集合、静态文件、数据库等应该放在 EBS 存储中。附加卷上存储的内容应该与服务器无关。例如。如果您有 3 个 Web 服务器，则连接到每个服务器的数据设备应该能够相同，并且不与特定实例绑定。这使得备份和故障恢复变得更加容易。

5. 除非您位于 VPC 中并且拥有静态内部 IP 地址，否则您应该设置私有 DNS 服务器，并在实例打开/关闭时使用脚本管理更新此服务器（以及安全组）。由于 EC2 和非静态 IP 的性质，各个服务器应尽可能避免引用这些 IP，因为它们每次启动时都会有所不同。

TL:DR AMI 应该只包含非特定于实例或大型数据集的信息，其余信息应被视为可改变的并进行相应的管理。