本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
# 平台停用常见问题
**注意**
Elastic Beanstalk 于 2022 年 7 月 18 日停用了所有基于亚马逊 Linux AL1 AMI () 的平台分支。
本常见问题中的回答参考了以下主题：
+ [Elastic Beanstalk 平台支持策略](platforms-support-policy.md)
+ [已停用平台分支历史记录](platforms-schedule.md#platforms-support-policy.retired)
+ *AWS Elastic Beanstalk 平台*中[支持 Elastic Beanstalk 的平台](https://docs.aws.amazon.com/elasticbeanstalk/latest/platforms/platforms-supported.html)
+ [将 Elastic Beanstalk Linux 应用程序迁移到 Amazon Linux 2023 或 Amazon Linux 2](using-features.migration-al.md)
+ [亚马逊 Linux 2 FAQs](https://aws.amazon.com//amazon-linux-2/faqs/).
## 1. 平台分支的停用意味着什么？
在公布的平台分支停用日期之后，除非您已经拥有基于该平台分支的活动环境，否则您将无法再基于已停用的平台分支创建新环境。有关更多信息，请参阅[常见问题 11](#using-features.migration-al.FAQ.new-env-create)。Elastic Beanstalk 将停止为这些平台分支提供新的维护更新。建议不要在生产环境中使用已停用的平台分支。有关更多信息，请参阅[常见问题 5](#using-features.migration-al.FAQ.remove-components)。
## 2. 为什么 AWS 停用了 AL1基于平台的分支？
当平台组件被其供应商弃用或停用时，Elastic Beanstalk 将停用平台分支。在本例中，亚马逊 Linux AMI (AL1) 已于 [2020 年 12 月 31 日](https://aws.amazon.com/blogs/aws/update-on-amazon-linux-ami-end-of-life/)终止标准支持。尽管 Elastic Beanstalk 在 2022 年之前 AL1 继续提供基于平台的同时，我们 AL2 已经 AL2023 发布了具有最新功能的基于和的平台。为了让客户继续从未来最新的安全性和功能中受益，客户迁移到我们 AL2 或 AL2023 基于我们的平台至关重要。
## 3. 哪些平台分支已停用？
有关已停用的平台组件和平台分支的列表，请参阅 [已停用平台分支历史记录](platforms-schedule.md#platforms-support-policy.retired)。
## 4. 目前支持哪些平台？
请参阅 *AWS Elastic Beanstalk 平台*中[支持 Elastic Beanstalk 的平台](https://docs.aws.amazon.com/elasticbeanstalk/latest/platforms/platforms-supported.html)。
## 5. Elastic Beanstalk 是否会在停用后移除或终止我的环境中的任何组件？
我们针对已停用平台分支的政策不会撤销对环境或已删除资源的访问权限。但是，由于供应商将其组件标记为寿命终止 (EOL)，Elastic Beanstalk 无法为已停用平台分支提供安全更新、技术支持或修补程序，因此基于已停用平台分支的环境最终可能会陷入无法预测的境地。例如，在已停用平台分支上运行的环境中，可能会出现有害且关键的安全漏洞。或者，如果环境随着时间推移变得与 Elastic Beanstalk 服务不兼容，则 EB API 操作可能会不再适用于该环境。基于已停用平台分支的环境保持活动状态的时间越长，出现这些类型风险的几率就越高。
如果您的应用程序在已停用的平台分支上运行时遇到问题并且您无法将其迁移到受支持的平台，则需要考虑其他替代方案。解决方法包括将该应用程序封装到 Docker 映像中，以便将其以 Docker 容器的形式运行。这将允许客户使用我们的任何 Docker 解决方案，例如我们的 Elastic AL2 Beanstalk/Docker 平台，或者其他基于 Docker 的服务，例如亚马逊 AL2023 ECS 或 Amazon EKS。非 Docker 替代方案包括我们的 AWS CodeDeploy 服务，它允许您完全自定义所需的运行时。
## 6. 我是否可以提交推迟停用日期的请求？
不可以。在停用日期后，现有环境将继续正常运行。只不过，Elastic Beanstalk 不会再提供平台维护和安全更新。因此，迁移到基于平台的平台 AL2 或者您 AL2023 是否仍在 AL1基于平台上运行应用程序至关重要。有关风险和解决方法的更多信息，请参阅[常见问题 5](#using-features.migration-al.FAQ.remove-components)。
## 7. 如果我无法及时完成 AL2 或 AL2023 迁移，有哪些解决方法？
客户可以继续运行该环境，但我们强烈建议您制定计划将所有 Elastic Beanstalk 环境迁移到受支持的平台版本。这样做可将风险降至最低，并持续受益于更新的版本中提供的重要安全性、性能和功能增强。有关风险和解决方法的更多信息，请参阅[常见问题 5](#using-features.migration-al.FAQ.remove-components)。
## 8. 迁移到 AL2 我们的 AL2023 平台的推荐流程是什么？
有关AL2 迁移 AL1 到 AL2023 /的全面说明，请参阅[将 Elastic Beanstalk Linux 应用程序迁移到 Amazon Linux 2023 或 Amazon Linux 2](using-features.migration-al.md)。本主题解释了 Elastic Beanstalk blue/green 需要部署才能执行升级。
## 9. 如果我有在已停用平台上运行的环境，会有什么影响？
由于供应商将其组件标记为寿命终止 (EOL)，Elastic Beanstalk 无法为已停用平台分支提供安全更新、技术支持或修补程序，因此基于已停用平台分支的环境最终可能会陷入无法预测的境地。例如，在已停用平台分支上运行的环境中，可能会出现有害且关键的安全漏洞。或者，如果环境随着时间推移变得与 Elastic Beanstalk 服务不兼容，则 EB API 操作可能会不再适用于该环境。已停用平台分支上的环境保持活动状态的时间越长，出现这些类型风险的几率就越高。有关更多信息，请参阅[常见问题 5](#using-features.migration-al.FAQ.remove-components)。
## 10. 停用日期后 90 天会发生什么情况？
我们针对已停用平台分支的政策不会撤销对环境或已删除资源的访问权限。但请注意，由于供应商将其组件标记为寿命终止 (EOL)，Elastic Beanstalk 无法为已停用平台分支提供安全更新、技术支持或修补程序，因此基于已停用平台分支的环境最终可能会陷入无法预测的境地。例如，在已停用平台分支上运行的环境中，可能会出现有害且关键的安全漏洞。或者，如果环境随着时间推移变得与 Elastic Beanstalk 服务不兼容，则 EB API 操作可能会不再适用于该环境。已停用平台分支上的环境保持活动状态的时间越长，出现这些类型风险的几率就越高。有关更多信息，请参阅[常见问题 5](#using-features.migration-al.FAQ.remove-components)。
## 11. 我是否可以基于已停用平台创建新环境？
如果您曾使用已停用平台分支使用同一账户并在同一区域创建了现有环境，则您可以基于该平台分支创建新环境。已停用的平台分支将不会在 Elastic Beanstalk 控制台中提供。但是，对于拥有基于已停用平台分支的现有环境的客户，它可通过 EB CLI、EB API 和 AWS CLI使用。此外，现有客户可以使用 [Clone environment](using-features.managing.clone.md)（克隆环境）和 [Rebuild environment](environment-management-rebuild.md)（重建环境）控制台。但请注意，基于已停用平台分支的环境最终可能会陷入无法预测的境地。有关更多信息，请参阅[常见问题 5](#using-features.migration-al.FAQ.remove-components)。
## 12. 如果我有一个现有环境在已停用平台分支上运行，那么我什么时候可以基于已应用平台分支创建新环境？ 我是否可以使用控制台、CLI 或 API 执行此操作？
您可以在停用日期之后创建环境。但请记住，已停用平台分支最终可能会陷入无法预测的境地。此类环境创建或处于活动状态的时间越长，该环境遇到意外问题的风险就越高。有关创建新环境的更多信息，请参阅[常见问题 11](#using-features.migration-al.FAQ.new-env-create)。
## 13. 我是否可以克隆或重建基于已停用平台的环境？
可以。您可以使用 [Clone environment](using-features.managing.clone.md)（克隆环境）和 [Rebuild environment](environment-management-rebuild.md)（重建环境）控制台执行此操作。您还可以使用 EB CLI、EB API 和 AWS CLI。有关创建新环境的更多信息，请参阅[常见问题 11](#using-features.migration-al.FAQ.new-env-create)。
但我们强烈建议您制定计划将所有 Elastic Beanstalk 环境迁移到受支持的平台版本。这样做可将风险降至最低，并持续受益于更新的版本中提供的重要安全性、性能和功能增强。有关风险和解决方法的更多信息，请参阅[常见问题 5](#using-features.migration-al.FAQ.remove-components)。
## 14. 在停用日期之后，基于已停用平台分支的 Elastic Beanstalk 环境的 AWS 资源会发生什么变化？ 例如，如果正在运行的 EC2 实例被终止，Elastic Beanstalk 能否启动基于 AL1 的新 EC2 实例来维持容量？
该环境的资源将保持活动状态，并继续正常运行。而且，是的，Elastic Beanstalk 将为该环境中的 AL1 EC2 实例自动扩展。但是，Elastic Beanstalk 将停止向该环境提供新的平台维护更新，这可能会导致该环境随着时间推移而陷入无法预测的境地。有关更多信息，请参阅[常见问题 5](#using-features.migration-al.FAQ.remove-components)。
## 15. AL2023/AL2 和 Amazon Linux AMI (AL1) 操作系统之间有哪些主要区别？ Elastic B AL2 eanstalk AL2023 /平台分支受到什么影响？
尽管 Amazon Linux AMI 和 AL2023/AL2 共享相同的 Linux 内核，但它们的初始化系统、`libc`版本、编译器工具链和各种软件包各不相同。有关更多信息，请参阅[亚马逊 Linux 2 FAQs](https://aws.amazon.com//amazon-linux-2/faqs/)。
Elastic Beanstalk 服务还更新了特定于平台的运行时版本、构建工具和其他依赖项。不能保证AL2 基于 AL2023 /的平台分支与您现有的应用程序向后兼容。此外，即使您的应用程序代码成功部署到新平台版本，其行为和性能也可能会因操作系统和运行时而异。有关您需要查看及测试的配置及自定义项的列表和描述，请参阅 [将 Elastic Beanstalk Linux 应用程序迁移到 Amazon Linux 2023 或 Amazon Linux 2](using-features.migration-al.md)。