使用自動化規則

本文說明自動化規則，也就是在放送管道中自動執行的動作。舉例來說，您可以設定推送管道，在適當情況下自動將促銷活動推送至特定目標。

您只能使用 Cloud Deploy 內建的自動化規則。如要查看可用的自動化規則，請參閱這份文件。

可用的自動化規則

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

規則 說明
timedPromoteReleaseRule 自動從一個目標推送至下一個目標

依據 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 會每隔三小時啟動一次)

  • [TIME_ZONE]

    您要用於安排促銷活動的時區，格式為 IANA。

  • [TO_TARGET]

    這是要推送版本的目標 targetId，或是 @next，可讓系統在完成此自動化設定中 selector.targets property 指定的目標後，自動將版本推送至下一個目標。這是選用屬性，預設值為 @next。

  • [TO_PHASE]

    這是您要升級的階段階段名稱，例如 canary-25 或 stable。這是選用屬性；如果省略，系統會將版本升級至目標的第一個階段。

設定promoteReleaseRule自動化規則

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

設定promoteReleaseRule自動化功能時，您可以指定要宣傳的目標 (destinationTargetId) 或 @next。當版本在Automation定義中指定的目標成功推出後，系統會根據wait時間間隔，將版本推送至destinationTargetId中指定的目標。

您也可以使用 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]

其中：

  • [RULE_ID]

    是您要為這項規則指定的名稱。此名稱在自動化資源中不得重複。

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

在這項自動化作業中，如果目標的推出作業失敗，系統會重試最多 3 次，每次重試之間會等待一分鐘。如果所有重試嘗試都失敗，系統會建立新的推出作業，將目標的最新成功發布版本部署至該目標，藉此啟動復原程序。

後續步驟