部署應用程式

本頁面說明如何使用 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 的 onboarding、學習或示範，不應用於實際工作負載。

  詳情請參閱「搭配使用 Skaffold 和 Cloud Deploy」。此外，您也可以參閱「在 Cloud Deploy 中管理資訊清單」一文，進一步瞭解如何將 Skaffold 和 Cloud Deploy 與 Helm、Kustomize 和 kpt 等資訊清單管理工具搭配使用。

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

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

• GKE
• GKE Enterprise
• Cloud Run

叫用推送管道來建立版本

設定 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 值區，並建立版本。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. 在「Delivery pipeline details」(放送管道詳細資料) 頁面中，針對特定放送管道，按一下「Create release」(建立版本)。

   

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

   您也可以按一下「選取」，從 Artifact Registry 或 Container Registry 中選擇容器映像檔。

3. 在「Release name」欄位中為此版本提供專屬名稱，或使用提供的預設名稱。

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

   這個名稱會用於推出至本版本的第一個目標。針對後續目標，您可以在「Promote」對話方塊或 gcloud deploy releases promote 指令中命名推出計畫。

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

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 是 false，則不會進行狀態檢查，推出作業會在 kubectl apply 順利完成後標示為成功。

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

  這項逾時期限僅適用於 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. 確認 skaffold.yaml 中的 deploy.statusCheck 已設為 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.
   

   這項設定僅適用於 Skaffold 2.0 以上版本。

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

後續步驟

• 瞭解如何部署至 GKE

• 瞭解如何部署至 Cloud Run

• 瞭解如何部署至 GKE Enterprise

• 瞭解如何建立推送管道和目標

• 瞭解如何宣傳版本