构建自定义非盟特派团中软件位置的最佳实践

Question

我一直在用AWS做实验，学习有关AMIs的知识，它们是如何运行的，以及如何构建它们。我很好奇这里是否有人对以下几点有任何想法：

用映像中预先安装的所有所需软件构建AMI，还是通过EBS提供该软件？我在想，如果您希望多个web/数据库服务器可以轻松地打开，那么最好为apache或mysql二进制文件设置一个中心位置。我已经够老的了，所以我想用EBS来构建一个看起来有点像NFS导出/usr/本地的东西给我所有的AMIs。

这似乎是对EBS的一种很好的利用，也是一种降低AMI大小的方法。但也许我们有理由不这么做。

Answer 1

你的问题似乎经常出现。

似乎最终的答案是每个人的环境是不同的，有不同的要求等等。然而，下面是我是如何进行和什么已经/没有工作。

1. 使用EBS支持的实例，除非您真的不再需要实例，否则它会使捆绑和数据传输等许多事情变得更简单。
2. 假设您将使用相当静态的软件版本(即，您没有使用软件的夜间边缘版本)，则在映像上安装软件，而不是配置。
3. 版本控制您的配置，并在实例出现时更新这些配置。在linux和windows中，很容易在启动时运行脚本，联系中央存储库并更新代码、信任等。这甚至可以扩展到启动新服务器，让它们从存储库中提取基本配置并对其进行修改。这样就可以更容易地管理较小的服务器更改，而不必重新绑定所有内容并重新测试。
4. 将数据存储在附加的EBS卷上。在linux上，主操作系统应该很容易地安装到默认的8GB EBS根卷上，并为一些简单的脚本提供空间。诸如大型代码集合、静态文件、数据库等都应该放在EBS存储区。存储在附加卷上的内容应该与服务器无关。例如。如果您有3个web服务器，那么连接到每个服务器上的数据设备应该是相同的，而不是绑定到特定的实例。这使得从失败中进行备份和恢复更加容易。
5. 除非您在VPC中，并且具有静态内部IP地址，否则您应该设置一个私有DNS服务器，并在实例打开/关闭时让脚本管理更新此服务器(以及安全组)。由于EC2和非静态IP的性质，各个服务器应该尽可能避免引用它们，因为它们在每次启动时都会有所不同。

TL: AMIs博士应该只包含不特定于实例的信息或大的数据集，其余的应该被假定是可变的，并相应地进行管理。