使用自动化规则

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

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

可用的自动化规则

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

配置自动化规则

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

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

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

配置 promoteReleaseRule 自动化规则

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

配置 promoteReleaseRule 自动化操作时，您可以指定要提升到的目标（destinationTargetId）或 @next。在 Automation 定义中指定的目标中成功完成发布后，该版本会在 wait 时间间隔内提升到 destinationTargetId 中指定的目标。

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

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。此属性为可选属性；如果您省略此属性，则版本将提升到目标中的第一个阶段。

配置 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 语法：

  * * * * *

  在此时间表中…

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

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

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

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

• [TIME_ZONE]

  您要用于安排促销活动的时区，采用 IANA 格式。

• [TO_TARGET]

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

• [TO_PHASE]

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

配置 advanceRolloutRule 自动化规则

advanceRolloutRule 会在一个阶段成功完成后，自动将发布作业推进到下一阶段。此自动化规则对 Canary 部署很有用。例如，如果您在目标上配置了 Canary 部署策略，其中包含 25%、50% 和 stable 三个阶段，则可以配置一个自动化规则，以便在 50% 阶段完成后自动将阶段推进到 stable。

配置 advanceRolloutRule 自动化操作时，您需要指定要从哪个阶段推进（即 sourcePhase）。此处显示的 rules 诗节将位于自动化操作定义内。

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 诗节将位于自动化定义内。

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 表示一分钟间隔。时间单位（在本例中为 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 次，每次重试尝试之间会等待 1 分钟。如果所有重试均失败，系统会创建新的发布，以将目标的最近一次成功发布部署到该目标，从而启动回滚。

后续步骤

• 试用快速入门：自动执行版本创建和发布推进。

• 详细了解 Cloud Deploy 中的部署自动化功能。