我的公司需要将 EC2 实例的操作系统从 AML 1 升级到 AML 2，因为生命周期终止日期为 6/2023。我们最近向我们的应用程序发布了一个非常大的附加组件，因此我们也在讨论升级实例类型...我们当前的实例大小是 m3.large，并且最近我们看到了一些延迟。需要澄清的是，我们需要操作系统升级以及生产环境上的实例类型升级。
在试图找出解决此问题的最佳方法时，我很好奇是否有办法挽救我们当前的服务器。我们的一位管理员将了解如何使用我们当前的实例升级操作系统，这样我们就不必完全重建我们的基础设施。我们为较低环境使用黄金映像，并在服务器上进行较低级别的下载/配置时将该映像从开发服务器部署到生产环境。我有几个问题试图确定升级我们的基础设施的最佳行动方案。
在不同环境中部署镜像有什么依赖关系？是操作系统吗？是实例类型吗？为了能够在所有环境中使用该映像，所有环境之间需要匹配什么？
如果我的生产实例类型大于较低环境实例类型，这是否会对将映像从较低环境部署到较高环境产生影响？
是否可以升级我当前实例上的操作系统，然后获取更大的生产实例类型，升级 DEV 环境操作系统，使用该映像并部署到上层环境？
是否有可能升级亚马逊 EC2 实例的操作系统而无需完全重建服务器？
谢谢。
答案1
我很少使用 Amazon Linux，但对于我使用过的其他发行版 AMI，AWS 在不同区域维护了不同的映像 (AMI)。映像中可能存在特定于本地区域的配置（并且在其他区域无法正常工作），或者 AWS 不希望通过从其他区域读取映像来减慢 EC2 服务器的启动 - 我不这样做我不知道。
但结果是不同的地区需要不同的AMI。我通常会在使用自定义 AMI 的每个区域中构建自定义 AMI，但我也见过将自定义 AMI 复制到不同区域并用于在那里启动 EC2 服务器。我的构建步骤对于不同的区域没有不同，只是原始源 AMI 是针对该区域的，并且它们是在该区域启动的 EC2 服务器上执行的。
我用过Hashcorp 的 Packer构建自定义 AMI，尽管 AWS 现在似乎有自定义 AMI 构建器服务，并且始终具有从 EC2 服务器创建 AMI 的功能。
在我从事的工作中，较低的非生产环境和较高的生产环境之间的操作系统通常没有什么不同。我的计算机使用不同 AMI 的唯一情况是，较低环境与较高环境位于不同的 AWS 账户或 AWS 区域，但 AMI 是从相同的源映像构建的，并配置了相同的自动脚本。
我的图像没有不同的原因是因为服务器功能（Web 服务器、数据库服务器等）的主要自定义来自配置管理工具（Puppet、Chef、Ansible、Saltstack 等）。有些团队更喜欢删除配置管理层并自定义图像。这可能会使较高环境的图像与较低环境的图像不同。两种方法都有优点和缺点。
在 AWS 上，有多种可用于HVM映像的实例类型/大小，但可用于映像的实例类型/大小并不多PV。这意味着您可以构建一个HVM映像并使用它来启动非常小的机器、非常大的机器以及介于两者之间的各种机器。您不必为不同的实例类型维护不同的映像。
如果您向特定于实例类型的映像添加自定义，则可能会遇到问题，但我使用的核心 Linux 映像没有问题。除非AWS对此有警告，否则我相信Linux2也不会遇到任何麻烦。
至于在 EC2 服务器上将 Linux1 升级到 Linux2，我不记得这是否可能。 AWS 文档会告诉你。