使用自动化规则

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

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

可用的自动化规则

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

规则 说明
timedPromoteReleaseRule 自动从一个目标提升到下一个目标

根据 cron 时间表。
promoteReleaseRule 在成功

在发布序列中的上一个目标中进行发布。
advanceRolloutRule 自动将发布从指定阶段推进到

阶段。
repairRolloutRule 自动重试发布中失败的作业

指定次数，并在所有重试均失败时回滚。

配置自动化规则

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

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

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

配置 timedPromoteReleaseRule 自动化规则

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

rules:
- timedPromoteReleaseRule:
    name: "[RULE_NAME]"
    schedule: "[CRON]"
    timeZone: "[TIME_ZONE]"
    destinationTargetId: "[TO_TARGET]"
    destinationPhase: "[TO_PHASE]"

其中：

  • [RULE_NAME]

    是您为此规则指定的任意名称。此名称在交付流水线中必须是唯一的。

  • [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 stanza 位于自动化定义内。

rules:
- promoteReleaseRule:
    name: "[RULE_NAME]"
    wait: [WAIT_TIME]
    destinationTargetId: "[TO_TARGET]"
    destinationPhase: "[TO_PHASE]"

其中：

  • [RULE_NAME]

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

  • [WAIT_TIME]

    是指在发布版本准备好进行推广后，等待多长时间（以分钟为单位）再进行推广。例如 1m。m 是必需的。

    默认值为 0，即不等待。最长为 20160m（或 14 天）。

  • [TO_TARGET]

    是要升级到的目标的 targetId。

    此值也可以是 @next，这样一来，系统会在自动化配置中 selector.targets 属性指定的目标之后，自动将相应版本提升到下一个目标。如果您从 destinationTargetId 中省略相应值，则此值为默认值。

  • [TO_PHASE]

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

配置 advanceRolloutRule 自动化规则

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

配置 advanceRolloutRule 自动化时，您需要确定要从哪个阶段推进（即 sourcePhase）。此处显示的 rules stanza 位于自动化定义中。

rules:
- advanceRolloutRule:
    name: "[RULE_NAME]"
    sourcePhases: ["[START_PHASE]", "[START_PHASE]"...]
    wait: [WAIT_TIME]

其中：

  • [RULE_NAME]

    是您为此规则指定的任意名称。此名称在交付流水线中必须是唯一的。

  • [WAIT_TIME]

    是指在发布准备就绪后，等待多长时间（以分钟为单位）才推进发布。例如 1m。m 是必需的。

    默认值为 0，即不等待。最长为 20160m（或 14 天）。

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

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

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

配置 repairRolloutRule 自动化规则

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

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

您可以选择性地配置自动化功能，以在目标上回滚到上次成功发布的版本。重试也是可选的，但您需要有一定次数的重试或回滚，或者两者都有。

此处显示的 rules stanza 位于自动化定义内。

rules:
- repairRolloutRule:
    name: "[RULE_NAME]"
    phases: [PHASES_TO_REPAIR]
    jobs: [JOBS_TO_REPAIR]
    repairPhases:
    - retry:
        attempts: [NUMBER_OF_ATTEMPTS]
        wait: [WAIT_TIME]
        backoffMode: [LINEAR | EXPONENTIAL]
    - rollback:
        destinationPhase: [PHASE_NAME]

其中：

  • [RULE_NAME]

    是您为此规则指定的任意名称。此名称在交付流水线中必须是唯一的。

  • [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 阶段。

中止 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:
    name: "repair-rollout"
    repairPhases:
    - retry:
        attempts: 3
        wait: 1m
        backoffMode: LINEAR
    - rollback:
        destinationPhase: "stable"

在此自动化流程中，如果发布在指定目标上失败，系统会重试发布最多 3 次，每次重试尝试之间等待一分钟。如果所有重试尝试均失败，系统会通过创建新的发布来部署目标的最新的成功发布版本，从而启动回滚。

后续步骤