部署應用程式

本頁說明如何使用 Cloud Deploy，將應用程式導入您偏好的目標執行階段環境。如要執行這項操作，請先建立推送管道和目標。

事前準備

本節說明使用 Cloud Deploy 部署應用程式前，您需要準備哪些事項。

  • 請確認執行服務帳戶具有必要的 IAM 角色和權限。

  • 建立推送管道和目標。

    Cloud Deploy 可部署至 Google Kubernetes Engine、Cloud Run 和 GKE Enterprise 叢集。目標設定會因部署對象而異。

  • 準備好容器映像檔和資訊清單。

    您需要一或多個容器映像檔才能部署，以及一或多個 Kubernetes 資訊清單 (部署到 GKE) 或服務 YAML 檔案 (部署到 Cloud Run)。

    您需要持續整合管道或其他程序，才能建構及放置圖片。您的持續整合工具可以是 Cloud Build、Jenkins，或任何可產生容器映像檔的工具，這些映像檔可提供給 Cloud Deploy 推送管道。

  • 擁有 skaffold.yaml 設定檔。

    Cloud Deploy 會呼叫 skaffold render，使用這個檔案轉譯 Kubernetes 資訊清單，並呼叫 skaffold apply 將資訊清單部署至目標。如要執行這項操作，Skaffold 至少需要最少的 skaffold.yaml。您可以透過下列任一方式取得：

    • 你可以自行建立。

      請注意，skaffold.yaml 檔案的第一行必須參照與支援的 Skaffold 版本對應的命名空間，如下例所示：

      `apiVersion: skaffold/v4beta7`

    • 請系統為你生成。

      如果您沒有 skaffold.yaml 檔案，可以讓 Cloud Deploy 為您建立一個。 這個檔案適用於新手入門、學習或展示 Cloud Deploy，不應用於實際工作負載。

    詳情請參閱「將 Skaffold 與 Cloud Deploy 搭配使用」。此外，在 Cloud Deploy 中管理資訊清單一文，也詳細說明如何搭配使用 Skaffold 和 Cloud Deploy，以及資訊清單管理工具 (例如 Helm、Kustomize 和 kpt)。

為所選執行階段環境設定 Cloud Deploy

Cloud Deploy 可將應用程式部署至下列任一執行階段環境：

叫用推送管道來建立發布版本

設定 Cloud Deploy 將應用程式部署至執行階段後，您現在可以根據建立的交付管道提交應用程式，以進行部署。

  1. 執行一般的持續整合 (CI) 程序，建立可部署的構件。

  2. 呼叫 Cloud Deploy 建立發布版本，啟動推送管道。

    從含有 Skaffold 設定的目錄執行下列指令：

    gcloud deploy releases create RELEASE_NAME --delivery-pipeline=PIPELINE_NAME --region=REGION

    因為這個指令會建立目錄和所有子目錄內容的 tar 檔案，您可能不想從主目錄或根目錄執行這個指令。您可以從包含 Skaffold 設定的目錄執行指令，也可以加入 --source= 選項 (稍後會說明)。

    在這個指令中...

    RELEASE_NAME 是這個版本的名稱。這個推送管道的所有版本名稱均不得重複。

    您可以加入 '$DATE' 或 '$TIME'，或同時加入兩者，指定動態發布名稱。舉例來說，如果您在世界標準時間下午 3 點 7 分叫用這項指令，'rel-$TIME' 會解析為 rel-1507。'$DATE' 和 '$TIME' 必須以單引號括住，且時間是您叫用指令的機器上所顯示的世界標準時間。

    PIPELINE_NAME 是推送管道的名稱，這個管道會管理透過目標進度部署的版本。這個名稱必須與管道定義中的 name 欄位相符。

    REGION 是您要建立版本的區域名稱，例如 us-central1。必填。

這項指令會將含有設定的 tar 檔案上傳至 Cloud Storage bucket，並建立版本。Cloud Deploy 也會自動建立推出作業，並將映像檔部署至推送管道中定義的第一個目標。

除了這個指令顯示的參數外，您還可以加入下列任一選項：

  • --images=<name=path/name:$IMAGE_SHA>,<name=path/name:$IMAGE_SHA>

    圖片名稱到圖片完整路徑的替代項目集合。

  • --build-artifacts=<path/file>

    Skaffold 建構構件輸出檔案的參照，可傳遞這個檔案來代表映像檔完整路徑的替代項目。

這兩個選項互斥。

您也可以加入下列其中一個標記，讓 Cloud Deploy 為您產生 skaffold.yaml 檔案：

  • --from-k8s-manifest=K8S_MANIFEST

    產生的 Skaffold 設定檔是以您傳遞這個旗標的 Kubernetes 資訊清單為依據。如果將這個旗標與 --skaffold-file 旗標或 --source 旗標搭配使用，就會產生錯誤。詳情請參閱「產生 skaffold.yaml」。

  • --from-run-manifest=RUN_MANIFEST

    產生的 Skaffold 設定會以您傳遞這個標記的 Cloud Run 服務 YAML 為依據。如果將這個旗標與 --skaffold-file 旗標或 --source 旗標搭配使用，就會產生錯誤。詳情請參閱「產生 skaffold.yaml」。

這兩個選項互斥。

如果目錄中有任何檔案不想納入 tar 檔案，也可以加入 .gcloudignore 檔案。

透過 Google Cloud 控制台建立版本

