使用自动规则

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

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

可用的自动化规则

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

规则 说明
promoteReleaseRule 成功后自动将某个版本提升到指定的目标

上一个目标进行部署。
advanceRolloutRule 自动将发布从指定的

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

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

配置自动化规则

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

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

配置 promoteReleaseRule 项自动化规则

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

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

您还可以使用 destinationPhase 属性将版本提升到预期目标中的特定阶段。

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 部署例如，如果您在目标上配置了 Canary 部署策略，其中包含 25%、50% 和 stable 三个阶段，则可以配置一个自动化规则，以便在 50% 阶段完成后自动将阶段推进到 stable。

配置 advanceRolloutRule 自动化操作时，您需要指定要从哪个阶段推进（即 sourcePhase）。

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:
- 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 分钟。如果所有重试都失败，系统会创建新的发布，以将目标的最近一次成功发布部署到该目标，从而启动回滚。

后续步骤