我们建议您使用声明式基础架构，以一致且可控的方式部署基础。此方法通过在流水线中强制执行可接受的资源配置政策控制来帮助实现一致的治理。此蓝图使用 GitOps 流程进行部署，在部署流水线中将 Terraform 用于定义基础架构即代码 (IaC)、将 Git 代码库用于代码的版本控制和批准，以及将 Cloud Build 用于用于 CI/CD 自动化。有关此概念的说明，请参阅使用 Terraform、Cloud Build 和 GitOps 管理基础架构即代码。
以下部分介绍如何使用部署流水线来管理组织中的资源。
流水线层
为了区分负责管理环境的不同层的团队和技术栈，我们推荐了一款模型，该模型使用不同的流水线和不同角色来负责每一层栈。
下图介绍了我们建议的用于区分基础流水线、基础架构流水线和应用流水线的模型。
下图介绍了此模型中的流水线层：
- 应用流水线为每个工作负载（例如容器或映像）部署工件。我们建议由一个中心团队负责管理多个业务部门和工作负载使用的基础资源。
- 基础架构流水线部署工作负载（例如虚拟机实例或数据库）使用的项目和基础架构。此蓝图会为每个业务部门设置单独的基础架构流水线，或者您可能更倾向于多个团队使用的单个基础架构流水线。
- 应用流水线为每个工作负载部署工件，例如例如容器或映像。您可能有多个不同的应用团队使用单独的应用流水线。
以下部分介绍每个流水线层的用法。
基础流水线
基础流水线用于部署基础资源。它还设置了用于部署工作负载使用的基础架构的基础架构流水线。
如需创建基础流水线，请先将 terraform-example-foundation 克隆或复刻到您自己的 Git 代码库中。按照 0-bootstrap README 文件中的步骤配置您的引导文件夹和资源。
| 阶段 | 说明 |
|---|---|
引导 Google Cloud 组织。此步骤还会在后续阶段为蓝图代码配置 CI/CD 流水线。
|
在 0-bootstrap 阶段创建基础流水线后，以下阶段会在基础流水线上部署资源。请查看每个阶段的 README 说明，并按顺序实现每个阶段。
| 阶段 | 说明 |
|---|---|
通过组织政策设置顶级共享文件夹、共享服务项目、组织级日志记录和基准安全设置。 |
|
在您创建的 Google Cloud 组织中设置开发、非生产和生产环境。 |
|
或 |
在您选择的拓扑和关联的网络资源中设置共享 VPC。 |
基础架构流水线
基础架构流水线会部署工作负载使用的项目和基础架构（例如虚拟机实例和数据库）。基础流水线会部署多个基础架构流水线。基础流水线和基础架构流水线之间的这种区别有助于分离平台范围的资源和工作负载专用资源。
下图描述了此蓝图如何配置旨在由不同团队使用的多个基础架构流水线。
该图描述了以下主要概念：
- 每个基础架构流水线都独立于基础资源用于管理基础架构资源。
- 每个业务部门都有自己的基础架构流水线，该流水线在
common文件夹中的专用项目中接受管理。 - 每个基础架构流水线都有一个服务账号，该账号有权将资源仅部署到与该业务部门关联的项目。此策略会在用于基础流水线的特权服务账号与每个基础架构流水线使用的服务账号之间实现职责分离
如果您的组织中有多个实体具备独立管理基础架构的技能和意愿，尤其是在实体具有不同的要求时（例如它们想要强制执行不同类型的流水线验证政策），建议使用这个多基础架构流水线方法。或者，您可能希望由采用一致验证政策的单个团队来管理单个基础架构流水线。
在 terraform-example-foundation 中，第 4 阶段配置基础架构流水线，第 5 阶段演示了使用该流水线部署基础架构资源的示例。
| 阶段 | 说明 |
|---|---|
设置文件夹结构、项目和基础架构流水线。 |
|
|
以基础架构流水线为例，使用 Compute Engine 实例部署工作负载项目。 |
应用流水线
应用流水线负责为每个工作负载（例如运行应用业务逻辑的映像或 Kubernetes 容器）部署应用工件。这些工件会部署到基础架构流水线部署的基础架构资源中。
企业基础蓝图可设置基础流水线和基础架构流水线，但不会部署应用流水线。如需查看示例应用流水线，请参阅企业应用蓝图。
使用 Cloud Build 自动执行流水线
此蓝图使用 Cloud Build 自动执行 CI/CD 流程。下表介绍了 terraform-example-foundation 代码库部署的基础流水线和基础架构流水线中内置的控制。如果您要使用其他 CI/CD 自动化工具开发自己的流水线，我们建议您应用类似的控制。
| 控制 | 说明 |
|---|---|
拆分 build 配置以在部署之前验证代码 |
此蓝图对整个流水线使用两个 Cloud Build build 配置文件，并且与某个阶段关联的每个代码库有两个与这些 build 配置文件关联的 Cloud Build 触发器。将代码推送到代码库分支时，系统会触发 build 配置文件首次运行 |
Terraform 政策检查 | 此蓝图包含一组由 Google Cloud CLI 中的政策验证强制执行的 Open Policy Agent 限制条件。这些限制条件定义了流水线可以部署的可接受资源配置。如果一个 build 不符合第一个 build 配置中的政策，则第二个 build 配置将不会部署任何资源。 在蓝图中强制执行的政策复刻自 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。
如需使用此永久性分支策略开发代码，请遵循以下简要步骤：
- 当您开发新功能或修复问题时，请基于开发分支创建一个新的分支。为分支使用命名惯例，包括更改类型、工单编号或其他标识符以及直观易懂的说明，例如
feature/123456-org-policies。 - 完成功能分支中的工作后，创建一个针对开发分支的 PR。
- 提交 PR 时，PR 会触发基础流水线执行
terraform plan和terraform validate以暂存并验证更改。 - 验证对代码的更改后，将功能或问题修复合并到开发分支中。
- 合并过程会触发基础流水线运行
terraform apply，以将开发分支中的最新更改部署到开发环境。 - 使用与您的用例相关的任何手动审核、功能测试或端到端测试，审核开发环境中的更改。然后，通过创建以非生产分支为目标的 PR 将更改升级到非生产环境，并合并您的更改。
- 要将资源部署到生产环境，请重复与第 6 步相同的过程：检查并验证已部署的资源，创建一个针对生产分支的 PR，然后进行合并。
后续步骤
- 了解运维最佳做法（本系列的下一个文档）。