本文属于机器翻译版本。若本译文内容与英语原文存在差异,则一律以英文原文为准。
使用更新资源 Amazon Cloud Control API
使用 update-resource
命令可以对现有资源进行更新。这包括最初未使用 Cloud Control API 配置的资源。
重要
我们强烈建议不要使用 Cloud Control API 来更新由其他服务主动管理的资源。这样做可能会导致意外结果。例如,不要使用 Cloud Control API 来更新当前属于 Amazon CloudFormation 堆栈的资源。
要更新现有资源,您必须指定资源的标识符。有关确定资源标识符的更多信息,请参阅使用资源的主标识符。
更新资源需要更改资源属性值。资源的属性在其资源类型架构中定义。这包括属性是否为必需属性、有效值和其他属性约束。有关查看资源属性定义的更多信息,请参阅查看资源类型架构。
编写补丁文档
要更新资源,首先要将更新定义为补丁文档中包含的JSON补丁操作列表。此补丁文档必须符合 RFC6902- JavaScript 对象表示法 (JSON)
每个补丁操作都会定义对特定资源属性的单一更新。需要具有以下属性:
-
op
:操作类型。Cloud Control API 支持 RFC 6902 中定义的所有操作:add
remove
、、replace
、move
copy
、和。test
-
path
:相对于资源架构的properties
部分的资源属性路径。
根据操作的不同,可能需要其他属性。有关详细信息,请参阅 RFC 6902。
使用 update-resource
命令时,可以将补丁文档内联指定为字符串,也可以指定文件位置。
以下示例将名为的AWS::Logs::LogGroup
资源的保留策略更新CloudControlApiLogGroup
为 90 天。
$
aws cloudcontrol update-resource --type-name AWS::Logs::LogGroup \ --identifier CloudControlApiLogGroup \ --patch-document '[{"op":"test","path":"RetentionInDays","value":90}]'
云控制如何API更新资源
要更新资源,Cloud Control API 首先检索资源的当前状态,然后分两步更新资源:
-
Cloud Control API 将更新请求中指定的补丁操作与资源的当前状态相结合,以便在资源更新后生成所需的状态。系统按操作在补丁文档中出现的顺序依次应用操作。序列中的每个操作都应用于资源的当前状态;生成的资源状态将成为下一个操作的目标。
此时,如果出现以下情况,整个更新请求将失败:
-
请求中包含的补丁操作无效。
-
op
类型test
的补丁操作失败。
在这种情况下,整个更新请求都会失败,Cloud Control API 不会对资源进行任何更新。
-
-
API然后,Cloud Control 会调用该资源类型的更新处理程序来更新资源。
如果更新处理程序在任何时候失败,则 Cloud Control API 不会将资源回滚到之前的状态。
例如,考虑以下为更新AWS::Logs::LogGroup
资源而定义的补丁文档。该文档包含两个补丁操作。第一个操作是 test
类型的操作,此操作检查资源的保留策略是否设置为 3653 天。如果是这样的话,资源将通过测试,Cloud Contro API l 会继续执行下一个操作。此操作会将当前的保留策略值替换为 180 天。如果资源的保留策略设置为 3653 天以外的值,则第一个test
操作将失败,Cloud Control API 永远不会运行第二个replace
操作。
[ { "op": "test", "path": "/RetentionInDays", "value":3653 }, { "op": "replace", "path": "/RetentionInDays", "value":180 } ]
跟踪更新资源请求的进度
该 update-resource
命令将返回一个 ProgressEvent
对象,您可以使用该对象跟踪资源操作请求的当前状态。有关更多信息,请参阅 跟踪资源操作请求的进度。