升级推出策略语法和示例 - AWS Organizations
注意事项基本策略结构策略组件升级推出策略示例

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

升级推出策略语法和示例

升级推出策略定义了 AWS 服务如何对您的资源进行自动升级。了解策略语法有助于您创建符合组织升级要求的有效策略。

注意事项

在实施升级推出策略时，请考虑以下重要因素：

  • 策略名称在您的组织中必须是唯一的，并且应清晰且具有描述性。选择能反映政策目的和范围的名称。有关更多信息，请参阅 优化运营效率。

  • 在广泛部署之前，测试至关重要。首先在非生产环境中验证新策略，然后逐步扩展以确保所需的行为。有关更多信息，请参阅 从小处着手，逐步扩大规模。

  • 政策变更可能需要几个小时才能在整个组织中传播。相应地规划您的实施，并确保进行适当的监控。有关更多信息，请参阅 监控和传达变更。

  • JSON 格式必须有效，并且保持在 5,120 字节的最大策略大小之内。在满足您的要求的同时，尽可能简化政策结构。

  • 定期的政策审查有助于保持有效性。安排对您的政策进行定期评估，以确保它们继续满足您的组织需求。有关更多信息，请参阅 建立审查流程。

  • 未分配升级顺序的资源默认为 “第二” 顺序。考虑为关键资源明确设置升级顺序，而不是依赖默认值。有关更多信息，请参阅 有效验证政策变更。

  • 手动升级优先于策略定义的升级订单。确保您的变更管理流程同时考虑自动和手动升级方案。有关更多信息，请参阅 建立审查流程。

注意

在管理账户中实施基于标签的升级推出策略时，请注意，管理账户无法直接查看或访问成员账户中的资源级标签。我们建议建立一个流程，让成员账户应用一致的资源标签，然后创建引用这些标签的组织级策略。这确保了资源级标记和组织策略实施之间的适当协调。在整个组织中标签策略对资源进行标记时，您还可以使用来帮助保持标签的一致性。

基本策略结构

升级推出策略使用包含以下主要元素的 JSON 结构：

  • 策略元数据（例如版本信息）

  • 资源定位规则

  • 升级订单规格

  • 可选的异常消息

  • 特定于服务的属性

以下示例显示了基本的升级部署策略结构：

{
   "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": {
                    "upgrade_order": "first"
                }
            }
        }
    }
}

示例 2：生产环境最后一个

此示例演示如何确保您的生产环境最后获得升级。通过将带有生产标签的资源明确设置为上次升级顺序，可以保持生产环境的稳定性，同时允许在预生产环境中进行充分的测试。这种方法对于具有严格变更管理要求的组织特别有用：

{
    "tags": {
        "environment": {
            "tag_values": {
                "production": {
                    "upgrade_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"
                  }
               }
            }
         }
      }
   }
}