使用自动化规则

本文档介绍了自动化规则，这些规则是可对交付流水线自动执行的操作。例如，您可以配置交付流水线，以便在适当的情况下自动提升到特定目标。

您只能使用 Cloud Deploy 内置的自动化规则。 本文档列出了可用的自动化规则。

可用的自动化规则

Cloud Deploy 中提供以下自动化规则：

规则 说明
timedPromoteReleaseRule 根据 cron 时间表，自动从一个目标提升到下一个目标

基于 cron 时间表。
promoteReleaseRule 在成功发布到过程中的上一个目标后，自动将版本提升到指定目标

。
advanceRolloutRule 自动将发布从指定阶段推进到下一阶段

フェーズを次のフェーズへ。
repairRolloutRule 自动重试发布中失败的作业

指定次数，如果所有重试都失败，则回滚。

配置自动化规则

每个自动化规则的配置取决于具体规则。本部分介绍了所有规则共有的配置，以及如何配置每个可用规则。

每个自动化规则都配置为 自动化资源的配置的一部分。这可以在与相关交付流水线的配置（通常称为 clouddeploy.yaml）相同的文件中，也可以在您想要的任何文件中。详细了解如何 配置自动化。

以下部分介绍了特定于各个自动化规则的配置。如需了解自动化本身的配置，请参阅自动执行部署 。

配置 timedPromoteReleaseRule 自动化规则

借助 timedPromoteReleaseRule 规则，您可以安排何时将版本从所选目标提升到过程中的下一个目标，或提升到指定目标。配置 timedPromoteReleaseRule 自动化时，您可以根据 cron 时间表指定何时提升版本。

rules:
- timedPromoteReleaseRule:
    id: "[RULE_ID]"
    schedule: "[CRON]"
    timeZone: "[TIME_ZONE]"
    destinationTargetId: "[TO_TARGET]"
    destinationPhase: "[TO_PHASE]"

其中：

  • [RULE_ID]

    是您要为此规则指定的任何名称。此名称在自动化资源中必须是唯一的。

  • [CRON]

    是指定何时提升版本的 cron 时间表。使用此时间表指定您要提升版本的日期和时间。

    此时间表使用标准 cron 语法：

    * * * * *

    在此时间表中…

    • 第一个位置是分钟 (0-59)。
    • 第二个位置是小时 (0-23)。
    • 第三个位置是日期 (1-31)。
    • 第四个位置是月份 (1-12)。
    • 第五个位置是星期几 (0-6，周日到周六)

    例如，如果您的定时提升规则包含以下时间表：0 9 * * 1，则您的版本会在每周一上午 9 点提升。

    您还可以使用标准 cron 时间表功能，例如：

    • 范围 (0-5)
    • 列表 (1,3,5)
    • 步进函数（例如，小时字段中的 */3 每隔 3 小时激活一次）

  • [TIME_ZONE]

    是您要用于安排提升的时区，采用 IANA 格式。

  • [TO_TARGET]

    是要提升到的目标的 targetId，或者 @next 会在自动化配置中的 selector.targets property 中指定的目标之后，自动将版本提升到下一个目标。这是可选的；默认值为 @next。

  • [TO_PHASE]

    是要提升到的阶段的阶段名称，例如 canary-25 或 stable。此属性是可选的；如果您省略此属性，则版本会提升到目标中的第一个阶段。

配置 promoteReleaseRule 自动化规则

promoteReleaseRule 规则会在成功发布到目标后提升您的版本。例如，如果您有三个目标，则可以设置此规则，以便在版本成功部署到第一个目标后，自动将其提升到第二个目标。

配置 promoteReleaseRule 自动化时，您可以指定要提升到的目标 (destinationTargetId) 或 @next。当在 Automation 定义中指定的目标中成功完成发布后，版本会提升到 destinationTargetId 中指定的目标，但需遵循 wait 时间间隔。

您还可以使用 destinationPhase 属性将版本提升到预期目标中的特定阶段。此处显示的 rules 节位于 自动化操作定义内。

rules:
- promoteReleaseRule:
    id: "[RULE_ID]"
    wait: [WAIT_TIME]
    destinationTargetId: "[TO_TARGET]"
    destinationPhase: "[TO_PHASE]"

其中：

  • [RULE_ID]

    是您要为此规则指定的任何名称。此名称在自动化资源中必须是唯一的。

  • [WAIT_TIME]

    是版本准备好提升后等待提升的时间（以分钟为单位）。例如，1m。必须使用 m。

    默认值为 0，即没有等待时间。最大值为 20160m（或 14 天）。

  • [TO_TARGET]

    是要提升到的目标的 targetId 。

    这也可以是 @next，它会在自动化配置中的 selector.targets 属性中指定的目标之后，自动将版本发布到下一个 目标。如果您从 destinationTargetId 中省略该值，则这是默认值。

  • [TO_PHASE]

    是要提升到的阶段的阶段名称，例如 canary-25 或 stable。此属性是可选的；如果您省略此属性，则版本会提升到目标中的第一个阶段。

配置 advanceRolloutRule 自动化规则

