Amazon服务器升级

Question

我的公司需要将我们的EC2实例的操作系统从AML 1升级到AML 2，因为寿命是6/2023。我们最近对我们的应用程序发布了一个非常大的附加组件，所以我们也在讨论如何升级实例类型.我们当前的实例大小是m3，最近我们看到了一些延迟。为了澄清这一点，我们需要在生产环境上进行OS升级和实例类型升级。

当我试图找出解决这个问题的最佳方法时，我很好奇是否有办法挽救我们目前的服务器。我们的一个管理员将看到用我们当前的实例升级操作系统，这样我们就不必完全重建我们的基础设施了。我们在较低的环境中使用黄金映像，当涉及到服务器上较低级别的下载/配置时，将该映像从dev服务器部署到生产。我有几个问题，试图确定改善我们的基础设施的最佳行动方针。

在不同的环境中部署映像的依赖是什么？是操作系统吗？是实例类型吗？在所有环境中需要匹配什么才能在所有环境中使用该映像？

如果我的生产实例类型大于我的低环境实例类型，这对将映像从低环境部署到高级环境有任何影响吗？

是否可以在当前实例上升级操作系统，然后获得更大的生产实例类型，升级DEV环境操作系统，使用该映像并部署到上层环境？

它甚至有可能升级亚马逊ec2实例的操作系统，而不必完全重建服务器？

谢谢。

Answer 1

我并没有经常使用Amazon，但在我使用的其他发行版AMIs中，AWS在不同的地区维护了不同的映像(AMIs)。映像中可能有特定于本地区域的配置(在其他区域不能很好地工作)，或者AWS不希望通过从另一个区域读取映像来减缓EC2服务器的启动--我不知道。

但结果是，不同地区需要不同的非盟驻苏特派团。我通常在使用它们的每个区域构建我的自定义AMI，尽管我看到一个定制AMI复制到不同的区域，并用于在那里启动服务器。我的构建步骤对于不同的区域没有什么不同，只是原始源AMI是该区域的一个，它们是在该区域启动的EC2服务器上执行的。

我使用哈什科普封隔器来构建自定义AMI，尽管AWS现在似乎有一个定制的AMI构建器服务，并且始终有从EC2服务器创建AMI的特性。

在我工作过的工作中，操作系统在低非生产环境和高生产环境之间通常没有区别。我的机器使用不同AMI的唯一情况是，如果较低的环境位于不同的AWS帐户或AWS区域而不是更高的AWS区域，但是AMI是从相同的源映像构建的，并且配置有相同的自动脚本。

我的映像没有不同的原因是因为服务器的功能(web服务器、db服务器等)的主要定制。来自配置管理工具(傀儡、主厨、Ansible、Salt堆栈等)。有些团队更喜欢删除配置管理层，而不是自定义映像。这可能使高环境的图像不同于低环境的图像。这两种方法各有优缺点。

在AWS上，有各种各样的实例类型/大小可用于HVM映像，而对于PV映像则不多。这意味着您可以构建一个HVM映像，并使用它来启动非常小的、非常大的机器，并在两者之间进行广泛的操作。您不必为不同的实例类型维护不同的图像。

如果将定制添加到特定于实例类型的映像中，则可能会出现问题，但我使用过的核心Linux映像没有问题。除非AWS对此有警告，否则我相信Linux2也不会有任何麻烦。

至于将Linux1升级到EC2服务器上的Linux2，我不记得这是否可能。AWS文档会告诉你。