更新计算环境 - AWS Batch
更新 AWS Fargate 计算环境更新 AMI ID

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

更新计算环境

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

重要

AWS Batch 代表您并在您的账户中创建和管理多个 AWS 资源，包括亚马逊 EC2 启动模板、Amazon A EC2 uto Scaling 群组、Amazon EC2 Spot 队列和 Amazon ECS 集群。这些托管资源经过专门配置，以确保最佳 AWS Batch 运行。除非 AWS Batch 文档中明确说明，否则手动修改这些批处理管理的资源可能会导致意外行为，从而导致INVALID计算环境、实例扩展行为不理想、工作负载处理延迟或意外成本。该服务无法确定性地支持这些手动修改。 AWS Batch 请务必使用支持的 Batch APIs 或 Batch 控制台来管理您的计算环境。

更新 AWS Fargate 计算环境

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

  • securityGroupIds

  • subnets

  • desiredvCpus

  • maxvCpus

  • minvCpus

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

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

注意

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

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

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

注意

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

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

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

注意

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

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

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

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

基础架构更新

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

重要

计算环境必须使用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之一）

  • 是否在基础设施更新 AWS Batch 期间更新到支持的最新 AMI updateToLatestImageVersion

更新 AMI ID

在基础设施更新期间，计算环境的 AMI ID 可能会发生变化，具体取决于 AMIs 是否在这三个设置中指定。 AMIs 在imageId（incomputeResources）、imageIdOverride（in）或中ec2Configuration指定的启动模板中指定launchTemplate。假设在这些设置中 IDs 均未指定 AMI，且updateToLatestImageVersion设置为true。然后，将支持的最新 Amazon ECS 优化 AWS Batch 的 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，并且要使用由 AWS Batch支持的最新 Amazon ECS 优化 AMI。然后，更新必须删除提供 AMI 的设置 IDs。对于imageId，需要为该参数指定一个空字符串。对于imageIdOverride，需要为ec2Configuration参数指定一个空字符串。

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

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

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