更新计算环境 - Amazon Batch
更新 Amazon Fargate 计算环境更新 AMI ID
Amazon Web Services 文档中描述的 Amazon Web Services 服务或功能可能因区域而异。要查看适用于中国区域的差异，请参阅 中国的 Amazon Web Services 服务入门 (PDF)。

更新计算环境

创建使用 EC2 资源的计算环境后，可以直接更新计算环境的许多设置。但是，更改某些设置需要Amazon Batch替换计算环境中的实例。

更新 Amazon Fargate 计算环境

对于使用 Fargate 资源的计算环境，可以更新以下内容。

  • securityGroupIds

  • subnets

  • desiredvCpus

  • maxvCpus

  • minvCpus

Amazon Batch有两种更新机制。第一种是扩展更新，即从计算环境中添加或删除实例。第二种是基础架构更新，即替换计算环境中的实例。基础架构更新比扩展更新所需的时间要长得多。

如果使用Amazon Batch更新计算环境，则仅更改以下设置会导致扩展更新：所需的 vCPU (desiredvCpus)、最大 vCPU (maxvCpus)、最小 vCPU (minvCpus)、服务角色 (serviceRole) 和状态 (state)。

注意

更新desiredvCpus设置时，该值必须介于minvCpus和maxvCpus值之间。

此外，更新的desiredvCpus值必须大于或等于当前的desiredvCpus值。有关更多信息，请参阅 更新desiredvCpus设置时出现错误消息。

如果在 UpdateComputeEnvironmentAPI 操作中更改了以下任何设置，则Amazon Batch会启动基础架构更新。基础架构更新要求将服务角色设置为 AWSServiceRoleForBatch（默认），并且分配策略为BEST_FIT_PROGRESSIVE、SPOT_CAPACITY_OPTIMIZED或SPOT_PRICE_CAPACITY_OPTIMIZED。不支持BEST_FIT。除了服务角色之外，所有可在扩展更新中更改的设置也可在基础架构更新中更改。

注意

建议在大多数情况下使用SPOT_PRICE_CAPACITY_OPTIMIZED而不是SPOT_CAPACITY_OPTIMIZEDn。

在基础架构更新期间，计算环境的状态更改为UPDATING。使用更新的设置启动新实例。新作业被安排到新实例上。当前正在运行的作业将根据基础架构更新策略进行分配。有关更多信息，请参阅 Amazon BatchAPI 参考中的UpdateComputeEnvironment和UpdatePolicy。

在UpdatePolicy数据类型中，请考虑以下情景：

注意

在这些情景中，以下各项适用。实例终止时，正在运行的作业也会停止。默认情况下，不会重试这些任务。要在实例终止后重试其中一个作业，请配置任务重试策略。有关更多信息，请参阅Amazon Batch《用户指南》中的自动作业重试。

  • 如果将terminateJobsOnUpdate设置设为true，则在基础架构更新期间将终止正在运行的作业。jobExecutionTimeoutMinutes设置将忽略。

  • 如果将terminateJobsOnUpdate设置设为false，则在基础架构更新后，作业可以运行更多时间。该额外时间在jobExecutionTimeoutMinutes设置中配置。默认情况下，jobExecutionTimeoutMinutes设置为 30 分钟。

当计算环境中有可用容量时，将使用更新的设置启动新实例，并在新实例上启动作业。在使用旧设置的实例上完成所有作业后，旧实例就会终止。容量变为可用意味着所需的 vCPU 数量比最大 vCPU 数量少，至少少于最小实例类型所需的 vCPU 数量。

基础架构更新

要更改计算环境的某些设置，需要更新基础架构。如果更改了以下任何设置，则会启动基础架构更新：

重要

计算环境必须使用 AWSServiceRoleForBatch 服务相关角色来进行需要更新基础架构的更改。

如果计算环境使用服务相关角色，则无法将其更改为使用常规 IAM 角色。同样，如果计算环境具有常规 IAM 角色，则无法将其更改为使用服务相关角色。因此，只能在使用服务相关角色创建的计算环境上执行基础架构更新。

  • 分配策略 (allocationStrategy，必须是BEST_FIT_PROGRESSIVE、SPOT_CAPACITY_OPTIMIZED或SPOT_PRICE_CAPACITY_OPTIMIZED。如果最初的分配策略是BEST_FIT，则不支持基础架构更新。）

    注意

    建议在大多数情况下使用SPOT_PRICE_CAPACITY_OPTIMIZED而不是SPOT_CAPACITY_OPTIMIZEDn。

  • 出价百分比 (bidPercentage)

  • EC2 配置 (ec2Configuration)

  • 密钥对 (ec2KeyPair)

  • 映像 ID (imageId)

  • 实例角色 (instanceRole)

  • 实例类型 (instanceTypes)

  • 启动模板 (launchTemplate)

  • 置放群组 (placementGroup)

  • 安全组 (securityGroupIds)

  • VPC 子网 (subnets)

  • EC2 标签 (tags)

  • 计算环境类型（type，可以是EC2或SPOT之一）

  • 是否在基础架构更新期间更新到Amazon Batch支持的最新 AMIupdateToLatestImageVersion

更新 AMI ID

在基础架构更新期间，计算环境的 AMI ID 可能会发生变化，这取决于是否在上述三种设置中的任何一种中指定了 AMI。AMI 在imageId（在computeResources）、imageIdOverride（在ec2Configuration）中指定，或者在launchTemplate指定的启动模板中指定。假设这些设置中都没有指定 AMI ID，且updateToLatestImageVersion设置是true。然后，Amazon Batch支持的最新 Amazon ECS 优化 AMI 将用于任何基础架构更新。

如果至少在其中一个设置中指定了 AMI ID，则更新将取决于提供了更新前使用的 AMI ID 的设置。创建计算环境时，选择 AMI ID 的优先级首先是启动模板，然后是imageId设置，最后是imageIdOverride设置。但是，如果使用的 AMI ID 来自启动模板，则更新imageId或imageIdOverride设置都不会更新 AMI ID。更新从启动模板中选择的 AMI ID 的唯一方法是更新启动模板。如果启动模板的版本参数为$Default或$Latest，则会评估指定启动模板的默认版本或最新版本。如果默认选择了不同的 AMI ID 或选择了最新版本的启动模板，则将在更新中使用该 AMI ID。

如果未使用启动模板来选择 AMI ID，则会使用imageId或imageIdOverride参数中指定的 AMI ID。如果同时指定了这两个参数，则会使用imageIdOverride参数中指定的 AMI ID。

假设计算环境使用由imageId、imageIdOverride或launchTemplate参数指定的 AMI ID，并且要使用由Amazon Batch支持的最新 Amazon ECS 优化 AMI。然后，更新必须删除提供 AMI ID 的设置。对于imageId，需要为该参数指定一个空字符串。对于imageIdOverride，需要为ec2Configuration参数指定一个空字符串。

如果 AMI ID 来自启动模板，则可以通过以下任一方法更改为Amazon Batch支持的最新 Amazon ECS 优化 AMI：

  • 通过为launchTemplateId或launchTemplateName参数指定一个空字符串，删除启动模板。这将删除整个启动模板，而不仅仅是 AMI ID。

  • 如果启动模板的更新版本未指定 AMI ID，则必须将updateToLatestImageVersion参数设置为true。