Google Kubernetes Engine 的持續整合與持續推送軟體更新最佳做法

Autopilot Standard

這份指南介紹一系列最佳做法，協助您向 Google Kubernetes Engine (GKE) 進行持續整合與持續推送軟體更新 (CI/CD)。當中涵蓋多個主題，從原始碼控管到部署策略都會探討。這些最佳做法僅適用於 GKE，一般 CI/CD 最佳做法仍適用。詳情請參閱「DevOps 技術：持續整合」和「DevOps 技術：持續推送軟體更新」。

如需所有 GKE 最佳做法的摘要檢查清單，請參閱本指南底部的檢查清單摘要。

如要查看所有 GKE 最佳做法的整合總覽，請參閱「GKE 最佳做法」。

持續整合

持續整合 (CI) 是指開發人員盡可能頻繁地將所有程式碼變更整合回主分支版本。這項做法旨在盡早發現問題，以便快速失敗。CI 管道通常是由開發人員推送程式碼變更所觸發。管道包含驗證這些變更的步驟，例如程式碼檢查、測試和建構。持續整合管道通常會產生構件，您可以在部署程序的後續階段部署該構件。

最佳做法：

建立可快速疊代的管道。
測試容器映像檔。
及早建立安全性。

建立可快速疊代的管道

從開發人員變更程式碼到應用程式版本開始運作，這段時間應盡可能縮短。在開發人員快速疊代的功能分支上進行開發時，這項速度特別重要。理想情況下，CI 管道應在 10 分鐘內執行完畢。如果無法這樣做，請建立兩種類型的 CI 管道：

• 快速管道：這類管道通常會在 10 分鐘內執行完畢。這些管道適用於功能分支，並非全面性。快速管道可能會導致構件不穩定。

• 完整管道：這些管道的執行時間可能超過 10 分鐘，且會執行更全面的測試和檢查。合併或提取要求，以及對主分支版本的修訂版本，都會執行完整管道。

測試容器映像檔

在 CI 管道中，請務必對程式碼和建構構件執行所有必要測試。這些測試應包括單元、功能、整合，以及負載或效能測試。

此外，測試建構的容器映像檔結構也很重要。測試結構可確保所有指令在容器內都能按照預期執行。測試也能讓您確認特定檔案是否位於正確位置，且內容正確無誤。

如要測試容器映像檔，可以使用容器結構測試架構。

在管道早期建立安全性

在開發生命週期中，盡早導入安全檢查和平衡機制。在建構構件或部署前找出安全風險，可減少處理這些風險所需的時間和成本。

為及早偵測，您可以在管道中實施下列安全措施：

• 要求主題專家審查整合至正式版存放區的任何程式碼。

• 在管道早期實施程式碼檢查和靜態程式碼分析。這項測試可協助您找出弱點，例如未逸出輸入內容、接受 SQL 查詢的原始輸入資料，或程式碼中的安全漏洞。

• 使用安全漏洞掃描功能，掃描建構的容器映像檔是否有安全漏洞。

• 使用二進位授權，防止含有安全漏洞的映像檔部署至叢集。二進位授權需要 GKE Enterprise 訂閱方案。為確保產生的映像檔更可靠，二進位授權也允許您要求不同實體或系統提供認證。例如，這些認證可能包括：

  • 通過安全漏洞掃描
  • 通過品質確保測試
  • 產品擁有者簽核

持續推送軟體更新

持續推送軟體更新 (CD) 讓您隨時都能發布程式碼。CD 會對 CI 管道產生的構件執行作業。CD 管道的執行時間可能比 CI 管道長得多，尤其是使用更複雜的部署策略 (例如藍綠部署) 時。

最佳做法：

使用 GitOps 方法。
升級容器，而非重新建構。
考慮使用更進階的部署選項。
為不同環境建立個別叢集。
盡可能讓試產環境與正式環境保持一致。
為正式環境中的故障做好準備。

使用 GitOps 方法

GitOps 的概念是將宣告式基礎架構儲存在 Git 存放區，並使用 CI/CD 工具將該基礎架構部署至環境。使用 GitOps 方法時，您可確保應用程式和叢集的所有變更都儲存在來源存放區中，且隨時可供存取。

使用 GitOps 方法可享有下列優勢：

