本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
升级推出政策语法和示例
升级推出政策定义了 Amazon 服务如何对您的资源应用自动升级。了解策略语法有助于您创建符合组织升级要求的有效策略。
注意事项
在实施升级推出政策时，请考虑以下重要因素：
-
策略名称在组织内必须是唯一的，并且应清晰且具有描述性。选择反映政策目的和范围的名称。有关更多信息，请参阅 优化运营效率。
-
在广泛部署之前，测试至关重要。首先在非生产环境中验证新策略，然后逐步扩展以确保达到预期的行为。有关更多信息，请参阅 从小规模开始，逐步扩展规模。
-
政策变更可能需要几个小时才能在您的组织中传播。相应地规划实施，并确保进行适当的监控。有关更多信息，请参阅 监控和传达变更。
-
JSON 格式必须有效且保持在 5,120 字节的最大策略大小范围内。在满足要求的同时，尽可能保持政策结构简单。
-
定期的政策审查有助于保持有效性。安排定期评估您的政策，以确保它们继续满足您的组织需求。有关更多信息，请参阅 建立审查流程。
-
没有分配升级顺序的资源默认为 “第二” 顺序。考虑明确设置关键资源的升级订单，而不是依赖默认值。有关更多信息，请参阅 有效验证政策变更。
-
手动升级优先于策略定义的升级订单。确保您的变更管理流程同时考虑自动和手动升级方案。有关更多信息，请参阅 建立审查流程。
注意
在从您的管理账户实施基于标签的升级部署政策时，请注意，管理账户无法直接查看或访问成员账户中的资源级标签。我们建议建立一个流程，让成员账户应用一致的资源标签，然后创建引用这些标签的组织级政策。这确保了资源级标记和组织策略执行之间的适当协调。在整个组织中标记资源时，您还可以使用标签策略来帮助保持标签的一致性。
基本策略结构
升级推出政策使用包含以下主要元素的 JSON 结构：
-
策略元数据（例如版本信息）
-
资源定位规则
-
升级订单规格
-
可选的异常消息
-
Service-specific 属性
以下示例显示了基本的升级部署策略结构：
{ "upgrade_rollout":{ "default":{ "patch_order":{ "@@assign":"last" } }, "tags":{ "devtag":{ "tag_values":{ "tag1":{ "patch_order":{ "@@assign":"first" } }, "tag2":{ "patch_order":{ "@@assign":"second" } }, "tag3":{ "patch_order":{ "@@assign":"last" } } } } } } }
策略组件
升级部署策略由两个关键组件组成，这两个组件共同控制如何在您的资源中应用升级。这些组件包括默认行为和基于标签的覆盖的配置选项。了解这些组件的相互作用方式有助于您创建符合组织需求的有效策略。
默认补丁顺序设置
当您在创建升级部署策略时未指定任何特定资源的替代时，所有资源将默认为基本升级顺序。您可以使用政策中的 “默认” 字段设置此默认值。没有通过标签明确分配升级顺序的资源将遵循此默认顺序。
注意
当今的主机体验需要指定默认顺序。
以下示例说明如何将所有资源设置为默认情况下持续接收升级，除非被标签覆盖。当你想确保大多数资源在升级周期的后期更新时，这种方法很有用：
"upgrade_rollout": { "default": { "patch_order": "last" } }
通过标签覆盖资源级别
您可以使用标签覆盖特定资源的默认升级顺序。这使您可以精细控制哪些资源按何种顺序接收升级。例如，您可以根据环境类型、开发阶段或工作负载关键程度分配不同的升级顺序。
以下示例说明如何配置开发资源以首先接收升级，将生产资源配置为最后接收升级。此配置可确保您的开发环境可以在升级投入生产之前对其进行验证：
"upgrade_rollout": { "tags": { "environment": { "tag_values": { "development": { "patch_order": "first" }, "production": { "patch_order": "last" } } } } }
升级推出政策示例
以下是常见的升级推出政策场景：
示例 1：首先是开发环境
此示例说明如何在开发环境中配置资源以首先接收升级。通过定位带有 “开发” 环境标签的资源，您可以确保您的开发环境是第一个接收和验证新升级的环境。此模式有助于在升级到达更关键的环境之前识别潜在问题：
{ "tags": { "environment": { "tag_values": { "development": { "patch_order": "first" } } } } }
示例 2：最后一个生产环境
此示例演示如何确保您的生产环境持续获得升级。通过明确将带有生产标签的资源设置为上次升级顺序，您可以保持生产环境的稳定性，同时允许在预生产环境中进行充分的测试。这种方法对于具有严格变更管理要求的组织特别有用：
{ "tags": { "environment": { "tag_values": { "production": { "patch_order": "last" } } } } }
示例 3：使用标签的多个升级订单
以下示例演示如何使用具有不同值的单个标签密钥来指定所有三个升级顺序。当你想通过单一标记方案管理升级订单时，这种方法很有用：
{ "upgrade_rollout":{ "default":{ "patch_order":{ "@@assign":"last" } }, "tags":{ "devtag":{ "tag_values":{ "tag1":{ "patch_order":{ "@@assign":"first" } }, "tag2":{ "patch_order":{ "@@assign":"second" } }, "tag3":{ "patch_order":{ "@@assign":"last" } } } } } } }