本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

# 更新 Elastic Beanstalk 环境的平台版本
<a name="using-features.platform.upgrade"></a>

Elastic Beanstalk 定期发布新平台版本以更新所有基于 Linux 和 Windows Server 的[平台](concepts.platforms.md)。新平台版本提供对现有软件组件的更新，并支持新功能和配置选项。要了解有关平台和平台版本的信息，请参阅[Elastic Beanstalk 平台词汇表](platforms-glossary.md)。

您可以使用 Elastic Beanstalk 控制台或 EB CLI 更新环境的平台版本。根据您要更新的平台版本，Elastic Beanstalk 建议使用以下两种方法之一来执行平台更新。
+ [方法 1 - 更新环境的平台版本](#using-features.platform.upgrade.config)。当您更新到平台分支中的最新平台版本（具有相同的运行时、Web 服务器、应用程序服务器和操作系统，但不更改主要平台版本）时，我们建议使用此方法。这是最常见的常规平台更新。
+ [方法 2-执行部 Blue/Green 署](#using-features.platform.upgrade.bluegreen)。当您更新到其他平台分支中的平台版本（具有不同的运行时、Web 服务器、应用程序服务器或操作系统版本）或更新到其他主要平台版本时，我们建议使用此方法。当您想要利用新的运行时功能或最新的 Elastic Beanstalk 功能时，或者当您想要脱离弃用或停用的平台分支时，这是一种很好的方法。

  [从旧平台版本迁移](using-features.migration.md)需要进行 blue/green 部署，因为这些平台版本与当前支持的版本不兼容。

  将 [Linux 应用程序迁移到亚马逊 Linux 2](using-features.migration-al.md) 需要进行 blue/green 部署，因为亚马逊 Linux 2 平台版本与之前的亚马逊 Linux AMI 平台版本不兼容。

有关选择最佳平台更新方法的更多帮助，请展开适用于您的环境平台的部分。

## Docker
<a name="using-features.platform.upgrade.docker-single"></a>

使用[方法 1](#using-features.platform.upgrade.config) 执行平台更新。

## 多容器 Docker
<a name="using-features.platform.upgrade.docker-multi"></a>

使用[方法 1](#using-features.platform.upgrade.config) 执行平台更新。

## 预配置的 Docker
<a name="using-features.platform.upgrade.docker-preconfigured"></a>

请考虑以下情况：
+ 如果您要将应用程序迁移到另一个平台，例如从 *Go 1.4 (Docker)* 迁移到 *Go 1.11* 或从 *Python 3.4 (Docker)* 迁移到 *Python 3.6*，请使用[方法 2](#using-features.platform.upgrade.bluegreen)。
+ 如果您要将应用程序迁移到其他 Docker 容器版本，例如从 *Glassfish 4.1 (Docker)* 迁移到 *Glassfish 5.0 (Docker)*，请使用[方法 2](#using-features.platform.upgrade.bluegreen)。
+ 如果您要更新到容器版本或主要版本没有变化的最新平台版本，请使用[方法 1](#using-features.platform.upgrade.config)。

## Go
<a name="using-features.platform.upgrade.go"></a>

使用[方法 1](#using-features.platform.upgrade.config) 执行平台更新。

## Java SE
<a name="using-features.platform.upgrade.java-se"></a>

请考虑以下情况：
+ 如果您要将应用程序迁移到其他 Java 运行时版本，例如从 *Java 7* 迁移到 *Java 8*，请使用[方法 2](#using-features.platform.upgrade.bluegreen)。
+ 如果您要更新到运行时版本没有变化的最新平台版本，请使用[方法 1](#using-features.platform.upgrade.config)。

## 使用 Tomcat 的 Java
<a name="using-features.platform.upgrade.java-tomcat"></a>

请考虑以下情况：
+ 如果您要将应用程序迁移到其他 Java 运行时版本或 Tomcat 应用程序服务器版本，例如从 *Java 7 with Tomcat 7* 迁移到 *Java 8 with Tomcat 8.5*，请使用[方法 2](#using-features.platform.upgrade.bluegreen)。
+ 如果您要跨主要 Java with Tomcat 平台版本（v1.x.x、v2.x.x 和 v3.x.x）迁移应用程序，请使用[方法 2](#using-features.platform.upgrade.bluegreen)。
+ 如果您要更新到运行时版本、应用程序服务器版本或主要版本没有变化的最新平台版本，请使用[方法 1](#using-features.platform.upgrade.config)。

## 使用 IIS 的 Windows Server 上的 .NET
<a name="using-features.platform.upgrade.dotnet"></a>

请考虑以下情况：
+ 如果您要将应用程序迁移到其他 Windows 操作系统版本，例如从 *Windows Server 2008 R2* 迁移到 *Windows Server 2016*，请使用[方法 2](#using-features.platform.upgrade.bluegreen)。
+ 如果您要跨主要 Windows Server 平台版本迁移应用程序，请参阅[从 Windows Server 平台更早的主要版本迁移](dotnet-v2migration.md#dotnet-v2migration.migration)，并使用[方法 2](#using-features.platform.upgrade.bluegreen)。
+ 如果您的应用程序当前运行在 Windows Server 平台 V2.x.x 上，并且您想要更新到最新的平台版本，请使用[方法 1](#using-features.platform.upgrade.config)。

**注意**  
v2 之前的 [Windows Server 平台版本](https://docs.aws.amazon.com/elasticbeanstalk/latest/platforms/platforms-supported.html#platforms-supported.net)未从语义上进行版本控制。您只能启动其中每个 Windows Server 主要平台版本的最新版本，在升级之后无法回退。

## Node.js
<a name="using-features.platform.upgrade.nodejs"></a>

使用[方法 2](#using-features.platform.upgrade.bluegreen) 执行平台更新。

## PHP
<a name="using-features.platform.upgrade.php"></a>

请考虑以下情况：
+ 如果您要将应用程序迁移到其他 Java 运行时版本，例如从 *PHP 5.6* 迁移到 *PHP 7.2*，请使用[方法 2](#using-features.platform.upgrade.bluegreen)。
+ 如果您要跨主要 PHP 平台版本（v1.x.x 和 v2.x.x）迁移应用程序，请使用[方法 2](#using-features.platform.upgrade.bluegreen)。
+ 如果您要更新到运行时版本或主要版本没有变化的最新平台版本，请使用[方法 1](#using-features.platform.upgrade.config)。

## Python
<a name="using-features.platform.upgrade.python"></a>

请考虑以下情况：
+ 如果您要将应用程序迁移到其他 Python 运行时版本，例如从 *Python 2.7* 迁移到 *Python 3.6*，请使用[方法 2](#using-features.platform.upgrade.bluegreen)。
+ 如果您要跨主要 Python 平台版本（v1.x.x 和 v2.x.x）迁移应用程序，请使用[方法 2](#using-features.platform.upgrade.bluegreen)。
+ 如果您要更新到运行时版本或主要版本没有变化的最新平台版本，请使用[方法 1](#using-features.platform.upgrade.config)。

## Ruby
<a name="using-features.platform.upgrade.ruby"></a>

请考虑以下情况：
+ 如果您要将应用程序迁移到其他 Ruby 运行时版本或应用程序服务器版本，例如从 *Ruby 2.3 with Puma* 迁移到 *Ruby 2.6 with Puma*，请使用[方法 2](#using-features.platform.upgrade.bluegreen)。
+ 如果您要跨主要 Ruby 平台版本（v1.x.x 和 v2.x.x）迁移应用程序，请使用[方法 2](#using-features.platform.upgrade.bluegreen)。
+ 如果您要更新到运行时版本、应用程序服务器版本或主要版本没有变化的最新平台版本，请使用[方法 1](#using-features.platform.upgrade.config)。

## 方法 1 - 更新环境的平台版本
<a name="using-features.platform.upgrade.config"></a>

使用此方法可更新到环境的平台分支的最新版本。如果您之前已使用旧平台版本创建环境，或已从旧版本升级环境，则您也可以使用此方法恢复到先前的平台版本，前提是它在同一平台分支中。

**更新环境的平台版本**

1. 打开 [Elastic Beanstalk](https://console.aws.amazon.com/elasticbeanstalk) 控制台，然后**在 “区域” 列表中，选择您**的。 AWS 区域

1. 在导航窗格中，选择 **Environments**（环境），然后从列表中选择环境的名称。

1. 在环境概述页面上的 **Platform (平台)** 下，选择 **Change (更改)**。  
![\[可用的更新的 Elastic Beanstalk 平台\]](http://docs.aws.amazon.com/zh_cn/elasticbeanstalk/latest/dg/images/environment-management-platform-change.png)

1. 在 **Update platform version (更新平台版本)** 对话框中，选择平台版本。将自动选择分支中的最新（推荐）平台版本。您可以更新到之前使用过的任何版本。  
![\[Elastic Beanstalk 更新平台版本确认\]](http://docs.aws.amazon.com/zh_cn/elasticbeanstalk/latest/dg/images/environment-management-update-platform-version.png)

1. 选择 **Save**。

为了进一步简化平台更新，Elastic Beanstalk 可以为您管理它们。在可配置的每周维护时段内，您可以配置环境自动应用次版本和修补版本更新。Elastic Beanstalk 在应用托管更新时，不会导致停机时间或容量减少，并且当运行在新版本实例上的应用程序未能通过运行状况检查时，会立即取消更新。有关详细信息，请参阅[托管平台更新](environment-platform-update-managed.md)。

## 方法 2-执行部 Blue/Green 署
<a name="using-features.platform.upgrade.bluegreen"></a>

使用此方法可更新到其他平台分支（具有不同的运行时、Web 服务器、应用程序服务器或操作系统版本）或更新到其他主要平台版本。当您想要利用新的运行时功能或最新的 Elastic Beanstalk 功能时，这通常是必需的。当您迁移出已弃用或已停用的平台分支时，也需要这样做。

当您跨主要平台版本或具有主要组件更新的平台版本进行迁移时，您的应用程序或其某些方面很可能无法在新平台版本上按预期运行，可能需要进行更改。

执行迁移前，请将本地开发计算机更新到较新的运行时版本以及您计划迁移到的平台的其他组件。验证应用程序是否仍按预期运行，并进行必要的代码修复和更改。然后使用以下最佳实践过程将环境安全地迁移到新平台版本。

**将环境迁移到具有主要更新的平台版本**

1. [创建新环境](using-features.environments.md)，使用新的目标平台版本，并将应用程序代码部署到其中。新环境应该在包含您要迁移的环境的 Elastic Beanstalk 应用程序中。此时不要终止现有环境。

1. 使用新环境迁移应用程序。具体而言：
   + 查找并修复在开发阶段未发现的任何应用程序兼容性问题。
   + 确保应用程序使用[配置文件](ebextensions.md)进行的任何自定义都能够在新环境中正常运行。这些可能包括选项设置、其他已安装的包、自定义安全策略以及环境实例上安装的脚本或配置文件。
   + 如果您的应用程序使用自定义 Amazon Machine Image (AMI)，请基于新平台版本的 AMI 创建新的自定义 AMI。要了解更多信息，请参阅“[在 Elastic Beanstalk 环境中使用自定义亚马逊机器映像（AMI）](using-features.customenv.md)”。具体而言，如果您的应用程序使用具有自定义 AMI 的 Windows Server 平台，并且您打算迁移到 Windows Server V2 平台版本，则需要执行此操作。在这种情况下，另请参阅[从 Windows Server 平台更早的主要版本迁移](dotnet-v2migration.md#dotnet-v2migration.migration)。

   迭代测试并部署修复，直至对新环境上的应用程序满意。

1. 通过将新环境的 CNAME 与现有生产环境的 CNAME 交换，将新环境转换为生产环境。有关详细信息，请参阅[使用 Elastic Beanstalk 进行蓝/绿部署](using-features.CNAMESwap.md)。

1. 当您对处于生产模式的新环境状态感到满意之后，终止旧环境。有关详细信息，请参阅[终止 Elastic Beanstalk 环境](using-features.terminating.md)。

# 托管平台更新
<a name="environment-platform-update-managed"></a>

AWS Elastic Beanstalk 定期发布[平台更新](using-features.platform.upgrade.md)以提供修复、软件更新和新功能。利用托管平台更新，您可以将环境配置为在计划的[维护时段](#environment-platform-update-managed-window)内自动升级到最新版本的平台。您的应用程序在更新过程中会继续提供服务，并且不会减少容量。托管更新对于单一实例和负载均衡环境均适用。

**注意**  
在早于版本 2 (v2) 的 [Windows Server 平台版本](https://docs.aws.amazon.com/elasticbeanstalk/latest/platforms/platforms-supported.html#platforms-supported.net)上，此功能不可用。

您可以将环境配置为自动应用[修补版本更新](#environment-platform-update-managed-versioning)，或者同时应用修补版本更新和次版本更新。托管平台更新不支持跨平台分支的更新（对各种主要版本的平台组件（例如操作系统、运行时或 Elastic Beanstalk 组件）的更新），因为这些更新可能会引入无法向后兼容的更改。

您还可以将 Elastic Beanstalk 配置为在维护时段内替换环境中的所有实例，即使平台更新不可用也是如此。如果应用程序在长时间运行后遇到错误或内存问题，则替换环境中的所有实例会很有用。

在 2019 年 11 月 25 日或以后使用 Elastic Beanstalk 控制台创建的环境中，默认情况下，尽可能启用托管更新。托管更新需要启用[增强型运行状况](health-enhanced.md)。默认情况下，当您选择某种[配置预设](environments-create-wizard.md#environments-create-wizard-presets)时，将启用增强型运行状况，当您选择**自定义配置**时，将禁用增强型运行状况。控制台无法为不支持增强型运行状况的较旧平台版本启用托管更新，也无法在禁用增强型运行状况时启用托管更新。当控制台为新环境启用托管更新时，**每周更新时段**设置为一周中的任意一天的任意时间。**更新级别**设置为**次要版本和补丁**，并禁用**实例替换**。您可以在环境创建最终步骤之前禁用或重新配置托管更新。

对于现有环境，可以随时使用 Elastic Beanstalk 控制台配置托管平台更新。

**重要**  
一个 AWS 账户中如果有*大量* Beanstalk 环境，可能会在托管更新期间导致节流问题。*大量*是一个相对的量，取决于您为环境安排托管更新的紧密程度。一个账户中紧密安排的 200 多个环境可能会导致节流问题，但数量少也可能会出现问题。  
为了平衡托管更新的资源负载，我们建议您将环境的定期维护窗口分散到一个账户中。  
另外，可以考虑使用多账户策略。有关更多信息，请参阅*AWS 白皮书和指南*网站上的[使用多个账户组织 AWS 环境](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/organizing-your-aws-environment.html)。

**配置托管平台更新**

1. 打开 [Elastic Beanstalk](https://console.aws.amazon.com/elasticbeanstalk) 控制台，然后**在 “区域” 列表中，选择您**的。 AWS 区域

1. 在导航窗格中，选择 **Environments**（环境），然后从列表中选择环境的名称。

1. 在导航窗格中，选择 **Configuration (配置)**。

1. 在 **Managed updates (托管更新)** 类别中，选择 **Edit (编辑)**。

1. 禁用或启用**托管更新**。

1. 如果已启用托管更新，请选择维护时段，然后选择**更新级别**。

1. （可选）选择 **Instance replacement (实例替换)** 以启用每周实例替换。  
![\[修改托管更新配置页面\]](http://docs.aws.amazon.com/zh_cn/elasticbeanstalk/latest/dg/images/environment-platform-update-managed.png)

1. 要保存更改，请选择页面底部的 **Apply**（应用）。

托管平台更新依赖于[增强型运行状况报告](health-enhanced.md)来确定应用程序的运行状况足够良好并可认为平台更新成功。有关说明，请参阅[启用 Elastic Beanstalk 增强型运行状况报告](health-enhanced-enable.md)。

**Topics**
+ [执行托管平台更新所需的权限](#environment-platform-update-managed-perms)
+ [托管更新维护时段](#environment-platform-update-managed-window)
+ [次版本更新和修补版本更新](#environment-platform-update-managed-versioning)
+ [不可变的环境更新](#environment-platform-update-managed-immutable)
+ [管理托管更新](#environment-platform-update-managed-managing)
+ [托管的操作选项命名空间](#environment-platform-update-managed-namespace)

## 执行托管平台更新所需的权限
<a name="environment-platform-update-managed-perms"></a>

Elastic Beanstalk 需要代表您启动平台更新的权限。为了获得这些权限，Elastic Beanstalk 会代入*托管更新服务角色*。当您为环境使用默认[服务角色](iam-servicerole.md)时，Elastic Beanstalk 控制台也会将其用作托管更新服务角色。控制台将 [`AWSElasticBeanstalkManagedUpdatesCustomerRolePolicy`](iam-servicerole.md#iam-servicerole-update) 托管策略分配给您的服务角色。此策略具有 Elastic Beanstalk 执行托管平台更新所需的全部权限。

有关设置托管更新服务角色的其他方法的详细信息，请参阅[管理 Elastic Beanstalk 服务角色](iam-servicerole.md)。

**注意**  
如果您使用[配置文件](ebextensions.md)扩展环境以包含其他资源，则可能需要向环境的托管更新服务角色添加权限。通常，当您在其他部分或文件中按名称引用这些资源时，您需要添加权限。

如果更新失败，您可以在[托管更新](#environment-platform-update-managed-managing)页面上查找失败的原因。

## 托管更新维护时段
<a name="environment-platform-update-managed-window"></a>

在 AWS 发布环境平台的新版本时，Elastic Beanstalk 会计划在下一个每周维护时段内更新托管平台。维护时段的长度为 2 小时。Elastic Beanstalk 在维护时段内开始执行计划的更新。此更新在该时段结束前可能无法完成。

**注意**  
在大多数情况下，Elastic Beanstalk 计划在即将到来的每周维护时段内进行托管更新。在计划托管更新时，系统会考虑更新安全和服务可用性的各个方面。在极少数情况下，更新可能不会安排在第一个即将到来的维护时段。如果发生这种情况，系统会在下一个维护时段内再次尝试。要手动应用托管更新，请选择 **Apply now (立即应用)**，如此页面的[管理托管更新](#environment-platform-update-managed-managing)中所述。

## 次版本更新和修补版本更新
<a name="environment-platform-update-managed-versioning"></a>

您可以启用托管平台更新以仅应用修补版本更新或同时应用次版本更新和修补版本更新。修补版本更新提供错误修复和性能改进，并且会包含对实例中的软件、脚本和配置选项的次要配置更改。次版本更新提供对新的 Elastic Beanstalk 功能的支持。您无法应用主版本更新，这可能会做出无法与托管平台更新向后兼容的更改。

在平台版本号中，第二个数字为次更新版本，第三个数字为修补版本。例如，在平台版本 2.0.7 中，次版本为 0，修补版本为 7。

## 不可变的环境更新
<a name="environment-platform-update-managed-immutable"></a>

托管平台更新执行[不可变的环境更新](environmentmgmt-updates-immutable.md)以将环境升级到新的平台版本。不可变更新在更新您的环境时，在确认运行新版本的实例通过运行状况检查之前，不会禁用任何实例或修改您的环境。

在不可变更新中，Elastic Beanstalk 将部署与当前使用新平台版本运行的实例一样多的实例。新实例开始与运行旧版本的实例一起接受请求。如果一组新实例通过所有运行状况检查，则 Elastic Beanstalk 会终止旧的实例组，并且仅保留具有新版本的实例。

托管平台更新始终执行不可变更新，即使您在维护时段之外应用它们也是如此。如果您从 **Dashboard (控制面板)** 更改平台版本，则 Elastic Beanstalk 会应用您为配置更新选择的更新策略。

**警告**  
某些策略会在部署或更新期间替换所有实例。这会导致丢失所有累积的 [Amazon EC2 突发余额](https://docs.aws.amazon.com/AWSEC2/latest/DeveloperGuide/burstable-performance-instances.html)。这发生在以下情况下：  
已启用实例替换的托管平台更新
不可变更新
已启用不可变更新或流量拆分的部署

## 管理托管更新
<a name="environment-platform-update-managed-managing"></a>

Elastic Beanstalk 控制台在 **Managed updates overview (托管更新概述)** 页面上显示有关托管更新的详细信息。

**查看有关托管更新的信息（控制台）**

1. 打开 [Elastic Beanstalk](https://console.aws.amazon.com/elasticbeanstalk) 控制台，然后**在 “区域” 列表中，选择您**的。 AWS 区域

1. 在导航窗格中，选择 **Environments**（环境），然后从列表中选择环境的名称。

1. 选择 **Managed updates (托管更新)**。

**托管更新概览**部分提供了有关计划的和挂起的托管更新的信息。**History (历史记录)** 部分列出成功的更新和失败的尝试。

您可以选择立即应用计划的更新，而不是等待进入维护时段。

**立即应用托管平台更新（控制台）**

1. 打开 [Elastic Beanstalk](https://console.aws.amazon.com/elasticbeanstalk) 控制台，然后**在 “区域” 列表中，选择您**的。 AWS 区域

1. 在导航窗格中，选择 **Environments**（环境），然后从列表中选择环境的名称。

1. 选择 **Managed updates (托管更新)**。

1. 选择 **Apply now (立即应用)**。

1. 验证更新详细信息，然后选择 **Apply (应用)**。

在维护时段之外应用托管平台更新时，Elastic Beanstalk 会执行不可变更新。如果您从[控制面板](environments-dashboard.md)更新环境平台或使用其他客户端更新环境平台，Elastic Beanstalk 将使用您为[配置更改](environments-updating.md)选择的更新类型。

如果您没有计划的托管更新，则您的环境可能已运行最新版本。导致未计划更新的其他原因包括：
+ [次版本](#environment-platform-update-managed-versioning)更新可用，但您的环境已配置为仅自动应用修补版本更新。
+ 自发布更新后未扫描您的环境。Elastic Beanstalk 通常会每小时检查一次更新。
+ 更新正在挂起或已在进行中。

在维护时段开始时或在您选择**立即应用**时，计划的更新在执行之前将进入挂起状态。

## 托管的操作选项命名空间
<a name="environment-platform-update-managed-namespace"></a>

您可使用 `aws:elasticbeanstalk:managedactions` 和 `aws:elasticbeanstalk:managedactions:platformupdate` 命名空间中的[配置选项](command-options.md)启用和配置托管平台更新。

`ManagedActionsEnabled` 选项可启用托管平台更新。将此选项设置为 `true` 可启用托管平台更新，使用其他选项可配置更新行为。

`PreferredStartTime`用于以*day*:*hour*: *minute* 格式配置每周维护时段的开头。

将 `UpdateLevel` 设置为 `minor` 或 `patch` 可同时应用次版本更新和修补版本更新，或仅应用修补版本更新。

在启用托管平台更新时，您可以通过将 `InstanceRefreshEnabled` 选项设置为 `true` 来启用实例替换。在启用此设置时，Elastic Beanstalk 每周在您的环境中运行一次不可变更新，而不管是否有新平台版本可用。

以下示例[配置文件](ebextensions.md)为维护时段在每个星期二 9:00 AM UTC 开始的修补版本更新启用托管平台更新。

**Example .ebextensions/ .config managed-platform-update**  

```
option_settings:
  aws:elasticbeanstalk:managedactions:
    ManagedActionsEnabled: true
    PreferredStartTime: "Tue:09:00"
  aws:elasticbeanstalk:managedactions:platformupdate:
    UpdateLevel: patch
    InstanceRefreshEnabled: true
```

# 从传统平台版本迁移应用程序
<a name="using-features.migration"></a>

如果已部署使用传统平台版本的 Elastic Beanstalk 应用程序，您应当将应用程序迁移到使用非传统平台版本的新环境，以便使用新功能。如果您不确定是否正在使用传统平台版本运行您的应用程序，则您可以在 Elastic Beanstalk 控制台中进行核实。有关说明，请参阅[检查您使用的是否属于传统平台版本](#using-features.migration-proc)。

## 传统平台版本缺失什么新功能？
<a name="using-features.migration.missing"></a>

旧版平台不支持以下功能：
+ 配置文件，如[使用配置文件 (`.ebextensions`) 进行高级环境自定义](ebextensions.md)主题中所述
+ ELB 运行状况检查，如[基本运行状况报告](using-features.healthstatus.md)主题中所述
+ 实例配置文件，如[管理 Elastic Beanstalk 实例配置文件](iam-instanceprofile.md)主题中所述
+ VPCs，如[将 Elastic Beanstalk 和 Amazon VPC 结合使用](vpc.md)主题中所述
+ 数据套餐，如[将数据库添加到 Elastic Beanstalk 环境](using-features.managing.db.md)主题中所述
+ 工作线程套餐，如[Elastic Beanstalk 工作线程环境](concepts-worker.md)主题中所述
+ 单个实例环境，如[环境类型](using-features-managing-env-types.md)主题中所述
+ 标签，如[在 Elastic Beanstalk 环境中标记资源](using-features.tagging.md)主题中所述
+ 滚动更新，如[Elastic Beanstalk 滚动环境配置更新](using-features.rollingupdates.md)主题中所述

## 为什么某些平台版本标记为传统版本？
<a name="using-features.migration.why"></a>

一些较旧的平台版本不支持最新的 Elastic Beanstalk 功能。这些版本在 Elastic Beanstalk 控制台中的环境概述页面上标记为 **(legacy) ((传统))**。<a name="using-features.migration-proc"></a>

**检查您使用的是否属于传统平台版本**

1. 打开 [Elastic Beanstalk](https://console.aws.amazon.com/elasticbeanstalk) 控制台，然后**在 “区域” 列表中，选择您**的。 AWS 区域

1. 在导航窗格中，选择 **Environments**（环境），然后从列表中选择环境的名称。

1. 在环境概述页面上，查看 **Platform (平台)** 名称。

   如果您在平台名称旁边看到 **(legacy) ((传统))**字样，则应用程序使用的是传统平台版本。

**迁移应用程序**

1. 将应用程序部署到新环境。有关说明，请转到[创建 Elastic Beanstalk 环境](using-features.environments.md)。

1. 如果您有 Amazon RDS 数据库实例，请更新数据库安全组，以便访问新环境的 EC2 安全组。有关如何使用 AWS 管理控制台查找 EC2 安全组名称的说明，请参阅[EC2 安全组](using-features.managing.ec2.console.md#using-features.managing.ec2.securitygroups)。有关配置 EC2 安全组的详细信息，请转到 *Amazon Relational Database Service 用户指南* 中的[使用数据库安全组](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_WorkingWithSecurityGroups.html)的“向 Amazon EC2 安全组授予网络访问权限”部分。

1. 交换环境 URL。有关说明，请转到[使用 Elastic Beanstalk 进行蓝/绿部署](using-features.CNAMESwap.md)。

1. 终止旧环境。有关说明，请转到[终止 Elastic Beanstalk 环境](using-features.terminating.md)。

**注意**  
如果您使用 AWS Identity and Access Management (IAM)，则需要更新您的政策，使其包含 CloudFormation 和 Amazon RDS（如果适用）。有关更多信息，请参阅 [将 Elastic Beanstalk 与 AWS Identity and Access Management](AWSHowTo.iam.md)。

# 将 Elastic Beanstalk Linux 应用程序迁移到 Amazon Linux 2023 或 Amazon Linux 2
<a name="using-features.migration-al"></a>

本节介绍了如何使用以下迁移路径之一迁移应用程序。
+ 从 *Amazon Linux 2* 平台分支迁移到 *Amazon Linux 2023* 平台分支。
+ 从*亚马逊 Linux AMI (AL1)* 平台分支迁移到*亚马逊 Linux 2023*（推荐）或*亚马逊 Linux 2* 平台分支。

**Topics**
+ [从 Amazon Linux 2 迁移到 Amazon Linux 2023](using-features.migration-al.generic.from-al2.md)
+ [从 Amazon Linux AMI (AL1) 迁移到 o AL2 r AL2 023](using-features.migration-al.generic.from-al1.md)

# 从 Amazon Linux 2 迁移到 Amazon Linux 2023
<a name="using-features.migration-al.generic.from-al2"></a>

本主题提供了将您的应用程序从 Amazon Linux 2 平台分支迁移到 Amazon Linux 2023 平台分支的指南。

## 差异和兼容性
<a name="using-features.migration-al.generic.from-al2.differences"></a>

**在 Elastic Bean AL2 stalk 和 023 AL2 平台之间**  


Elastic Beanstalk Amazon Linux 2 和 Amazon Linux 2023 平台之间具有高度的兼容性。尽管还有一些差异需要注意：
+ **实例元数据服务版本 1 (IMDSv1)**-在 AL2 023 平台`true`上，[禁用IMDSv1](command-options-general.md#command-options-general-autoscalinglaunchconfiguration)选项设置默认为。默认设置在 AL2 平台`false`上。
+ **pkg-repo 实例工具** — 该[pkg-repo](custom-platforms-scripts.md#custom-platforms-scripts.pkg-repo)工具不适用于在 023 平台上 AL2运行的环境。但是，您仍然可以手动将软件包和操作系统更新应用到 AL2 023 实例。有关更多信息，请参阅 *Amazon Linux 2023 用户指南*中的[管理软件包和操作系统更新](https://docs.aws.amazon.com/linux/al2023/ug/managing-repos-os-updates.html)。
+ **Apache HTTPd 配置** — 适用于 AL2 023 平台的 Apache `httpd.conf` 文件有一些与以下平台不同的配置设置： AL2
  + 默认情况下，拒绝访问服务器的整个文件系统。这些设置在 Apache 网站[安全提示](https://httpd.apache.org/docs/2.4/misc/security_tips.html)页面上的*默认保护服务器文件*中进行了描述。
  + 拒绝访问所有目录`.htaccess`中的设置，但特别启用的目录除外。此设置在 Apache 网站[安全提示](https://httpd.apache.org/docs/2.4/misc/security_tips.html)页面上的*保护系统设置*中进行了描述。[Apache HTTP 服务器教程：.htaccess 文件](https://httpd.apache.org/docs/2.4/howto/htaccess.html)页面指出，此设置可能有助于提高性能。
  + 拒绝访问带有名称模式 `.ht*` 的文件。此设置阻止 Web 客户端查看 `.htaccess` 和 `.htpasswd` 文件。

  您可以更改您的环境的上述任何配置设置。有关更多信息，请参阅 [配置 Apache HTTPD](platforms-linux-extend.proxy.md#platforms-linux-extend.proxy.httpd)。
+ **多行环境变量支持** — AL2 023 平台支持 systemd 服务配置中的环境变量和密钥的多行值。Amazon Linux 2 平台不支持多行环境变量值。此增强功能允许您在 AL2 023 平台上使用多行密钥和配置值。有关使用环境变量和密钥的更多信息，请参阅[Amazon Linux 2 环境变量中的多行值](AWSHowTo.secrets.env-vars.md#AWSHowTo.secrets.multiline)。
+ **CloudWatch 自定义日志转发**-已弃用的 Log CloudWatch s 代理（`awslogs`软件包）在 AL2 023 平台上不可用。如果您有安装和使用已弃用`awslogs`代理的自定义日志转发配置，则在从 Amazon Linux 2 迁移到 AL2 023 时，必须更新配置文件以使用统一 CloudWatch 代理。有关更多信息，请参阅 [自定义日志文件流式传输](AWSHowTo.cloudwatchlogs.md#AWSHowTo.cloudwatchlogs.streaming.custom)。

**特定于平台的差异**

除了基本操作系统的差异外，Amazon Linux 2 和 AL2 023 运行时平台之间还存在平台特定的差异：
+ **.NET 平台分支** — 亚马逊 Linux 2 和 AL2 023 的.NET 平台分支策略有所不同。在 Amazon Linux 2 上，.NET Core 平台在单个平台分支中维护一个轮换窗口，其中包含.NET 主要版本。在 AL2 023 上，每个平台分支都固定到特定的.NET 主要版本（例如.NET 9、.NET 10）。

  如果您部署依赖于框架的应用程序（依赖于平台安装的.NET 运行时的应用程序），则必须选择与应用程序的目标.NET 版本相匹配的平台分支。如果您部署自包含的应用程序（捆绑自己的.NET 运行时的应用程序），则无论应用程序的.NET 版本如何，都可以使用任何 AL2 023 .NET 平台分支，因为您的应用程序不依赖于平台安装的运行时。有关更多信息，请参阅 [捆绑适用于 .NET Core on Linux Elastic Beanstalk 平台的应用程序](dotnet-linux-platform-bundle-app.md)。
+ **Node.js 版本选择** — 亚马逊 Linux 2 上的 Node.js 平台支持在应用程序`package.json`文件中指定 Node.js 版本。 AL2023 上的 Node.js 平台不支持此功能。您必须使用平台分支提供的默认 Node.js 版本。有关 Node.js 版本管理的更多信息，请参阅[配置您的应用程序对 Elastic Beanstalk 的依赖项](nodejs-platform-dependencies.md)。
+ **Ruby Puma 服务器版本** — 亚马逊 Linux 2 上的 Ruby 平台会忽略应用程序`Gemfile.lock`文件中指定的 Puma 版本，而是使用平台默认 Puma 版本。 AL2023 上的 Ruby 平台支持中指定的 Puma 版本（`Gemfile.lock`如果存在）。如果未指定版本，则平台将安装平台默认 Puma 版本。
+ **PHP 软件包的可用性** — 亚马逊 Linux 2 PHP 平台上提供的某些软件包在 AL2 023 PHP 平台上不可用：
  + *MySQL 客户端软件包* — `mysql` 和`mysql-devel`命令行客户端软件包未安装在 AL2 023 PHP 平台上。如果您的应用程序需要 MySQL 数据库连接，请使用两个平台上都提供的 PHP `mysqli` 或`pdo_mysql`扩展。
  + *Compass 和 Ruby 工具* — Compass CSS 框架支持的`ruby-devel`和`rubygems`软件包未安装在 AL2 023 PHP 平台上。指南针已被弃用。可以考虑使用现代 CSS 预处理工具作为替代工具。
+ **Go 版本控制工具** — Bazaar 版本控制系统 (`bzr`) 在 AL2 023 Go 平台上不可用。Bazaar 已被弃用，未包含在 AL2 023 软件包存储库中。改用 Git、Mercurial 或 Subversion 进行版本控制，所有这些都在 AL2 023 Go 平台上可用。

**在 Amazon Linux 操作系统之间**  
有关 Amazon Linux 2 和 Amazon Linux 2023 操作系统之间差异的详细信息，请参阅《Amazon Linux 2023 用户指南》**中的[比较 Amazon Linux 2 和 Amazon Linux 2023](https://docs.aws.amazon.com/linux/al2023/ug/compare-with-al2.html)。

有关 Amazon Linux 2023 的详细信息，请参阅《Amazon Linux 2023 用户指南》**中的[什么是 Amazon Linux 2023？](https://docs.aws.amazon.com/linux/al2023/ug/what-is-amazon-linux.html)。

## 一般迁移流程
<a name="using-features.migration-al.generic.from-al2.process"></a>

当你准备好进入生产环境时，Elastic Beanstalk blue/green 需要部署才能执行升级。以下是我们建议使用 blue/green 部署过程进行迁移的一般最佳实践步骤。

**准备对您的迁移进行测试**  
在部署应用程序并开始测试之前，请查看上一节 [差异和兼容性](#using-features.migration-al.generic.from-al2.differences) 中的信息。另请参阅《Amazon Linux 2023 用户指南》**中的[比较 Amazon Linux 2 与 Amazon Linux 2023](https://docs.aws.amazon.com/linux/al2023/ug/compare-with-al2.html) 一节中引用的参考。记下此内容中应用于或可能应用于您的应用程序和配置设置的特定信息。

**高级迁移步骤**

1. 创建基于 AL2 023 平台分支的新环境。

1. 将您的应用程序部署到目标 AL2 023 环境。

   在您通过测试和调整新环境进行迭代时，您的现有生产环境将保持活动状态且不受影响。

1. 在新环境中全面测试您的应用程序。

1. 当您的目标 AL2 023 环境准备好进入生产环境时，交换两个环境中的 CNAMEs 一个，将流量重定向到新的 AL2 023 环境。

**更详细的迁移步骤和最佳实践**  
有关更详细的 blue/green 部署过程，请参阅[使用 Elastic Beanstalk 进行蓝/绿部署](using-features.CNAMESwap.md)。

有关更具体的指导和详细的最佳实践步骤，请参阅[蓝/绿方法](using-features.platform.upgrade.md#using-features.platform.upgrade.bluegreen)。

## 可帮助您规划迁移的更多参考
<a name="using-features.migration-al.generic.from-al2.references"></a>

以下参考可以为规划迁移提供更多信息。
+ *AWS Elastic Beanstalk 平台*中[支持 Elastic Beanstalk 的平台](https://docs.aws.amazon.com/elasticbeanstalk/latest/platforms/platforms-supported.html)
+ [已停用平台分支历史记录](platforms-schedule.md#platforms-support-policy.retired)
+ [Elastic Beanstalk Linux 平台](platforms-linux.md)
+ [平台停用常见问题](using-features.migration-al.FAQ.md)

# 从 Amazon Linux AMI (AL1) 迁移到 o AL2 r AL2 023
<a name="using-features.migration-al.generic.from-al1"></a>

如果您的 Elastic Beanstalk 应用程序基于 Amazon Linux AMI 平台分支，请使用此部分了解如何将应用程序的环境迁移到 Amazon Linux 2 或 Amazon Linux 2023。上一代平台分支基于 [Amazon Linux AMI](https://aws.amazon.com/amazon-linux-ami/) 而建，但现已停用。

强烈建议您迁移到 Amazon Linux 2023，因为它比 Amazon Linux 2 更新。Amazon Linux 2 操作系统将在 Amazon Linux 2023 之前终止支持，因此，如果您迁移到 Amazon Linux 2023，则将受益于更长的支持时间。

值得注意的是，Elastic Beanstalk Amazon Linux 2 和 Amazon Linux 2023 平台之间具有高度的兼容性。尽管有些方面确实存在差异：实例元数据服务版本 1 (IMDSv1) 选项默认、对 pkg-repo 实例工具的支持以及某些 Apache 配置。 HTTPd 有关更多信息，请参阅 [Amazon Linux 2023](platforms-linux.md#platforms-linux.versions.al2023)。

## 差异和兼容性
<a name="using-features.migration-al.generic.from-al1.differences"></a>

AL2 基于 AL2 023/ 的平台分支不能保证与您的现有应用程序向后兼容。另外，同样重要的要注意，即使您的应用程序代码成功部署到新平台版本，其行为和性能也可能会因操作系统和运行时而异。

尽管 Amazon Linux AMI 和 AL2 023/ AL2 共享相同的 Linux 内核，但它们在以下方面有所不同：它们的初始化系统、`libc`版本、编译器工具链和各种软件包。有关更多信息，请参阅[亚马逊 Linux 2 FAQs](https://aws.amazon.com//amazon-linux-2/faqs/)。

Elastic Beanstalk 服务还更新了特定于平台的运行时版本、构建工具和其他依赖项。

因此，我们建议您花些时间在开发环境中彻底测试您的应用程序，并进行任何必要的调整。

## 一般迁移流程
<a name="using-features.migration-al.generic.from-al1.process"></a>

当你准备好进入生产环境时，Elastic Beanstalk blue/green 需要部署才能执行升级。以下是我们建议使用 blue/green 部署过程进行迁移的一般最佳实践步骤。

**准备对您的迁移进行测试**  
在部署应用程序并开始测试之前，请查看 [所有 Linux 平台的注意事项](#using-features.migration-al.generic) 中的信息，本主题后面将介绍这些信息。此外，请在以下 [平台特定注意事项](#using-features.migration-al.specific) 部分中查看适用于您的平台的信息。记下此内容中应用于或可能应用于您的应用程序和配置设置的特定信息。

**高级迁移步骤**

1. 创建基于 AL2 或 AL2 023 平台分支的新环境。我们建议您迁移到 AL2 023 平台分支。

1. 将您的应用程序部署到目标 AL2 023/ 环境AL2 。

   在您通过测试和调整新环境进行迭代时，您的现有生产环境将保持活动状态且不受影响。

1. 在新环境中全面测试您的应用程序。

1. 当您的目标 AL2 023/ AL2 环境准备好进入生产环境时，交换两个环境中的 CNAMEs 一个，将流量重定向到新环境。

**更详细的迁移步骤和最佳实践**  
有关更详细的 blue/green 部署过程，请参阅[使用 Elastic Beanstalk 进行蓝/绿部署](using-features.CNAMESwap.md)。

有关更具体的指导和详细的最佳实践步骤，请参阅[蓝/绿方法](using-features.platform.upgrade.md#using-features.platform.upgrade.bluegreen)。

## 可帮助您规划迁移的更多参考
<a name="using-features.migration-al.generic.from-al1.references"></a>

以下参考可以为规划迁移提供更多信息。
+ [比较 Amazon Linux 2 与 Amazon Linux 2023](https://docs.aws.amazon.com/linux/al2023/ug/compare-with-al2.html) *Amazon Linux 2023 用户指南*。
+  《Amazon Linux 2023 用户指南》**中的[什么是 Amazon Linux 2023？](https://docs.aws.amazon.com/linux/al2023/ug/what-is-amazon-linux.html)
+ *AWS Elastic Beanstalk 平台*中[支持 Elastic Beanstalk 的平台](https://docs.aws.amazon.com/elasticbeanstalk/latest/platforms/platforms-supported.html)
+ [已停用平台分支历史记录](platforms-schedule.md#platforms-support-policy.retired)
+ [Elastic Beanstalk Linux 平台](platforms-linux.md)
+ [平台停用常见问题](using-features.migration-al.FAQ.md)

## 所有 Linux 平台的注意事项
<a name="using-features.migration-al.generic"></a>

下表讨论了在计划将应用程序迁移到 AL2 023AL2/时应注意的注意事项。这些注意事项适用于任何 Elastic Beanstalk Linux 平台，而不管平台采用何种特定的编程语言或应用程序服务器。


|  **领域**  |  **更改和信息**  | 
| --- | --- | 
|  配置文件  |  在 AL2 023/ AL2 平台上，你可以像以前一样使用[配置文件](ebextensions.md)，所有部分的工作方式都是一样的。但是，某些特定设置的工作方式可能与早期 Amazon Linux AMI 平台上的工作方式不同。例如： [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/elasticbeanstalk/latest/dg/using-features.migration-al.generic.from-al1.html) 我们建议使用平台挂钩在环境实例上运行自定义代码。您仍可以在 `.ebextensions` 配置文件中使用命令和容器命令，但这并不简单。例如，在 YAML 文件中编写命令脚本可能非常繁琐且很难测试。 对于需要引用 AWS CloudFormation 资源的任何脚本，您仍需要使用 `.ebextensions` 配置文件。  | 
|  平台挂钩  |  AL2 platforms 引入了一种扩展环境平台的新方法，方法是将可执行文件添加到环境实例上的挂钩目录中。对于以前的 Linux 平台版本，您可能使用了[自定义平台挂钩](custom-platforms.md#custom-platform-hooks)。这些挂钩不是为托管平台设计的，因此不受支持，但在某些情况下使用可能会有效。在 AL2 023/ AL2 平台版本中，自定义平台挂钩不起作用。应当将所有挂钩迁移到新的平台挂钩。有关详细信息，请参阅 [平台挂钩](platforms-linux-extend.hooks.md)。  | 
|  支持的代理服务器  |  AL2023/ AL2 平台版本支持的反向代理服务器与其 Amazon Linux AMI 平台版本所支持的每个平台相同。除了 ECS 和 Docker 平台之外，所有 AL2 023/AL2; 平台版本都使用 nginx 作为其默认反向代理服务器。Tomcat、Node.js、PHP 和 Python 平台也支持将 Apache HTTPD 作为替代方案。所有平台都以一致的方式启用代理服务器配置，如本节所述。但是，配置代理服务器与其在 Amazon Linux AMI 上时略有不同。以下是所有平台的区别： [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/elasticbeanstalk/latest/dg/using-features.migration-al.generic.from-al1.html) 有关特定于平台的代理配置更改，请参阅[平台特定注意事项](#using-features.migration-al.specific)。有关 AL2 023/ AL2 平台上的代理配置的信息，请参见。[反向代理配置](platforms-linux-extend.proxy.md)  | 
|   代理配置更改   |  除了特定于每个平台的代理配置更改外，还有一些代理配置更改统一适用于所有平台。为了准确配置您的环境，请务必参考两者。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/elasticbeanstalk/latest/dg/using-features.migration-al.generic.from-al1.html)  | 
|  实例配置文件  |  AL2023/ AL2 平台需要配置实例配置文件。如果没有该配置文件，环境创建可能会暂时成功，但是当需要实例配置文件的操作开始失败时，该环境可能会在创建后很快出现错误。有关更多信息，请参阅 [管理 Elastic Beanstalk 实例配置文件](iam-instanceprofile.md)。  | 
|  增强型运行状况  |  AL2023/ AL2 平台版本默认启用增强生命值。如果您未使用 Elastic Beanstalk 控制台创建环境，则该功能是一种更改。无论平台版本如何，默认情况下，该控制台尽可能启用增强型运行状况。有关更多信息，请参阅 [Elastic Beanstalk 中的增强型运行状况报告和监控](health-enhanced.md)。  | 
|  自定义 AMI  |  如果您的环境使用[自定义 AMI](using-features.customenv.md)，请使用 Elastic Beanstalk AL2 023/ 平台AL2为您的新环境创建一个基于 023/ 的新 AMI。 AL2 AL2   | 
|  自定义平台  |   AL2023/ AL2 平台 AMIs 的托管版本不支持自定义平台。  | 

## 平台特定注意事项
<a name="using-features.migration-al.specific"></a>

本节讨论特定 Elastic Beanstalk Linux 平台特有的迁移注意事项。

### Docker
<a name="using-features.migration-al.specific.docker"></a>

基于亚马逊 Linux AMI (AL1) 的 Docker 平台分支系列包括三个平台分支。我们建议为每个平台分支制定一条不同的迁移路径。


|  **AL1 平台分支**  |  **迁移到 AL2 023/ 的路径 AL2**  | 
| --- | --- | 
|  **领域**  |  **更改和信息**  | 
| --- | --- | 
|  由在亚马逊 Linux 上运行的亚马逊 ECS 管理的多容器 Docker AMI () AL1  |   基于 ECS 的 Docker AL2 023/ 平台AL2 分支 *基于 ECS 的 Docker AL2 023/ AL2* 平台分支为在*多容*器 Docker 平台分支上运行的环境提供了直接的迁移路径。 AL1  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/elasticbeanstalk/latest/dg/using-features.migration-al.generic.from-al1.html) 有关将*多容器 Docker Amazon Linux* 平台分支上运行的应用程序迁移到在 * AL2023/ AL2 平台分支上运行的 Amazon ECS* 的更多信息，请参阅。[在亚马逊 Linux 2023 上将你的 Elastic Beanstalk 应用程序从 ECS 托管的多容器 Docker AL1 迁移到 ECS](migrate-to-ec2-AL2-platform.md)  | 
|  在亚马逊 Linux 上运行的 Docker AMI () AL1 运行亚马逊 Linux AMI 的预配置 Docker (Glassfish 5.0) () AL1  |   Docker 在 AL2 023/ 平台分支AL2 上运行 我们建议您将运行在基于*预配置的 Docker（Glassfish 5.0）或在亚马逊 Linux AMI ()* *上运行的 Docker 环境中的应用程序迁移到基于在亚马逊 Linux* *2 上运行的 Docker 或在 023 平台分支上运行**的 Docker* 的环境。AL1 AL2  如果您的环境基于*预配置 Docker (Glassfish 5.0)* 平台分支，请参阅 [将 GlassFish 应用程序部署到 Docker 平台：2023 年亚马逊 Linux 的迁移之路](create_deploy_dockerpreconfig.md#docker-glassfish-tutorial)。 下表列出了特定于平台分支 *Docker 在 AL2 0 AL2 23/ 上运行*的迁移信息。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/elasticbeanstalk/latest/dg/using-features.migration-al.generic.from-al1.html)  | 
|  存储  |  Elastic Beanstalk 将 Docker 配置为使用[存储驱动程序](https://docs.docker.com/storage/storagedriver/)来存储 Docker 映像和容器数据。在 Amazon Linux AMI 上，Elastic Beanstalk 使用[设备映射器存储驱动程序](https://docs.docker.com/storage/storagedriver/device-mapper-driver/)。为了提高性能，Elastic Beanstalk 预置了额外的 Amazon EBS 卷。在 AL2 023/ AL2 Docker 平台版本上，Elastic Beanstalk 使用 OverlayFS [存储驱动程序，在不再需要单独卷](https://docs.docker.com/storage/storagedriver/overlayfs-driver/)的情况下实现更好的性能。 对于 Amazon Linux AMI，如果您使用 `BlockDeviceMappings` 命名空间 `aws:autoscaling:launchconfiguration` 选项向 Docker 环境添加自定义存储卷，建议您同时添加 Elastic Beanstalk 预配置的 `/dev/xvdcz` Amazon EBS 卷。Elastic Beanstalk 不再预配置此卷，因此您应从配置文件中将其删除。有关更多信息，请参阅 [Amazon Linux AMI（在 Amazon Linux 2 之前）上的 Docker 配置](create_deploy_docker.container.console.md#docker-alami)。  | 
|  私有存储库身份验证  |  当您提供 Docker 生成的身份验证文件以连接到私有存储库时，您无需再将其转换为 Amazon Linux AMI Docker 平台版本所需的旧格式。 AL2023/ AL2 Docker 平台版本支持新格式。有关更多信息，请参阅 [映像存储库的身份验证](docker-configuration.remote-repo.md)。  | 
|  代理服务器  |  AL2023/ AL2 Docker 平台版本不支持不在代理服务器后面运行的独立容器。在 Amazon Linux AMI Docker 平台版本上，这一点过去可以通过 `aws:elasticbeanstalk:environment:proxy` 命名空间中 `ProxyServer` 选项的 `none` 值来实现。  | 

### Go
<a name="using-features.migration-al.specific.go"></a>

下表列出了 [Go](go-environment.md) 平台中 AL2 023/ AL2 平台版本的迁移信息。


|  **领域**  |  **更改和信息**  | 
| --- | --- | 
|  端口传递  |  在 AL2 023/ AL2 平台上，Elastic Beanstalk 不会通过环境变量将端口值传递给您的应用程序进程。`PORT`您可以通过亲自配置 `PORT` 环境属性来模拟进程的此类行为。但是，如果您具有多个进程，并且您依赖于 Elastic Beanstalk 将增量端口值（5000、5100、5200 等）传递给进程，则应当修改您的实现。有关详细信息，请参阅 [反向代理配置](platforms-linux-extend.proxy.md)。  | 

### Amazon Corretto
<a name="using-features.migration-al.specific.corretto"></a>

下表列出了 [Java SE 平台](java-se-platform.md)中的 Corretto 平台分支的迁移信息。


|  **领域**  |  **更改和信息**  | 
| --- | --- | 
|  Corretto 与 OpenJDK  |  要实现 Java 平台、标准版 (Java SE)、 AL2 023/ AL2 平台分支，请使用 Amazon [Corrett](https://aws.amazon.com/corretto) o，这是开放式 Java 开发套件 (OpenJDK) 的 AWS 发行版。早期 Elastic Beanstalk Java SE 平台分支使用 Amazon Linux AMI 随附的 OpenJDK 软件包。  | 
|  构建工具  |  AL2023/ AL2 平台有较新版本的构建工具：`gradle``maven`、和。`ant`  | 
|  JAR 文件处理  |  在 AL2 023/ AL2 平台上，如果您的源包（ZIP 文件）包含单个 JAR 文件而不包含其他文件，则 Elastic Beanstalk 将不再将 JAR 文件重命名为。`application.jar`仅当提交 JAR 文件自身（而不是包含在 ZIP 文件中）时，才会重命名。  | 
|  端口传递  |  在 AL2 023/ AL2 平台上，Elastic Beanstalk 不会通过环境变量将端口值传递给您的应用程序进程。`PORT`您可以通过亲自配置 `PORT` 环境属性来模拟进程的此类行为。但是，如果您具有多个进程，并且您依赖于 Elastic Beanstalk 将增量端口值（5000、5100、5200 等）传递给进程，则应当修改您的实现。有关详细信息，请参阅 [反向代理配置](platforms-linux-extend.proxy.md)。  | 
|  Java 7  |  Elastic Beanstalk 不 AL2支持 023/ Java 7 平台分AL2 支。如果您有 Java 7 应用程序，请将其迁移到 Corretto 8 或 Corretto 11。  | 

### Tomcat
<a name="using-features.migration-al.specific.tomcat"></a>

下表列出了 [Tomc](java-tomcat-platform.md) at 平台中 AL2 023/ AL2 平台版本的迁移信息。


|  **领域**  |  **更改和信息**  | 
| --- | --- | 
|  **选项**  |  **迁移信息**  | 
| --- | --- | 
|  配置选项  |  在 AL2 023/ AL2 平台版本上，Elastic Beanstalk 仅支持命名空间中配置选项和选项值的子集。`aws:elasticbeanstalk:environment:proxy`以下是每个选项的迁移信息。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/elasticbeanstalk/latest/dg/using-features.migration-al.generic.from-al1.html)  AL2023/ AL2 平台`aws:elasticbeanstalk:container:tomcat:jvmoptions`版本不支持命名空间中的`XX:MaxPermSize`选项。修改永久生成大小的 JVM 设置仅适用于 Java 7 及更早版本，因此不适用于 AL2 023/ AL2 平台版本。  | 
|  应用程序路径  |  在 AL2 023/ AL2 平台上，您的环境的 Amazon EC2 实例上应用程序目录的路径是。`/var/app/current`在 Amazon Linux AMI 平台上，该路径为 `/var/lib/tomcat8/webapps`。  | 
|  `GzipCompression`  |   AL2023/ 平台版本AL2 不支持。  | 
|  `ProxyServer`  |  AL2023/ AL2 Tomcat 平台版本同时支持 nginx 和 Apache HTTPD 版本 2.4 代理服务器。但是，不支持 Apache 版本 2.2。 在 Amazon Linux AMI 平台版本中，默认代理是 Apache 2.4。如果您使用默认代理设置并添加了自定义代理配置文件，则您的代理配置仍应在 AL2 023AL2/上起作用。但是，如果您使用了 `apache/2.2` 选项值，则现在必须将代理配置迁移到 Apache 版本 2.4。  | 

### Node.js
<a name="using-features.migration-al.specific.nodejs"></a>

下表列出了 [Node.js](create_deploy_nodejs.container.md) 平台中 AL2 023/ AL2 平台版本的迁移信息。


|  **领域**  |  **更改和信息**  | 
| --- | --- | 
|  **选项**  |  **迁移信息**  | 
| --- | --- | 
|  已安装的 Node.js 版本  |  在 AL2 023/ AL2 平台上，Elastic Beanstalk 维护多个 Node.js 平台分支，并且仅在每个平台版本上安装与平台分支对应的最新版本的 Node.js 主版本。例如，Node.js 12 平台分支中的每个平台版本在默认情况下仅安装 Node.js 12.x.y。在 Amazon Linux AMI 平台版本上，我们在每个平台版本上安装了多个 Node.js 版本的多个版本，并且只维护一个平台分支。 选择与您的应用程序所需的 Node.js 主版本对应的 Node.js 平台分支。  | 
|  Apache HTTPD 日志文件名  |  在 AL2 023/ AL2 平台上，如果您使用 Apache HTTPD 代理服务器，则 HTTPD 日志文件名为`access_log`和`error_log`，这与所有其他支持 Apache HTTPD 的平台一致。在 Amazon Linux AMI 平台版本上，这些日志文件分别命名为 `access.log` 和 `error.log`。 有关所有平台的日志文件名和位置的详细信息，请参阅 [Elastic Beanstalk 是如何设置日志 CloudWatch 的](AWSHowTo.cloudwatchlogs.md#AWSHowTo.cloudwatchlogs.loggroups)。  | 
|  配置选项  |  在 AL2 023/ AL2 平台上，Elastic Beanstalk 不支持命名空间中的配置选项。`aws:elasticbeanstalk:container:nodejs`其中一些选项具有备用项。以下是每个选项的迁移信息。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/elasticbeanstalk/latest/dg/using-features.migration-al.generic.from-al1.html)  | 
|  `NodeCommand`  |  使用 `package.json` 文件中的 `Procfile` 或 `scripts` 关键字指定启动脚本。  | 
|  `NodeVersion`  |  使用 `package.json` 文件中的 `engines` 关键字指定 Node.js 版本。请注意，您只能指定与平台分支对应的 Node.js 版本。例如，如果您使用的是 Node.js 12 平台分支，则只能指定 12.x.y Node.js 版本。有关更多信息，请参阅 [使用 package.json 文件指定 Node.js 依赖项](nodejs-platform-dependencies.md#nodejs-platform-packagejson)。  | 
|  `GzipCompression`  |   AL2023/ 平台版本AL2 不支持。  | 
|  `ProxyServer`  |  在 AL2 023/ AL2 Node.js 平台版本上，此选项已移至命名`aws:elasticbeanstalk:environment:proxy`空间。您可以在 `nginx`（默认值）和 `apache` 之间进行选择。 AL2023/ AL2 Node.js 平台版本不支持不在代理服务器后面运行的独立应用程序。在 Amazon Linux AMI Node.js 平台版本上，这一点过去可以通过 `aws:elasticbeanstalk:container:nodejs` 命名空间中 `ProxyServer` 选项的 `none` 值来实现。如果您的环境运行独立应用程序，请更新您的代码以侦听代理服务器（nginx 或 Apache）将流量转发到的端口。 <pre>var port = process.env.PORT || 5000;<br /><br />app.listen(port, function() {<br />  console.log('Server running at http://127.0.0.1:%s', port);<br />});</pre>  | 

### PHP
<a name="using-features.migration-al.specific.php"></a>

下表列出了 [PHP](create_deploy_PHP.container.md) 平台中 AL2 023/ AL2 平台版本的迁移信息。


|  **领域**  |  **更改和信息**  | 
| --- | --- | 
|  PHP 文件处理  |  在 AL2 023/ AL2 平台上，使用 PHP-FPM（CGI 进程管理器）处理 PHP 文件。在 Amazon Linux AMI 平台上，我们使用的是 mod\$1php（一个 Apache 模块）。  | 
|  代理服务器  |  AL2023/ AL2 PHP 平台版本同时支持 nginx 和 Apache HTTPD 代理服务器。默认为 nginx。 Amazon Linux AMI PHP 平台版本仅支持 Apache HTTPD。如果您添加了自定义 Apache 配置文件，则可以将 `aws:elasticbeanstalk:environment:proxy` 命名空间中的 `ProxyServer` 选项设置为 `apache`。  | 

### Python
<a name="using-features.migration-al.specific.python"></a>

下表列出了 Pyth [on](create-deploy-python-container.md) 平台中 AL2 023/ AL2 平台版本的迁移信息。


|  **领域**  |  **更改和信息**  | 
| --- | --- | 
|  WSGI 服务器  |  在 AL2 023/ AL2 平台上，[Gunicorn 是默认的 WSG](https://gunicorn.org/) I 服务器。默认情况下，Gunicorn 侦听端口 8000。该端口可能与您的应用程序在 Amazon Linux AMI 平台上使用的端口不同。如果您正在设置 `[aws:elasticbeanstalk:container:python](command-options-specific.md#command-options-python)` 命名空间的 `WSGIPath` 选项，请将该值替换为 Gunicorn 语法。有关更多信息，请参阅 [Python 配置命名空间](create-deploy-python-container.md#python-namespaces)。 此外，您可以使用 `Procfile` 指定和配置 WSGI 服务器。有关更多信息，请参阅 [在 Elastic Beanstalk 上使用 Procfile 配置 WSGI 服务器](python-configuration-procfile.md)。  | 
|  应用程序路径  |  在 AL2 023/ AL2 平台上，您的环境的 Amazon EC2 实例上应用程序目录的路径是。`/var/app/current`在 Amazon Linux AMI 平台上，该路径为 `/opt/python/current/app`。  | 
|  代理服务器  |  AL2023/ Pyt AL2 hon 平台版本同时支持 nginx 和 Apache HTTPD 代理服务器。默认为 nginx。 Amazon Linux AMI Python 平台版本仅支持 Apache HTTPD。如果您添加了自定义 Apache 配置文件，则可以将 `aws:elasticbeanstalk:environment:proxy` 命名空间中的 `ProxyServer` 选项设置为 `apache`。  | 

### Ruby
<a name="using-features.migration-al.specific.ruby"></a>

下表列出了 [Ruby](create_deploy_Ruby.container.md) 平台中 AL2 023/ AL2 平台版本的迁移信息。


|  **领域**  |  **更改和信息**  | 
| --- | --- | 
|  已安装 Ruby 版本  |  在 AL2 023/ AL2 平台上，Elastic Beanstalk 仅在每个平台版本上安装与平台分支相对应的单个 Ruby 版本的最新版本。例如，Ruby 2.6 平台分支中的每个平台版本仅安装了 Ruby 2.6.x。在 Amazon Linux AMI 平台版本上，我们安装了多个 Ruby 版本的最新版本，例如 2.4.x、2.5.x 和 2.6.x。 如果您的应用程序使用的 Ruby 版本与您正在使用的平台分支不对应，建议您切换到具有适合您的应用程序的 Ruby 版本的平台分支。  | 
|  应用程序服务器  |  在 AL2 023/ AL2 平台上，Elastic Beanstalk 仅在所有 Ruby 平台版本上安装 Puma 应用服务器。您可以使用 `Procfile` 启动其他应用程序服务器，并使用 `Gemfile` 来安装它。 在 Amazon Linux AMI 平台上，对于每个 Ruby 版本，我们支持两种平台分支 - 一种具有 Puma 应用程序服务器，另一种具有 Passenger 应用服务器。如果您的应用程序使用 Passenger，则可以将 Ruby 环境配置为安装和使用 Passenger。 有关更多信息以及示例，请参阅 [使用 Elastic Beanstalk Ruby 平台](create_deploy_Ruby.container.md)。  | 

# 平台停用常见问题
<a name="using-features.migration-al.FAQ"></a>

**注意**  
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. 平台分支的停用意味着什么？
<a name="using-features.migration-al.FAQ.what-retire-means"></a>

在公布的平台分支停用日期之后，除非您已经拥有基于该平台分支的活动环境，否则您将无法再基于已停用的平台分支创建新环境。有关更多信息，请参阅[常见问题 11](#using-features.migration-al.FAQ.new-env-create)。Elastic Beanstalk 将停止为这些平台分支提供新的维护更新。建议不要在生产环境中使用已停用的平台分支。有关更多信息，请参阅[常见问题 5](#using-features.migration-al.FAQ.remove-components)。

## 2. 为什么 AWS 停用了 AL1基于平台的分支？
<a name="using-features.migration-al.FAQ.why"></a>

当平台组件被其供应商弃用或停用时，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. 哪些平台分支已停用？
<a name="using-features.migration-al.FAQ.which-pb-retire"></a>

 有关已停用的平台组件和平台分支的列表，请参阅 [已停用平台分支历史记录](platforms-schedule.md#platforms-support-policy.retired)。

## 4. 目前支持哪些平台？
<a name="using-features.migration-al.FAQ.which-pb-supported"></a>

请参阅 *AWS Elastic Beanstalk 平台*中[支持 Elastic Beanstalk 的平台](https://docs.aws.amazon.com/elasticbeanstalk/latest/platforms/platforms-supported.html)。

## 5. Elastic Beanstalk 是否会在停用后移除或终止我的环境中的任何组件？
<a name="using-features.migration-al.FAQ.remove-components"></a>

我们针对已停用平台分支的政策不会撤销对环境或已删除资源的访问权限。但是，由于供应商将其组件标记为寿命终止 (EOL)，Elastic Beanstalk 无法为已停用平台分支提供安全更新、技术支持或修补程序，因此基于已停用平台分支的环境最终可能会陷入无法预测的境地。例如，在已停用平台分支上运行的环境中，可能会出现有害且关键的安全漏洞。或者，如果环境随着时间推移变得与 Elastic Beanstalk 服务不兼容，则 EB API 操作可能会不再适用于该环境。基于已停用平台分支的环境保持活动状态的时间越长，出现这些类型风险的几率就越高。

如果您的应用程序在已停用的平台分支上运行时遇到问题并且您无法将其迁移到受支持的平台，则需要考虑其他替代方案。解决方法包括将该应用程序封装到 Docker 映像中，以便将其以 Docker 容器的形式运行。这将允许客户使用我们的任何 Docker 解决方案，例如我们的 Elastic AL2 Beanstalk/Docker 平台，或者其他基于 Docker 的服务，例如亚马逊 AL2023 ECS 或 Amazon EKS。非 Docker 替代方案包括我们的 AWS CodeDeploy 服务，它允许您完全自定义所需的运行时。

## 6. 我是否可以提交推迟停用日期的请求？
<a name="using-features.migration-al.FAQ.extend-request"></a>

不可以。在停用日期后，现有环境将继续正常运行。只不过，Elastic Beanstalk 不会再提供平台维护和安全更新。因此，迁移到基于平台的平台 AL2 或者您 AL2023 是否仍在 AL1基于平台上运行应用程序至关重要。有关风险和解决方法的更多信息，请参阅[常见问题 5](#using-features.migration-al.FAQ.remove-components)。

## 7. 如果我无法及时完成 AL2 或 AL2023 迁移，有哪些解决方法？
<a name="using-features.migration-al.FAQ.workarounds"></a>

客户可以继续运行该环境，但我们强烈建议您制定计划将所有 Elastic Beanstalk 环境迁移到受支持的平台版本。这样做可将风险降至最低，并持续受益于更新的版本中提供的重要安全性、性能和功能增强。有关风险和解决方法的更多信息，请参阅[常见问题 5](#using-features.migration-al.FAQ.remove-components)。

## 8. 迁移到 AL2 我们的 AL2023 平台的推荐流程是什么？
<a name="using-features.migration-al.FAQ.migration-process"></a>

有关AL2 迁移 AL1 到 AL2023 /的全面说明，请参阅[将 Elastic Beanstalk Linux 应用程序迁移到 Amazon Linux 2023 或 Amazon Linux 2](using-features.migration-al.md)。本主题解释了 Elastic Beanstalk blue/green 需要部署才能执行升级。

## 9. 如果我有在已停用平台上运行的环境，会有什么影响？
<a name="using-features.migration-al.FAQ.ret-env-impact"></a>

由于供应商将其组件标记为寿命终止 (EOL)，Elastic Beanstalk 无法为已停用平台分支提供安全更新、技术支持或修补程序，因此基于已停用平台分支的环境最终可能会陷入无法预测的境地。例如，在已停用平台分支上运行的环境中，可能会出现有害且关键的安全漏洞。或者，如果环境随着时间推移变得与 Elastic Beanstalk 服务不兼容，则 EB API 操作可能会不再适用于该环境。已停用平台分支上的环境保持活动状态的时间越长，出现这些类型风险的几率就越高。有关更多信息，请参阅[常见问题 5](#using-features.migration-al.FAQ.remove-components)。

## 10. 停用日期后 90 天会发生什么情况？
<a name="using-features.migration-al.FAQ.after-grace"></a>

我们针对已停用平台分支的政策不会撤销对环境或已删除资源的访问权限。但请注意，由于供应商将其组件标记为寿命终止 (EOL)，Elastic Beanstalk 无法为已停用平台分支提供安全更新、技术支持或修补程序，因此基于已停用平台分支的环境最终可能会陷入无法预测的境地。例如，在已停用平台分支上运行的环境中，可能会出现有害且关键的安全漏洞。或者，如果环境随着时间推移变得与 Elastic Beanstalk 服务不兼容，则 EB API 操作可能会不再适用于该环境。已停用平台分支上的环境保持活动状态的时间越长，出现这些类型风险的几率就越高。有关更多信息，请参阅[常见问题 5](#using-features.migration-al.FAQ.remove-components)。

## 11. 我是否可以基于已停用平台创建新环境？
<a name="using-features.migration-al.FAQ.new-env-create"></a>

如果您曾使用已停用平台分支使用同一账户并在同一区域创建了现有环境，则您可以基于该平台分支创建新环境。已停用的平台分支将不会在 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 执行此操作？
<a name="using-features.migration-al.FAQ.new-env-when"></a>

您可以在停用日期之后创建环境。但请记住，已停用平台分支最终可能会陷入无法预测的境地。此类环境创建或处于活动状态的时间越长，该环境遇到意外问题的风险就越高。有关创建新环境的更多信息，请参阅[常见问题 11](#using-features.migration-al.FAQ.new-env-create)。

## 13. 我是否可以克隆或重建基于已停用平台的环境？
<a name="using-features.migration-al.FAQ.clone"></a>

可以。您可以使用 [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 实例来维持容量？
<a name="using-features.migration-al.FAQ.auto-scale"></a>

该环境的资源将保持活动状态，并继续正常运行。而且，是的，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 /平台分支受到什么影响？
<a name="using-features.migration-al.FAQ.os-diff"></a>

尽管 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)。