• 您可以先查看變更，再透過合併或提取要求部署。
• 您可以在單一位置，隨時查看應用程式和叢集的狀態。
• 叢集和應用程式的快照可讓您在發生故障時更輕鬆地復原。

用於宣告式基礎架構的常見工具包括 Hashicorp 的 Terraform 和 Google Cloud的 Config Connector。如要實際操作，練習使用 GitOps 和其他工具管理基礎架構，請參閱「使用 Terraform、Cloud Build 和 GitOps 管理基礎架構即程式碼」教學課程。如要瞭解如何以 GitOps 模式管理應用程式，請試用使用 Cloud Build 以 GitOps 模式持續推送軟體更新。

推送容器映像檔，而非重新建構

容器映像檔在通過 CI/CD 管道的不同階段時，不應重新建構。重建可能會導致程式碼分支版本之間出現細微差異。這些差異可能會導致應用程式在正式環境中失敗，或不小心將未經測試的程式碼新增至正式環境容器映像檔。為確保測試的容器映像檔就是部署的容器映像檔，建議您建構一次，並在各環境中升級。這項建議假設您將環境專屬設定與套件分開。

考慮使用更進階的部署和測試模式

GKE 可讓您靈活運用多種模式部署及測試應用程式。您選擇的部署模式主要取決於業務目標。舉例來說，您可能需要在不造成任何停機時間的情況下部署變更，或是在正式發布功能之前，將變更部署至環境或一部分的使用者。

以下列舉幾種可用的部署模式：

• 重新建立部署作業：先完全縮減現有應用程式版本，再擴充新的應用程式版本。

• 滾動式更新部署：更新部分執行中的應用程式執行個體，而非一次更新所有執行中的應用程式執行個體。接著，您會逐步更新更多執行中的應用程式執行個體，直到全部更新完畢。

• 藍綠部署：您可以使用升級版應用程式，將額外的平行執行個體部署至現有的正式版執行個體。準備好部署時，您會將流量切換至新的執行個體。

為不同環境建立個別叢集

區隔環境是任何部署目標的重要考量。理想情況下，您應該為下列各個環境建立獨立的叢集：

• 開發環境：開發人員會在這個環境部署應用程式，進行測試和實驗。這類部署作業需要與應用程式或系統的其他部分 (例如資料庫) 整合。這個環境的叢集通常閘道較少，開發人員對叢集設定的控制權也較大。

• 正式生產前環境 (測試或品質確保)：這些環境應盡可能與正式環境相似。用於對變更執行大規模測試，例如整合、負載、效能或迴歸測試。

• 正式環境：這個環境用於執行正式工作負載，以及面向使用者的應用程式和服務。

讓試產環境與正式環境保持一致

理想情況下，試產叢集與正式環境叢集相同，但基於成本考量，試產叢集可以是縮減後的副本。保持叢集相似，可確保任何測試都是在與正式環境相同或相似的條件下進行。試產和正式環境叢集之間的同等性，也能降低部署至正式環境時，因環境差異而發生非預期故障的可能性。

宣告式基礎架構和 GitOps 可協助您更接近環境的同等性，因為您可以更輕鬆地複製基礎叢集的設定。如要確保環境的政策和設定條件相似，您也可以使用 Config Sync 等工具。

為正式環境中的故障做好準備

無論測試多少次，都無法保證應用程式在實際工作環境中能正常運作。失敗的原因可能是未考慮到資料的極端情況，或未測試使用者的存取模式。請務必監控實際工作環境中的應用程式，並採用自動復原和部署機制，以便快速應對及修正錯誤或服務中斷問題。採用更穩健的部署策略，可減少問題的影響，並在正式環境發生問題時，減少受影響的使用者人數。

檢查清單摘要

下表摘要列出在 GKE 中使用 CI/CD 管道時，建議執行的工作：

區	Tasks
持續整合	建立可快速疊代的管道。 測試容器映像檔。 在管道初期建立安全性機制。
持續推送軟體更新	使用 GitOps 方法。 升級容器，而非重新建構。 建議使用更進階的部署和測試模式。 為不同環境建立個別叢集。 讓正式生產前環境與正式環境保持一致。 為正式環境中的故障做好準備。

後續步驟

• 瞭解企業多用戶群的最佳做法。
• 進一步瞭解 Google Cloud的 CI/CD。