

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

# 更新中的计算环境 Amazon Batch
<a name="updating-compute-environments"></a>

Amazon Batch 提供了多种更新计算环境的策略，每种策略都针对特定的更新场景和要求而设计。这些方法使用相同的底层更新 API，但代表了用于有效管理更新的不同规范方法。您可以使用 Amazon Batch 控制台或管理这些更新 Amazon CLI。了解这些策略有助您选择最适合自己需求的方法，同时尽可能减少工作负载中断。

本主题概述了可用的更新策略，并提供了有关每种方法的使用场景的指导。有关详细操作过程，请参阅每种更新策略的相应部分。

**重要**  
Amazon Batch 代表您并在您的账户中创建和管理多个 Amazon 资源，包括亚马逊 EC2 启动模板、亚马逊 EC2 Auto Scaling 群组、亚马逊 EC2 竞价队列和亚马逊 ECS 集群。这些托管式资源均经过专门配置，以确保 Amazon Batch 的最优运行状态。除非在 Amazon Batch 文档中明确说明，否则手动修改这些 Amazon Batch托管资源可能会导致意外行为，包括`INVALID`计算环境、实例扩展行为不佳、工作负载处理延迟或意外成本。不能确定 Amazon Batch 服务一定能够支持这些手动修改。请务必使用支持的控制台 Amazon Batch APIs 或 Amazon Batch 控制台来管理您的计算环境。  
不支持的手动修改包括在托管的 Amazon ECS 集群上运行您自己的 Amazon Batch Amazon ECS 任务或服务，或者直接在托管实例上 Amazon Batch启动其他进程、守护程序或服务。 Amazon Batch 完全控制托管计算环境中的计算资源，并且可以随时终止实例、停止任务或扩展集群。您在这些托管资源上提交 Amazon Batch 任务之外运行的任何工作负载都可以在没有警告的情况下中断。在 Amazon Batch托管集群和实例上运行非Amazon Batch 工作负载也会干扰 Amazon Batch 作业调度和实例扩展。

