建議您使用宣告式基礎架構，以一致且可控的方式部署基礎架構。這種做法可在管道中強制執行關於可接受的資源設定的政策控管，以便實現一致的治理。藍圖會透過 GitOps 流程部署，其中 Terraform 用於定義基礎架構即程式碼 (IaC)、Git 存放區用於版本管控和程式碼核准，以及 Cloud Build 用於部署管道中的 CI/CD 自動化。如要瞭解這個概念，請參閱「使用 Terraform、Cloud Build 和 GitOps 以程式碼的形式管理基礎架構」。
以下各節說明如何使用部署管道來管理貴機構中的資源。
管道層
為分隔負責管理環境不同層級的團隊和技術堆疊，我們建議您採用採用不同管道和不同角色的模型，這些角色負責堆疊的各個層級。
下圖介紹我們建議的模型，可用於將基礎管道、基礎架構管道和應用程式管道分開。
下圖介紹此模型中的管道層：
- 基礎管道會部署在整個平台上使用的基礎資源。建議由單一中央團隊負責管理多個業務單位和工作負載所消耗的基礎資源。
- 基礎架構管道會部署工作負載使用的專案和基礎架構，例如 VM 執行個體或資料庫。藍圖會為每個業務單位設定個別的基礎架構管道，您也可以選擇由多個團隊共用單一基礎架構管道。
- 應用程式管道會為每個工作負載部署構件，例如容器或映像檔。您可能有多個應用程式團隊，每個團隊都有個別的應用程式管道。
以下各節將介紹各個管道層的用法。
基礎管道
基礎管道會部署基礎資源。並設定用於部署工作負載所用基礎架構的基礎架構管道。
如要建立基礎管道，請先將 terraform-example-foundation 複製或分支至您自己的 Git 存放區。請按照 0-bootstrap README 檔案中的步驟設定引導資料夾和資源。
| 階段 | 說明 |
|---|---|
啟動 Google Cloud 機構。這個步驟也會在後續階段為藍圖程式碼設定 CI/CD 管道。
|
在 0-bootstrap 階段建立基礎管道後，後續階段會在基礎管道上部署資源。請查看各階段的 README 說明，並依序實作各階段。
| 階段 | 說明 |
|---|---|
透過機構政策設定頂層共用資料夾、共用服務專案、機構層級記錄，以及基準安全性設定。 |
|
在您建立的 Google Cloud 機構內設定開發、非正式和正式環境。 |
|
或 |
在您選擇的拓撲和相關聯的網路資源中設定共用虛擬私有雲。 |
基礎架構管道
基礎架構管道會部署工作負載使用的專案和基礎架構 (例如 VM 執行個體和資料庫)。基礎管道會部署多個基礎架構管道。基礎管道和基礎架構管道之間的這種分離，可將平台層級資源與工作負載專屬資源分開。
下圖說明藍圖如何設定多個基礎架構管道，供不同團隊使用。
圖表說明下列重要概念：
- 每個基礎架構管道都會獨立於基礎資源之外管理基礎架構資源。
- 每個業務單位都有自己的基礎架構管道，並在
common資料夾中的專屬專案中管理。 - 每個基礎架構管道都會設有服務帳戶，該帳戶具備僅能將資源部署至與該業務單位相關聯的專案的權限。這項策略會在基礎管道使用的特殊權限服務帳戶，與各基礎架構管道使用的服務帳戶之間建立職責區隔。
如果貴機構內有多個實體，且這些實體具備管理基礎架構的專業技能和意願，特別是如果他們有不同的需求 (例如想要強制執行的管道驗證政策類型)，建議您採用這種方法，使用多個基礎架構管道。或者，您可能會希望由單一團隊管理單一基礎架構管道，並採用一致的驗證政策。
在 terraform-example-foundation 中，第 4 階段會設定基礎架構管道，第 5 階段則會示範如何使用該管道部署基礎架構資源。
| 階段 | 說明 |
|---|---|
設定資料夾結構、專案和基礎架構管道。 |
|
|
使用基礎架構管道做為範例，部署具有 Compute Engine 執行個體的工作負載專案。 |
應用程式管道
應用程式管道負責為每個個別工作負載部署應用程式構件，例如執行應用程式業務邏輯的映像檔或 Kubernetes 容器。這些構件會部署至基礎架構管道所部署的基礎架構資源。
企業基礎架構藍圖會設定基礎管道和基礎架構管道，但不會部署應用程式管道。如需應用程式管道範例，請參閱企業應用程式藍圖。
使用 Cloud Build 自動化管道
藍圖會使用 Cloud Build 自動化 CI/CD 程序。下表說明瞭由 terraform-example-foundation 存放區部署的基礎管道和基礎架構管道內建的控制項。如果您使用其他 CI/CD 自動化工具開發自己的管道，建議您套用類似的控管措施。
| 控制項 | 說明 |
|---|---|
分開建構設定，在部署前驗證程式碼 |
藍圖會為整個管道使用兩個 Cloud Build 建構設定檔，而與階段相關聯的每個存放區都會包含兩個與這些建構設定檔相關聯的 Cloud Build 觸發條件。當程式碼推送至存放區分支版本時，系統會觸發建構設定檔，首先執行 |
Terraform 政策檢查 | 藍圖包含一組 Open Policy Agent 限制，這些限制會由 Google Cloud CLI 中的政策驗證強制執行。這些限制會定義管道可部署的資源設定。如果某個版本不符合第一個建構設定中的政策，第二個建構設定就不會部署任何資源。 藍圖中強制執行的政策是從 GitHub 上的 |
最低權限原則 | 基礎管道會為每個階段提供不同的服務帳戶，並設有允許政策，只授予該階段所需的最低 IAM 角色。每個 Cloud Build 觸發條件都會以該階段的特定服務帳戶執行。使用不同的帳戶有助於降低修改一個存放區可能影響由其他存放區管理的資源的風險。如要瞭解套用至每個服務帳戶的特定 IAM 角色，請參閱引導階段的 |
Cloud Build 私人集區 | 此藍圖會使用 Cloud Build 私人集區。您可以選擇在私人集區中強制執行額外控管措施，例如限制存取公開存放區或在 VPC Service Controls 範圍內執行 Cloud Build。 |
Cloud Build 自訂建構工具 | 藍圖會建立自己的自訂建構工具來執行 Terraform。詳情請參閱 |
部署作業核准 | 您可以視需要在 Cloud Build 中新增手動核准階段。這項核准程序會在建構作業觸發後，但在執行前新增額外檢查點，方便具有權限的使用者手動核准建構作業。 |
分支策略
我們建議您採用持續分支策略，將程式碼提交至 Git 系統，並透過基礎管道部署資源。下圖說明持續分支策略。
這張圖表說明 Git 中的三個持續分支版本 (開發、非實際工作環境和實際工作環境)，這些分支版本會反映對應的Google Cloud 環境。還有多個暫時性功能分支，不對應於在Google Cloud 環境中部署的資源。
建議您在 Git 系統中強制執行提取要求 (PR) 程序，這樣任何合併至持續分支的程式碼都會具有已核准的 PR。
如要使用這個持續分支策略開發程式碼，請按照下列概略步驟操作：
- 開發新功能或修正錯誤時，請根據開發分支建立新分支。為分支使用命名慣例，包括變更類型、支援單號碼或其他 ID，以及人類可讀的說明，例如
feature/123456-org-policies。 - 完成功能分支中的作業後，請開啟以開發分支為目標的 PR。
- 提交 PR 時，PR 會觸發基礎管道，執行
terraform plan和terraform validate，以便階段化及驗證變更。 - 驗證程式碼變更後，請將功能或錯誤修正項目合併至開發分支版本。
- 合併程序會觸發基礎管道執行
terraform apply，將開發分支中的最新變更部署至開發環境。 - 使用與用途相關的手動審查、功能測試或端對端測試，查看開發環境中的變更。接著，請開啟以非正式版分支版本為目標的 PR，並合併變更內容，將變更推送至非正式版環境。
- 如要將資源部署至實際工作環境，請重複步驟 6 的程序：檢查並驗證已部署的資源、向實際工作分支開啟 PR，然後合併。
後續步驟
- 請參閱營運最佳做法 (本系列的下一篇文件)。