您可以使用 Google Cloud 控制台，為發布管道建立版本。這項功能適合用於試用 Cloud Deploy，但不適用於正式環境工作負載。

進行下列程序前，請先建立推送管道和一或多個目標。(您也可以使用 Google Cloud 控制台建立推送管道)。

  1. 在「推送管道詳細資料」頁面中，針對特定推送管道按一下「建立版本」。

    推送管道詳細資料，顯示「建立版本」按鈕

  2. 在「選擇容器」欄位中，貼上或輸入要部署的容器映像檔路徑。您也可以使用這個欄位中預先填入的預設容器進行評估。

    您也可以點選「選取」，從 Artifact Registry 選擇容器映像檔。

  3. 在「發行版本名稱」欄位中，為這個發行版本提供專屬名稱，或使用系統提供的預設名稱。

  4. 在「推出名稱」欄位中輸入推出名稱，或使用系統提供的預設名稱。

    這個名稱會用於將此版本推出至第一個目標。如要為後續目標命名，請在「宣傳」對話方塊或 gcloud deploy releases promote 指令中輸入名稱。

  5. 您也可以在「說明」欄位中輸入版本的說明。

  6. 在「部署詳細資料」下方，輸入 GKE 部署作業或 Cloud Run 服務的名稱，或使用系統提供的預設名稱。

    如果是 GKE，Cloud Deploy 會為您產生資訊清單。如果是 Cloud Run，Cloud Deploy 會產生服務定義，用於建立服務。

  7. 點選「建立」。

    建立發布內容的對話方塊

Cloud Deploy 會使用產生的資訊清單或 Cloud Run 服務定義，以及產生的 skaffold.yaml，建立版本。

變更部署作業逾時時間

如要將部署作業傳送至 GKE 和 GKE Enterprise 目標叢集，有三種不同的逾時設定會影響系統等待 Kubernetes 回報穩定部署作業的時間長度：

  • Cloud Build 為 Cloud Deploy 執行的作業設有 1 小時的逾時時間。

    您可以在執行環境的設定中變更這個逾時時間。

  • Skaffold 具有健康狀態檢查逾時 (deploy.statusCheckDeadlineSeconds)，這是等待部署作業穩定下來的時間量 (以秒為單位)。

    預設值為 600 秒 (10 分鐘)。如要使用這項逾時，deploy.statusCheck必須設為 true。預設為 statusCheck。如果 statusCheck 為 false，系統不會檢查狀態，kubectl apply 成功完成後，推出作業就會標示為成功。

  • 對於 kind: Deployment 的 Kubernetes 資源，有 Deployment.spec.progressDeadlineSeconds，這是 Kubernetes 等待 Deployment 回報穩定狀態的時間長度。

    這項逾時設定僅適用於 Deployment 資源。這兩個逾時的運作方式如下：

    • 如果 Kubernetes 中的 Deployment.spec.progressDeadlineSeconds 未設定，則無論是預設或明確設定，Skaffold 健康狀態檢查逾時都是有效逾時。

    • 如果已在 Kubernetes 中設定 Deployment.spec.progressDeadlineSeconds，Skaffold 會忽略自身的健康狀態檢查逾時，而 Kubernetes 進度期限就是有效逾時。不過，如果 Kubernetes 超時時間明確設為 600 (10 分鐘)，Skaffold 會假設這是預設值 (未設定) 並忽略，然後使用 Skaffold 超時時間 (如有設定)。

    • 如果未設定任何逾時，則有效逾時為 Skaffold 預設的 600 (10 分鐘)。

    除了 Deployment 之外，其他 Kubernetes 資源也可能發生逾時，但這不會影響穩定性逾時。如有任何這類項目，請檢查是否與穩定性逾時發生衝突。

    如果 Skaffold (或 Cloud Build) 超時，GKE 部署作業仍會繼續執行。Cloud Deploy 會顯示失敗，但 GKE 叢集仍可能成功或失敗。

如要變更部署穩定性逾時時間，請按照下列步驟操作：

  1. 確認 deploy.statusCheck 在 skaffold.yaml 中設為 true。

    true 為預設值。當 true 時，Skaffold 會等待健康狀態檢查回報穩定的部署作業，但須遵守下一個步驟中的逾時值。

  2. 在 skaffold.yaml 中，將 statusCheckDeadlineSeconds 設為要等待的秒數。

    deploy:
  ...
  statusCheck: true
  statusCheckDeadlineSeconds: 600
  ...

    預設值為 600 (10 分鐘)。Skaffold 會等待這段時間，直到部署作業穩定為止。如果部署作業在穩定前超過這段時間，就會失敗。

  3. 你也可以在 statusCheckDeadlineSeconds 後方加入 tolerateFailuresUntilDeadline: true。

    這項設定會告知 Skaffold，如果單一部署作業失敗，不要結束，而是要容許失敗，直到 statusCheckDeadlineSeconds 過期為止。如果資源可能需要更多時間 (最晚在狀態檢查期限前) 才能達到穩定狀態，這項設定就能派上用場。

    舉例來說，如果您使用 Istio 或 Cloud Service Mesh，部署作業可能會失敗，並顯示類似下列的訊息：

    error iptables validation failed; workload is not ready for Istio.
When using Istio CNI, this can occur if a pod is scheduled before the node is ready.

  4. 在 Kubernetes 資訊清單中，針對 kind: Deployment 資源，將 Deployment.spec.progressDeadlineSeconds 設為與 statusCheckDeadlineSeconds 相同的值。

後續步驟