本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
更新计算环境
创建使用 EC2 资源的计算环境后，您可以直接更新计算环境的许多设置。但是，更改某些设置需要 Amazon Batch 替换计算环境中的实例。
重要
Amazon Batch 代表您并在您的账户中创建和管理多个 Amazon 资源，包括亚马逊 EC2 启动模板、Amazon A EC2 uto Scaling 群组、Amazon EC2 Spot 队列和 Amazon ECS 集群。这些托管资源经过专门配置，以确保最佳 Amazon Batch
运行。除非 Amazon Batch
文档中明确说明，否则手动修改这些批处理管理的资源可能会导致意外行为，从而导致INVALID计算环境、实例扩展行为不理想、工作负载处理延迟或意外成本。该服务无法确定性地支持这些手动修改。 Amazon Batch 请务必使用支持的 Batch APIs 或 Batch 控制台来管理您的计算环境。
更新 Amazon Fargate 计算环境
对于使用 Fargate 资源的计算环境，可以更新以下内容。
-
securityGroupIds -
subnets -
desiredvCpus -
maxvCpus -
minvCpus
Amazon Batch 有两种更新机制。第一种是扩展更新，即从计算环境中添加或删除实例。第二种是基础架构更新，即替换计算环境中的实例。基础架构更新比扩展更新所需的时间要长得多。
如果您使用更新计算环境 Amazon Batch，则仅更改以下设置会导致扩展更新：所需的 v CPUs (desiredvCpus)、最大 v CPUs (maxvCpus)、最小 v CPUs (minvCpus)、服务角色 (serviceRole) 和状态 (state)。
注意
更新desiredvCpus设置时，该值必须介于minvCpus和maxvCpus值之间。
此外，更新的desiredvCpus值必须大于或等于当前的desiredvCpus值。有关更多信息，请参阅 更新desiredvCpus设置时出现错误消息。
如果在中更改了以下任何设置 UpdateComputeEnvironmentAPI 操作， Amazon Batch 启动基础架构更新。基础架构更新要求将服务角色设置为 AWSServiceRoleForBatch（默认），并且分配策略为BEST_FIT_PROGRESSIVESPOT_CAPACITY_OPTIMIZED、或SPOT_PRICE_CAPACITY_OPTIMIZED。 BEST_FIT不支持。除了服务角色之外，所有可在扩展更新中更改的设置也可在基础架构更新中更改。
注意
建议在大多数情况下使用SPOT_PRICE_CAPACITY_OPTIMIZED而不是SPOT_CAPACITY_OPTIMIZED。
在基础架构更新期间，计算环境的状态更改为UPDATING。使用更新的设置启动新实例。新作业被安排到新实例上。当前正在运行的作业将根据基础架构更新策略进行分配。有关更多信息，请参阅《Amazon Batch API 参考》中的UpdateComputeEnvironment和UpdatePolicy。
在UpdatePolicy数据类型中，请考虑以下情景：
注意
在这些情景中，以下各项适用。实例终止时，正在运行的作业也会停止。默认情况下，不会重试这些任务。要在实例终止后重试其中一个作业，请配置任务重试策略。有关更多信息，请参阅Amazon 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_OPTIMIZED。 -
出价百分比 (
bidPercentage) -
EC2 配置 (
ec2Configuration) -
密钥对 (
ec2KeyPair) -
映像 ID (
imageId) -
实例角色 (
instanceRole) -
实例类型 (
instanceTypes) -
启动模板 (
launchTemplate) -
置放群组 (
placementGroup) -
安全组 (
securityGroupIds) -
VPC 子网 (
subnets) -
EC2 标签 (
tags) -
计算环境类型（
type，可以是EC2或SPOT之一） -
是否在基础设施更新 Amazon Batch 期间更新到支持的最新 AMI
updateToLatestImageVersion
更新 AMI ID
在基础设施更新期间，计算环境的 AMI ID 可能会发生变化，具体取决于 AMIs 是否在这三个设置中指定。 AMIs 在imageId（incomputeResources）、imageIdOverride（in）或中ec2Configuration指定的启动模板中指定launchTemplate。假设在这些设置中 IDs 均未指定 AMI，且updateToLatestImageVersion设置为true。然后，将支持的最新 Amazon ECS 优化 Amazon 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，并且要使用由 Amazon Batch支持的最新 Amazon ECS 优化 AMI。然后，更新必须删除提供 AMI 的设置 IDs。对于imageId，需要为该参数指定一个空字符串。对于imageIdOverride，需要为ec2Configuration参数指定一个空字符串。
如果 AMI ID 来自启动模板，则可以通过以下任一方式更改为支持的最新 Amazon ECS 优化 Amazon Batch 的 AMI：
-
通过为
launchTemplateId或launchTemplateName参数指定一个空字符串，删除启动模板。这将删除整个启动模板，而不仅仅是 AMI ID。 -
如果启动模板的更新版本未指定 AMI ID，则必须将
updateToLatestImageVersion参数设置为true。