**Topics**
+ [计算环境更新策略](#update-strategies)
+ [选择合适的更新策略](#choosing-update-strategies)
+ [AMI 更新注意事项](#ami-update-considerations)
+ [执行扩缩更新](scaling-updates.md)
+ [执行基础设施更新](infrastructure-updates.md)
+ [为计算环境执行 blue/green 更新](blue-green-updates.md)

## 计算环境更新策略
<a name="update-strategies"></a>

使用扩缩更新或基础设施更新策略时，您的计算环境将就地更新。对于 blue/green 更新策略，您可以创建一个新的计算环境（绿色），然后将工作负载从旧计算环境（蓝色）迁移到新的计算环境（绿色）。

Amazon Batch 为计算环境更新提供了三种不同的策略：

扩缩更新  
扩缩更新通过增加或移除实例来调整计算环境的容量，但不会替换现有实例。这是最快的更新场景，不需要停机时间。需要更改容量设置时使用扩展更新 (vCPUs)。此类更新通常会在几分钟内完成。  
Fargate 更新的执行过程与扩缩更新相同。有关更多信息，请参阅 [执行扩缩更新](scaling-updates.md)。

基础架构更新  
基础设施更新会将计算环境中的实例替换为具有更新后设置的新实例。此类更新需要特定的服务角色和分配策略配置，但停机时间极少，正在运行的作业可能会出现中断。需要修改实例类型、AMI 配置、联网设置、服务角色、环境状态或其他基础设施组件时，应使用基础设施更新。根据作业完成情况，此类更新通常会在 10-30 分钟内完成。  
有关更多信息，请参阅 [执行基础设施更新](infrastructure-updates.md)。

蓝绿更新  
Blue/green updates create a new compute environment alongside your existing environment, allowing gradual workload transition with zero downtime. This approach provides the safest update path but requires running two environments temporarily. Use blue/green在需要零停机时间、想要在完全部署之前测试更改、需要快速回滚功能或使用不支持的配置进行基础架构更新时进行更新。完成更新所需的时间因情况而异，并且由您控制。  
有关更多信息，请参阅 [为计算环境执行 blue/green 更新](blue-green-updates.md)。

## 选择合适的更新策略
<a name="choosing-update-strategies"></a>

使用以下决策指南来选择最适合您需求的更新策略：

### 选择扩缩更新的场景
<a name="scaling-updates-when"></a>

当你只需要调整计算容量 (vCPUs) 时，选择扩展更新策略。需要在无停机时间的情况下快速更新且无需更改基础设施配置时，扩缩更新是理想的选择。

有关详细步骤，请参阅 [执行扩缩更新](scaling-updates.md)。

### 选择基础设施更新的场景
<a name="infrastructure-updates-when"></a>

需要修改实例类型、AMI 设置、服务角色、环境状态或联网配置时，应选择基础设施更新策略。您的环境必须使用*AWSServiceRoleForBatch*服务相关角色和`BEST_FIT_PROGRESSIVE``SPOT_CAPACITY_OPTIMIZED`、或`SPOT_PRICE_CAPACITY_OPTIMIZED`的分配策略。如果更新期间可以接受某些作业中断，并且您希望自动更新到最新版本的 Amazon ECS 优化型 AMI，则非常适合选择基础设施更新。

有关详细步骤，请参阅 [执行基础设施更新](infrastructure-updates.md)。

### 何时选择 blue/green 更新
<a name="blue-green-updates-when"></a>

如果您的工作负载需要零停机时间，或者您需要在过渡生产工作负载之前测试更改，请选择 blue/green 更新策略。当快速回滚功能很重要、您的环境使用`BEST_FIT`分配策略或者您的环境不使用*AWSServiceRoleForBatch*服务相关角色时，这种方法是必不可少的。 Blue/green 当您使用需要手动更新或需要进行重大配置更改 AMIs 的自定义版本时，更新也是最佳选择。

有关详细步骤，请参阅 [为计算环境执行 blue/green 更新](blue-green-updates.md)。

## AMI 更新注意事项
<a name="ami-update-considerations"></a>

更新方法 AMIs 取决于您的计算环境配置。

### 将 Amazon Batch 提供的默认 AMI 更新为最新
<a name="automatic-ami-updates"></a>

Amazon Batch 当满足所有这些条件时，可以在[基础设施](infrastructure-updates.md)更新期间更新到最新 Amazon ECS 优化的 AMI：

**注意**  
基础设施更新完成后，`updateToLatestImageVersion` 将设置为 `false`。要启动其他更新，必须将 `updateToLatestImageVersion` 设置为 `true`。
+ 计算环境使用*AWSServiceRoleForBatch*服务相关角色。
+ 分配策略设置为`BEST_FIT_PROGRESSIVE``SPOT_CAPACITY_OPTIMIZED`、或`SPOT_PRICE_CAPACITY_OPTIMIZED`。
+ 在`imageId`、`imageIdOverride`或启动模板中未明确指定 AMI ID。
+ `updateToLatestImageVersion` 设置为 `true`。

### AMI 使用 blue/green 部署进行更新
<a name="manual-ami-updates-blue-green"></a>

 AMIs 在以下情况下，必须使用 blue/green 部署进行更新：
+ 使用特定版本的亚马逊 ECS 优化 AMI 时。
+ 在以下任一资源中指定了 AMI ID 时：
  + 启动模板（必须更新模板或将其删除）。
  + `imageId`参数。
  + EC2 配置中的`imageIdOverride`参数。
+ 使用`BEST_FIT`分配策略时（不支持基础架构更新）。
+ 不使用*AWSServiceRoleForBatch*[服务相关角色](using-service-linked-roles-batch-general.md)时。

### 自定义 AMI 的 AMI 更新
<a name="manual-ami-updates-custom-ami"></a>

如果您在计算环境的启动模板中指定自定义 AMI，则 EC2 配置中的`imageId``imageIdOverride`参数或参数 Amazon Batch 不会在基础设施更新期间自动更新您的自定义 AMI。您可以通过在创建计算环境时最初使用的参数中指定新 ID 来更新自定义 AMI ID。如果您想切换到使用 Amazon Batch提供的 AMI，则可以通过在计算环境更新中删除自定义 AMI ID 来实现。