advanceRolloutRule 会在成功完成一个阶段后，自动将发布推进到下一阶段。此自动化规则适用于 Canary 版部署。例如，如果您在目标上配置了 Canary 部署策略，阶段为 25%、50% 和 stable，则可以配置一个自动化规则，该规则会在 50% 阶段完成后自动将阶段推进到 stable。

配置 advanceRolloutRule 自动化时，您需要标识要推进的阶段（sourcePhase）。此处显示的 rules 节位于您的 自动化定义 内。

rules:
- advanceRolloutRule:
    id: "[RULE_ID]"
    sourcePhases: ["[START_PHASE]", "[START_PHASE]"...]
    wait: [WAIT_TIME]

其中：

  • [RULE_ID]

    是您要为此规则指定的任何名称。此名称在自动化资源中必须是唯一的。

  • [WAIT_TIME]

    是发布准备就绪后等待推进发布的时间（以分钟为单位）。例如，1m。必须使用 m。

    默认值为 0，即没有等待时间。最大值为 20160m（或 14 天）。

  • ["[START_PHASE]", "[START_PHASE]"...]

    是发布自动推进的阶段。 也就是说，当列出的任何阶段成功完成时，发布会自动从该阶段推进到下一阶段。

    阶段名称区分大小写。此外，这些阶段名称是可选的；如果您省略 sourcePhases，则发布中的所有阶段都会自动推进。

配置 repairRolloutRule 自动化规则

repairRolloutRule 规则会重试失败的发布指定次数。如果重试次数已用完，此规则可以自动将目标回滚到上次成功发布的版本。

配置 repairRolloutRule 自动化时，您可以指定重试发布的次数以及重试之间的等待时间。您还可以配置要重试的特定阶段或作业，或同时配置两者。如果每次重试尝试都失败，则发布会失败。如果任何重试成功，自动化会停止，发布也会成功。

（可选）您可以将自动化配置为回滚到目标上上次成功发布的版本。重试也是可选的，但您需要进行一定次数的重试或回滚，或者同时进行两者。

此处显示的 rules 节位于您的 自动化操作定义内。

rules:
- repairRolloutRule:
    id: "[RULE_ID]"
    phases: [PHASES_TO_REPAIR]
    jobs: [JOBS_TO_REPAIR]
    repairPhases:
    - retry:
        attempts: [NUMBER_OF_ATTEMPTS]
        wait: [WAIT_TIME]
        backoffMode: [LINEAR | EXPONENTIAL]
    - rollback:
        destinationPhase: [PHASE_NAME]
        disableRollbackIfRolloutPending: [true | false]

其中：

  • [RULE_ID]

    是您要为此规则指定的任何名称。此名称在自动化资源中必须是唯一的。

  • [PHASES_TO_REPAIR]

    是要重试的发布阶段。这是可选的，默认值为发布中的所有阶段。

  • [JOBS_TO_REPAIR]

    是要重试的作业。这是可选的，默认值为所有作业。

  • [NUMBER_OF_ATTEMPTS]

    （可选）在将发布视为失败之前重试发布的次数。

  • [WAIT_TIME]

    是重试尝试之间的等待时间。例如，1m 表示间隔为 1 分钟。必须使用时间单位（在本例中为 m）。

    如果 mode 为 linear，则每次重试的间隔都相同。如果 mode 为 exponential，则间隔每次都会增加。（如需了解详情，请参阅 mode。）

  • backoffMode

    LINEAR 或 EXPONENTIAL，表示是否增加重试之间的间隔时间。如果为 LINEAR，则重试之间的间隔时间是固定的，为 WAIT_TIME。如果为 EXPONENTIAL，则重试之间的间隔时间会随着每次重试而翻倍。默认值为 LINEAR。

    例如，如果 WAIT_TIME 为 1 分钟，并且 backoffMode 设置为 EXPONENTIAL，则失败与第一次重试之间的间隔时间为 1 分钟，第一次重试与第二次重试之间的间隔时间为 2 分钟，第二次重试与第三次重试之间的间隔时间为 4 分钟。

  • rollback

    （可选）在所有重试尝试都用完后，是否回滚失败的发布。

  • [PHASE_NAME]

    是要回滚到的特定阶段的名称。如果您省略 toPhase，则回滚默认到 stable 阶段。

  • disableRollbackIfRolloutPending：

    如果设置为 true，则当目标上有待处理的发布时，回滚操作会中止。

中止 repairRolloutRule 自动化运行

如果您对发布运行以下任何命令，则 repairRolloutRule 自动化会中止：

示例

以下是包含 repairRolloutRule 的自动化配置示例：

apiVersion: deploy.cloud.google.com/v1
kind: Automation
metadata:
  name: regular-repair/regular
description: repair regular rollouts
suspended: false
serviceAccount: (REDACTED)
selector:
  targets:
  - id: t1
rules:
- repairRolloutRule:
    id: "repair-rollout"
    repairPhases:
    - retry:
        attempts: 3
        wait: 1m
        backoffMode: LINEAR
    - rollback:
        destinationPhase: "stable"

在此自动化中，如果发布在标识的目标上失败，则该发布最多会重试 3 次，每次重试尝试之间等待 1 分钟。如果所有重试尝试都失败，则会通过创建新发布来启动回滚，以将目标最近一次成功发布的版本部署到该目标。

后续步骤