使用自動化規則

本文件說明自動化規則，也就是可在提交管道中自動執行的動作。舉例來說，您可以設定提交管道，在適當情況下自動將內容提交至特定目標。

您只能使用 Cloud Deploy 內建的自動化規則。這份文件列出了可用的自動化規則。

可用的自動化規則

Cloud Deploy 提供下列自動化規則：

規則 說明
promoteReleaseRule 成功推出後，自動將版本推送至指定目標

在程序中的上一個目標中推出。
timedPromoteReleaseRule 自動從一個目標推送至下一個目標

依據 Cron 排程。
advanceRolloutRule 自動從指定的

phase 到下一個階段。
repairRolloutRule 自動重試推出作業中的失敗工作

指定次數，如果所有重試都失敗，則回溯。

設定自動化規則

每項自動化規則的設定取決於特定規則。本節將說明所有規則的共同設定，以及如何設定每項可用規則。

每個自動化規則都會設為自動化資源的一部分。您可以將這項資訊放在相關提交管道的設定 (通常稱為 clouddeploy.yaml) 所在的檔案中，也可以放在任何檔案中。進一步瞭解如何設定自動化動作。

以下各節將說明個別自動化規則的特定設定。如要設定自動化動作本身，請參閱「自動進行部署」。

設定 promoteReleaseRule 自動化規則

promoteReleaseRule 規則會在版本成功推出至目標後推送版本。舉例來說，如果您有三個目標，可以設定這個規則，讓系統在成功部署至第一個目標後，自動將版本推送至第二個目標。

設定 promoteReleaseRule 自動化動作時，您可以指定要提升至哪個目標 (destinationTargetId) 或 @next。當推出作業在 Automation 定義中指定的目標中順利完成時，系統就會將版本推送至 destinationTargetId 中指定的目標，並遵循 wait 時間間隔。

您也可以使用 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 語法：

    * * * * *

    在這個時間表中...

    • 第一個位置是分鐘 (0 至 59)。
    • 第二個位置是小時 (0 至 23)。
    • 第三個位置是當月日期 (1 至 31)。
    • 第四個位置是月份 (1 至 12)。
    • 第五個位置是星期幾 (0-6，星期日至星期六)

    舉例來說，如果您的時間限定宣傳規則包含以下排程：0 9 * * 1，則系統會在每週一上午 9 點宣傳您的版本。

    您也可以使用標準的 cron 排程功能，例如：

    • 範圍 (0-5)
    • 清單 (1、3、5)
    • 步進函數 (例如，小時欄位中的 */3 會每隔三小時啟用一次)

  • [TIME_ZONE]

    您要用來安排促銷活動的時區，以 IANA 格式表示。

  • [TO_TARGET]

    是推送至目標的 targetId，或是 @next，以便在自動化設定的 selector.targets property 中指定目標後，自動將版本推送至下一個目標。這是選用項目，預設值為 @next。

  • [TO_PHASE]

    是您要宣傳至的階段名稱，例如 canary-25 或 stable。這個屬性是選用的，如果省略，則該版本會推送至目標的第一個階段。

設定 advanceRolloutRule 自動化規則

advanceRolloutRule 會在成功完成一個階段後，自動將推出作業推進至下一個階段。這項自動化規則適用於金絲雀部署作業。舉例來說，如果您在目標上設定了金絲雀部署策略，並且有 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 為 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 次，每次重試之間等候 1 分鐘。如果所有重試嘗試都失敗，系統會建立新的推出作業，並開始復原，將目標的最新成功版本部署至該目標。

後續步驟