這項參考架構提供方法和初始基礎架構，讓您使用 Google Kubernetes Engine、Cloud Build、Skaffold、kustomize、Config Sync、Policy Controller、Artifact Registry 和 Cloud Deploy 等工具，建構現代化的持續整合/持續推送軟體更新 (CI/CD) 系統。
本文件屬於下列系列：
- 透過 GKE 建立現代化 CI/CD：軟體推送架構
- 使用 GKE 進行現代化的 CI/CD：建構 CI/CD 系統 (本文)
- 透過 GKE 建立現代化 CI/CD：套用開發人員工作流程
本文適用對象為企業架構師和應用程式開發人員，以及 IT 安全性、開發運作和網站可靠性工程團隊。建議您具備自動部署工具和程序的相關經驗，有助於瞭解本文概念。
CI/CD 工作流程
如要建構現代化 CI/CD 系統，首先需要選擇執行系統主要功能的工具和服務。這項參考架構著重於實作 CI/CD 系統的核心功能，如下圖所示：
這個參考實作項目會為每個元件使用下列工具：
- 原始碼管理：GitHub
- 儲存應用程式和設定程式碼。
- 可查看變更。
- 如要管理應用程式設定：
kustomize- 定義應用程式的預期設定。
- 可讓您重複使用及擴充設定原始物件或藍圖。
- 持續整合：Cloud Build
- 測試及驗證原始碼。
- 建構部署環境使用的構件。
- 持續推送軟體更新：Cloud Deploy
- 定義程式碼在各環境中的推出程序。
- 可復原失敗的變更。
- 基礎架構設定：Config Sync
- 以一致的方式套用叢集和政策設定。
- 政策執行：Policy Controller
- 提供機制，可讓您根據機構的政策，定義允許在特定環境中執行的項目。
- 容器自動化調度管理：Google Kubernetes Engine
- 執行在 CI 期間建構的構件。
- 提供工作負載的資源調度、健康狀態檢查和推出方法。
- 容器構件：Artifact Registry
- 儲存 CI 期間建構的構件 (容器映像檔)。
架構
本節說明您使用這個參考架構實作的 CI/CD 元件：基礎架構、管道、程式碼存放區和登陸區。
如要一般討論 CI/CD 系統的這些層面，請參閱「透過 GKE 建立現代化 CI/CD：軟體推送架構」。
參考架構變體
參考架構有兩種部署模型：
- 多專案變體，更像是實際工作環境部署作業，且隔離界線有所改善
- 單一專案變化版本，適合用於示範
多專案參考架構
參考架構的 multi-project 版本會模擬類似於實際運作的情境。在這些情境中，不同角色會建立基礎架構、CI/CD 管道和應用程式，並設有適當的隔離界線。這些角色或團隊只能存取必要資源。
詳情請參閱「使用 GKE 打造現代化 CI/CD：軟體推送架構」。
如要進一步瞭解如何安裝及套用這個版本的參考架構，請參閱軟體推送藍圖
單一專案參考架構
參考架構的 single-project 版本說明如何在單一 Google Cloud 專案中設定整個軟體推送平台。如果使用者沒有較高的 IAM 角色，只要具備專案擁有者角色，就能安裝並試用這個版本的參考架構。本文將說明參考架構的單一專案版本。
平台基礎架構
這個參考架構的基礎架構包含 Kubernetes 叢集，可支援開發、測試和正式版應用程式環境。下圖顯示叢集的邏輯版面配置：
程式碼存放區
使用這個參考架構，為運算子、開發人員、平台和安全工程師設定存放區。
下圖顯示不同程式碼存放區的參考架構實作，以及作業、開發和安全團隊如何與存放區互動：
在這個工作流程中，運算子可以在運算子存放區中管理 CI/CD 和應用程式設定的最佳做法。開發人員在開發存放區中加入應用程式時，會自動取得最佳做法、應用程式的商業邏輯，以及應用程式正常運作所需的任何特殊設定。同時，營運和安全團隊可以在設定和政策存放區中，管理平台的一致性和安全性。
應用程式登陸區
在這個參考架構中，應用程式的登陸區會在佈建應用程式時建立。在本系列文章的下一份文件「透過 GKE 建立現代化 CI/CD：套用開發人員工作流程」中，您將佈建新的應用程式，建立自己的登陸區。下圖說明此參考架構中使用的登陸區重要元件：
每個命名空間都包含一個服務帳戶，用於 GKE 的 Workload Identity Federation，以便存取 Kubernetes 容器外部的服務，例如 Cloud Storage 或 Spanner。命名空間也包含其他資源 (例如網路政策)，可與其他命名空間或應用程式隔離或共用邊界。
命名空間是由 CD 執行服務帳戶建立。建議團隊遵循最小權限原則，確保 CD 執行服務帳戶只能存取必要的命名空間。
您可以在 Config Sync 中定義服務帳戶存取權，並使用 Kubernetes 角色式存取控管 (RBAC) 角色和角色繫結來實作。有了這個模型，團隊就能直接將任何資源部署到他們管理的命名空間，但無法覆寫或刪除其他命名空間的資源。
目標
- 部署單一專案參考架構。
- 探索程式碼存放區。
- 探索管道和基礎架構。
費用
在本文件中，您將使用下列 Google Cloud計費元件：
如要根據預測用量估算費用，請使用 Pricing Calculator。
完成本文所述工作後，您可以刪除建立的資源，避免繼續計費，詳情請參閱「清除所用資源」。
事前準備
-
在 Google Cloud 控制台的專案選擇器頁面中，選取或建立 Google Cloud 專案。
選取或建立專案所需的角色
- 選取專案：選取專案時，不需要具備特定 IAM 角色，只要您在專案中獲派角色，即可選取該專案。
-
建立專案：如要建立專案，您需要專案建立者角色 (
roles/resourcemanager.projectCreator)，其中包含resourcemanager.projects.create權限。瞭解如何授予角色。
-
在 Google Cloud 控制台中啟用 Cloud Shell。
部署參考架構
在 Cloud Shell 中設定專案：
gcloud config set core/project PROJECT_ID
將
PROJECT_ID替換為 Google Cloud 專案 ID。在 Cloud Shell 中複製 Git 存放區：
git clone https://github.com/GoogleCloudPlatform/software-delivery-blueprint.git cd software-delivery-blueprint/launch-scripts git checkout single-project-blueprint在 GitHub 中建立個人存取權杖，並設定下列範圍：
repodelete_repoadmin:orgadmin:repo_hook
software-delivery-bluprint/launch-scripts資料夾下有名為vars.sh的空白檔案。在檔案中新增下列內容：cat << EOF >vars.sh export INFRA_SETUP_REPO="gke-infrastructure-repo" export APP_SETUP_REPO="application-factory-repo" export GITHUB_USER=GITHUB_USER export TOKEN=TOKEN export GITHUB_ORG=GITHUB_ORG export REGION="us-central1" export SEC_REGION="us-west1" export TRIGGER_TYPE="webhook" EOF
將
GITHUB_USER改成 GitHub 使用者名稱。將
TOKEN替換為 GitHub 個人存取權杖。將
GITHUB_ORG替換為 GitHub 組織名稱。執行
bootstrap.sh指令碼。如果 Cloud Shell 提示您授權，請按一下「授權」：./bootstrap.sh這個指令碼會啟動軟體推送平台。
探索程式碼存放區
在本節中，您將探索程式碼存放區。
登入 GitHub
- 在網路瀏覽器中前往 github.com，然後登入帳戶。
- 按一下介面頂端的圖片圖示。
- 按一下「你的機構」。
- 選擇您在
vars.sh檔案中輸入的機構。 - 按一下「存放區」分頁標籤。
探索入門、運算子、設定和基礎架構存放區
在入門、運算子、設定和基礎架構存放區中，運算子和平台管理員會定義在平台上建構及操作的一般最佳做法。啟動參考架構時，系統會在 GitHub 組織中建立這些存放區。
入門存放區
入門儲存庫可協助您在整個平台採用 CI/CD、基礎架構和開發最佳做法。詳情請參閱「使用 GKE 打造現代化 CI/CD：軟體推送架構」
應用程式入門存放區
在應用程式啟動器存放區中，您的運算子可以編碼及記錄最佳做法，例如 CI/CD、指標收集、記錄、容器步驟和應用程式安全性。參考架構包含 Go、Python 和 Java 應用程式的範例入門存放區。
app-template-python、app-template-java 和 app-template-golang 應用程式啟動器存放區包含樣板程式碼，可用於建立新應用程式。除了建立新應用程式，您也可以根據應用程式需求建立新範本。參考架構提供的應用程式入門存放區包含：
kustomize基本和修補程式，位於k8s資料夾下方。應用程式原始碼。
說明如何建構及執行應用程式的
Dockerfile。說明 CI 步驟最佳做法的
cloudbuild.yaml檔案。描述部署步驟的
skaffold.yaml檔案。
在本系列文章的下一份文件「
使用 GKE 打造現代化 CI/CD：套用開發人員工作流程」中，您將使用 app-template-python 存放區建立新應用程式。
基礎架構入門存放區
在基礎架構入門儲存庫中，運算子和基礎架構管理員可以編碼及記錄最佳做法，例如 CI/CD 管道、IaC、指標收集、記錄和基礎架構安全性。參考架構中包含使用 Terraform 的基礎架構入門存放區範例。infra-template 基礎架構入門存放區包含 Terraform 的樣板程式碼，可用於建立應用程式所需的基礎架構資源，例如 Cloud Storage bucket、Spanner 資料庫或其他資源。
共用範本存放區
在共用範本存放區中，基礎架構管理員和營運人員會提供標準範本來執行工作。參考架構提供名為 terraform-modules 的存放區。存放區包含範本化的 Terraform 程式碼，可建立各種基礎架構資源。
運算子存放區
在參考架構中，運算子存放區與應用程式啟動存放區相同。運算子會管理應用程式啟動器存放區中 CI 和 CD 兩者所需的檔案。
參考架構包含 app-template-python、app-template-java 和 app-template-golang 存放區。
- 這些是入門範本，包含在平台上 Kubernetes 中執行的應用程式的基本 Kubernetes 資訊清單。運算子可以視需要更新啟動範本中的資訊清單。建立應用程式時，系統會擷取更新。
- 這些存放區中的
cloudbuild.yaml和skaffold.yaml檔案分別儲存了在平台上執行 CI 和 CD 的最佳做法。與應用程式設定類似，營運人員可以更新最佳做法並新增步驟。個別應用程式管道會使用最新步驟建立。
在本參考實作中，運算子會使用 kustomize 管理啟動器存放區 k8s 資料夾中的基本設定。開發人員可以自由擴充資訊清單，加入應用程式專屬的變更，例如資源名稱和設定檔。kustomize 工具支援將設定視為資料。使用這種方法時，kustomize輸入和輸出內容都是 Kubernetes 資源。您可以將某次修改資訊清單的輸出內容，用於另一次修改。
下圖說明 Spring Boot 應用程式的基本設定：
以 kustomize 中的資料模型形式設定，有以下主要優點：當營運商更新基本設定時，開發人員的部署管道會在下次執行時自動採用更新，開發人員端不需進行任何變更。
如要進一步瞭解如何使用 kustomize 管理 Kubernetes 資訊清單，請參閱 kustomize 說明文件。
設定和政策存放區
參考架構包含使用 Config Sync 和 Policy Controller 的設定和政策存放區實作。acm-gke-infrastructure-repo 存放區包含您在應用程式環境叢集中部署的設定和政策。平台管理員在這些存放區中定義及儲存的設定，對於確保平台為營運和開發團隊提供一致的外觀和風格至關重要。
以下章節將詳細說明參考架構如何實作設定和政策存放區。
設定
在本參考實作中，您會使用 Config Sync 集中管理平台中叢集的設定，並強制執行政策。集中管理功能可讓您在整個系統中傳播設定變更。
貴組織可以使用 Config Sync 註冊叢集，從 Git 存放區同步設定，這項程序稱為 GitOps。新增叢集時，叢集會自動同步處理最新設定，並持續比對叢集狀態與設定，以免有人導入頻外變更。
政策
在本參考實作中，您會使用以 Open Policy Agent 為基礎的 Policy Controller，攔截並驗證平台中 Kubernetes 叢集的每項要求。您可以使用 Rego 政策語言建立政策，全面控管提交至叢集的資源類型和設定。
下圖的架構顯示使用 Policy Controller 建立資源的要求流程：
您可以在 Config Sync 存放區中建立及定義規則，這些變更會套用至叢集。之後，CLI 或 API 用戶端提出的新資源要求，都會由 Policy Controller 根據限制條件進行驗證。
如要進一步瞭解如何管理政策，請參閱「Policy Controller 總覽」。
基礎架構存放區
參考資料中包含使用 Terraform 實作的基礎架構存放區。gke-infrastructure-repo 存放區包含基礎架構即程式碼，可建立開發、測試和正式環境的 GKE 叢集，並使用 acm-gke-infrastructure-repo 存放區在這些叢集上設定 Config Sync。gke-infrastructure-repo 包含三個分支，分別對應開發、測試和正式環境。每個分支版本也包含開發、測試和正式環境資料夾。
探索管道和基礎架構
參考架構會在 Google Cloud 專案中建立管道。這個管道負責建立共用基礎架構。
管道
在本節中，您將探索基礎架構即程式碼管道，並執行該管道來建立共用基礎架構，包括 GKE 叢集。這個管道是基礎架構存放區 gke-infrastructure-repo 連結的 Google Cloud 專案中，名為 create-infra 的 Cloud Build 自動建構觸發條件。您按照 GitOps 方法建立基礎架構，如透過 Cloud Build Infra-As-Code 管道大規模建構可重複的 GCP 環境影片所述。
gke-infrastructure-repo 有開發、測試和正式分支版本。存放區中也有與這些分支相應的開發、預先發布和正式環境資料夾。存放區設有分支保護規則，確保程式碼只能推送至開發分支。如要將程式碼推送至測試和正式版分支，請建立提取要求。
通常，有權存取存放區的使用者會審查變更，然後合併提取要求，確保只有預期的變更會升級至較高的分支。為了讓個人試用藍圖，參考架構已放寬分支保護規則，因此存放區管理員可以略過審查，並合併提取要求。
當推送至 gke-infrastructure-repo 時，系統會叫用 create-infra 觸發條件。該觸發條件會找出推送發生所在的分支版本，並前往該分支版本存放區中的對應資料夾。找到對應的資料夾後，系統會使用資料夾中的檔案執行 Terraform。舉例來說，如果程式碼推送至開發分支版本，觸發程序會在開發分支版本的開發資料夾中執行 Terraform，建立開發 GKE 叢集。同樣地，當推送至 staging 分支時，觸發條件會在測試分支的測試資料夾上執行 Terraform，建立測試 GKE 叢集。
執行管道來建立 GKE 叢集：
前往 Google Cloud 控制台的 Cloud Build 頁面。
- 共有五個 Cloud Build Webhook 觸發條件。找出名為
create-infra的觸發條件。這個觸發程序會建立共用基礎架構，包括 GKE 叢集。
- 共有五個 Cloud Build Webhook 觸發條件。找出名為
按一下觸發條件名稱。觸發條件定義隨即開啟。
按一下「開啟編輯器」，查看觸發條件執行的步驟。
當您在「使用 GKE 進行現代化 CI/CD：套用開發人員工作流程」中導入應用程式時，會使用其他觸發條件。
前往 Google Cloud 控制台的 Cloud Build 頁面。
查看記錄頁面上的管道。使用
bootstrap.sh部署軟體交付平台時，指令碼會將程式碼推送至gke-infrastructure-repo存放區的開發分支，啟動這個管道並建立開發 GKE 叢集。如要建立暫存 GKE 叢集，請從開發分支提交提取要求至暫存分支：
前往 GitHub 並瀏覽至存放區
gke-infrastructure-repo。依序點選「提取要求」和「新增提取要求」。
在「Base」選單中選擇「staging」，在「Compare」選單中選擇「dev」。
按一下「建立提取要求」。
如果您是存放區管理員，請合併提取要求。否則，請管理員合併提取要求。
在 Google Cloud 控制台中，前往「Cloud Build history」(Cloud Build 記錄) 頁面。
專案中會啟動第二個 Cloud Build 管道。這個管道會建立測試 GKE 叢集。
如要建立正式版 GKE 叢集，請將
pull request從測試分支版本提交至正式分支版本：前往 GitHub，然後前往存放區
gke-infrastructure-repo。依序點選「提取要求」和「新增提取要求」。
在「Base」選單中選擇「prod」，在「Compare」選單中選擇「staging」。
按一下「建立提取要求」。
如果您是存放區的管理員，請合併提取要求。否則，請管理員合併提取要求。
前往 Google Cloud 控制台的「Cloud Build 記錄」頁面。
專案中會啟動第三個 Cloud Build 管道。這個管道會建立正式環境 GKE 叢集。
基礎架構
在本節中，您將探索管道建立的基礎架構。
前往 Google Cloud 控制台的「Kubernetes clusters」(Kubernetes 叢集) 頁面。
前往「Kubernetes clusters」(Kubernetes 叢集) 頁面
這個頁面會列出用於開發 (
gke-dev-us-central1)、預先發布 (gke-staging-us-central1) 和正式發布 (gke-prod-us-central1、gke-prod-us-west1) 的叢集：
開發叢集
開發叢集 (gke-dev-us-central1) 可讓開發人員存取命名空間，並用於疊代應用程式。建議團隊使用 Skaffold 等工具，主動監控開發中的程式碼，並在變更時重新套用至開發環境，藉此提供疊代工作流程。這個疊代迴圈與熱重載類似。不過，這個迴圈不限於特定程式設計語言，而是適用於任何可透過 Docker 映像檔建構的應用程式。您可以在 Kubernetes 叢集中執行迴圈。
或者，開發人員也可以在開發環境中遵循 CI/CD 迴圈。這個迴圈會準備好程式碼變更，以便推送至更高層級的環境。
在本系列文件的下一篇「透過 GKE 建立現代化 CI/CD：套用開發人員工作流程」中，您將使用 Skaffold 和 CI/CD 建立開發迴圈。
預備叢集
這個叢集會執行應用程式的暫存環境。在本參考架構中，您會建立一個用於暫存的 GKE 叢集。一般來說，測試環境是正式環境的精確副本。
正式環境叢集
在參考架構中，正式環境有兩個 GKE 叢集。如為異地備援或高可用性 (HA) 系統，建議您在每個環境中新增多個叢集。對於部署應用程式的所有叢集，建議使用區域叢集。這種做法可避免應用程式受到可用區層級故障，以及叢集或節點集區升級造成的任何中斷影響。
如要同步處理叢集資源的設定 (例如命名空間、配額和 RBAC)，建議使用 Config Sync。如要進一步瞭解如何管理這些資源，請參閱「設定和政策存放區」。
套用參考架構
瞭解參考架構後，您可以探索以這項實作方式為基礎的開發人員工作流程。在本系列文章的下一份文件「使用 GKE 進行現代化 CI/CD：套用開發人員工作流程」中，您將建立新應用程式、新增功能，然後將應用程式部署至測試和正式環境。
清除所用資源
如果您想試試本系列中的下一份文件「使用 GKE 進行現代化 CI/CD：套用開發人員工作流程」，請勿刪除與這個參考架構相關聯的專案或資源。否則，如要避免系統向您的 Google Cloud帳戶收取參考架構所用資源的費用，請刪除專案或手動移除資源。
刪除專案
- 前往 Google Cloud 控制台的「Manage resources」(管理資源) 頁面。
- 在專案清單中選取要刪除的專案，然後點選「Delete」(刪除)。
- 在對話方塊中輸入專案 ID，然後按一下 [Shut down] (關閉) 以刪除專案。
手動移除資源
在 Cloud Shell 中移除基礎架構：
gcloud container clusters delete gke-dev-us-central1 gcloud container clusters delete gke-staging-us-central1 gcloud container clusters delete gke-prod-us-central1 gcloud container clusters delete gke-prod-us-west1 gcloud beta builds triggers delete create-infra gcloud beta builds triggers delete add-team-files gcloud beta builds triggers delete create-app gcloud beta builds triggers delete tf-plan gcloud beta builds triggers delete tf-apply
後續步驟
- 按照「透過 GKE 建立現代化 CI/CD：套用開發人員工作流程」一文中的步驟，建立新的應用程式。
- 瞭解設定身分聯盟的最佳做法。
請參閱「Kubernetes and the challenges of continuous software deployment」(Kubernetes 和持續軟體部署的挑戰)。
查看 Google Cloud 的參考架構、圖表和最佳做法。歡迎瀏覽 Cloud Architecture Center。