在部署前後執行掛鉤

本文說明如何在部署前後執行任意程式或作業。

您可以設定 Cloud Deploy 執行部署前和/或部署後的動作。以這種方式執行的程式稱為「掛鉤」。預先部署和後期部署掛鉤會在推出作業中，以預先部署和後期部署工作的形式執行。

您可以設定每個掛鉤，在指定的 Cloud Deploy 執行環境中執行，但如果部署至 Google Kubernetes Engine，則可選擇在部署應用程式的 GKE 叢集上執行。

部署掛鉤應為冪等。如果特定動作執行超過一次，不會產生額外效果。

部署掛鉤的運作方式

以下說明部署掛鉤在 Cloud Deploy 中的執行方式，以及如何設定：

  1. 您可以在推送管道進度的其中一或多個階段中設定掛鉤。

  2. 在推出作業的部署工作執行前，Cloud Deploy 會執行管道進度中 predeploy 定義設定的所有工作。

    predeploy hook 一律會在階段中做為第一個工作執行。

  3. 推出作業的部署工作執行完畢後，Cloud Deploy 會執行管道進度中 postdeploy 定義的任何工作。

部署掛鉤會在 Cloud Deploy 執行環境中執行。

搭配初期測試部署策略使用部署掛鉤

為初期測試部署設定部署掛鉤時，請注意下列事項：

  • 在交付管道階段，勾點設定 (predeploy 和 postdeploy) 位於 strategy.canary.canaryDeployment 或 strategy.canary.customCanaryDeployment.phaseConfigs 下方，而非 strategy.standard 下方。

  • 如果是自動 Canary，predeploy hook 只會在第一階段部署前執行，postdeploy hook 則只會在最後階段 (穩定版) 部署後執行。

設定管道來執行掛鉤

您可以在管道進展中的一或多個特定階段設定部署前和部署後掛鉤。

使用 standard 部署策略時，您可以在管道階段中設定部署前和部署後掛鉤，如下所示：

serialPipeline:
  stages:
  - targetId: hooks-staging
    profiles: []
    strategy:
      standard:
        predeploy:
          tasks: [TASKS]
        postdeploy:
          tasks: [TASKS]

在這個 YAML 中：

  • TASKS

    這是您要以 predeploy 或 postdeploy hook 形式執行的一或多個 Task 清單。指定多個工作時，系統會依指定順序逐一執行。如果第一個工作失敗，工作 (部署前或部署後) 就會失敗，其餘工作則不會執行。

在應用程式叢集上執行掛鉤

根據預設，部署掛鉤會在 Cloud Deploy 執行環境中執行。您也可以設定 Skaffold，在應用程式執行的相同叢集上執行部署掛鉤。

如要在應用程式叢集上執行掛鉤，您必須在 skaffold.yaml 中將掛鉤設定為 customActions，並在傳送管道階段設定的 predeploy 或 postdeploy 節中，使用 actions 參照掛鉤：

serialPipeline:
  stages:
  - targetId: hooks-staging
    profiles: []
    strategy:
      standard:
        predeploy:
          actions: ["my-predeploy-action"]
        postdeploy:
          actions: ["my-postdeploy-action"]

這項功能僅適用於 GKE 部署作業，不適用於 Cloud Run。部署至 Cloud Run 時，只能在 Cloud Deploy 執行環境中執行掛鉤。

如要設定在叢集上執行的 Hook，請在 skaffold.yaml 設定檔中加入 executionMode.kubernetesCluster 節，並放在要在叢集上執行的每個動作的 customActions 節內：

customActions:
- name: ACTION_NAME
  containers:
  - name: CONTAINER_NAME
    image: IMAGE
    command: [COMMANDS_TO_RUN]
    args: [LIST_OF_ARGS]
  executionMode:
    kubernetesCluster: {}

以下是 customActions 節的範例，其中包含 executionMode，可在應用程式叢集上叫用 Hook 容器：

customActions:
- name: predeploy-action
  containers:
  - name: predeploy-echo
    image: ubuntu
    command: ["/bin/sh"]
    args: ["-c", 'echo "this is a predeploy action"' ]
  executionMode:
    kubernetesCluster: {}

executionMode 節是選用項目，如果省略，Skaffold 會在 Cloud Deploy 執行環境中執行自訂動作容器。

可用的環境變數

Cloud Deploy 也會在執行環境中提供及填入下列環境變數。 您可以在部署掛鉤、驗證工作或自訂目標的算繪或部署作業中使用這些環境變數。

  • ANTHOS_MEMBERSHIP

    如果是 ANTHOS 類型的目標，則為 Anthos 成員資格的完整資源名稱。

  • CLOUD_RUN_LOCATION

    如果是 RUN 類型的目標，則為 Cloud Run 服務的部署區域。

  • CLOUD_RUN_PROJECT

    如果是 RUN 類型的目標，則為建立 Cloud Run 服務的專案。

  • CLOUD_RUN_SERVICE

    如果是 RUN 類型的目標，則為已部署的 Cloud Run 服務名稱。

  • CLOUD_RUN_SERVICE_URLS

    如果是 RUN 類型的目標，這是使用者用來存取服務的網址 (或以半形逗號分隔的網址清單)。您可以在Google Cloud 控制台中，查看服務的 Cloud Run 服務詳細資料。成功部署 Cloud Run 服務後，Cloud Run 會產生網址。因此，這個環境變數僅適用於部署後掛鉤和驗證工作。

  • CLOUD_RUN_REVISION

    如果是 RUN 類型的目標，則為 Cloud Run 服務的特定修訂版本。

  • GKE_CLUSTER

    如果是 GKE 類型的目標，請提供 Google Kubernetes Engine 叢集的完整資源名稱，例如 projects/p/locations/us-central1/clusters/dev。

  • TARGET_TYPE

    目標的特定執行階段類型。GKE、ANTHOS 或 RUN。 如果是自訂目標，則不會設定這項屬性。

  • CLOUD_DEPLOY_LOCATION

    包含 Cloud Deploy 資源的區域。

  • CLOUD_DEPLOY_DELIVERY_PIPELINE

    推送管道的 ID。

  • CLOUD_DEPLOY_TARGET

    目標的 ID。

  • CLOUD_DEPLOY_PROJECT

    包含 Cloud Deploy 資源的專案專案編號。 Google Cloud

  • CLOUD_DEPLOY_PROJECT_ID

    專案的 Google Cloud 專案 ID。

  • CLOUD_DEPLOY_RELEASE

    要執行 Hook 的發布版本 ID。

  • CLOUD_DEPLOY_ROLLOUT

    包含掛鉤作業的推出作業 ID。

  • CLOUD_DEPLOY_JOB_RUN

    工作執行的 ID，代表目前執行的工作。

  • CLOUD_DEPLOY_PHASE

    推出作業中的階段，包含部署掛鉤、驗證工作或自訂轉譯/部署的工作。

將參數部署為環境變數

除了本節列出的環境變數外，Cloud Deploy 還可以將您設定的任何部署參數傳遞至自訂容器。

瞭解詳情。

後續步驟