借助 GKE 实现现代 CI/CD：构建 CI/CD 系统

此参考架构为您提供了一种方法和初始基础设施，以使用如下工具构建现代持续集成/持续交付 (CI/CD) 系统：Google Kubernetes Engine、Cloud Build、Skaffold、kustomize、Config Sync、Policy Controller、Artifact Registry 和 Cloud Deploy。

本文档是以下系列文章中的一篇：

本文档面向企业架构师和应用开发者，以及 IT 安全、DevOps 和网站可靠性工程团队。拥有一些自动化部署工具和流程的相关经验对于理解本文档中的概念很有用。

CI/CD 工作流

如需构建现代 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 角色的用户安装并尝试参考架构且仅具有项目的 Owner 角色。本文档演示了参考架构的单项目版本。

平台基础架构

此参考架构的基础架构包括支持开发、预演和生产应用环境的 Kubernetes 集群。下图显示了集群的逻辑布局：

集群布局支持不同的平台工作负载。

代码库

使用该参考架构，您可以为运营商、开发者、平台和安全工程师设置代码库。

下图展示了不同代码库的参考架构实现，以及运营、开发和安全团队与代码库的交互方式：

代码库包括最佳做法以及应用和平台配置的代码库。

在此工作流中，运营商可以管理运营商代码库中 CI/CD 和应用配置的最佳做法。当开发者在开发代码库中添加应用时，他们会自动获得最佳做法、应用的业务逻辑以及应用正常工作所需的任何专业配置。同时，运营团队和安全团队可以在配置和政策代码库中管理平台的一致性和安全性。

应用着陆区

在此参考架构中，应用的着陆区是在预配应用时创建的。在本系列的下一个文档（即借助 GKE 实现现代 CI/CD：应用开发者工作流）中，您将预配一个应用，该应用会创建自己的着陆区。下图说明了此参考架构中使用的着陆区的重要组成部分：

GKE 集群包括三个命名空间，用于不同的应用。

每个命名空间都包含一个服务账号，用于 GKE 的工作负载身份联合访问 Kubernetes 容器外部的服务（例如 Cloud Storage 或 Spanner）。命名空间还包含其他资源（例如网络政策），用于与其他命名空间或应用隔离或共享边界。

命名空间由 CD 执行服务账号创建。我们建议团队遵循最小权限原则，以帮助确保 CD 执行服务账号只能访问所需的命名空间。

您可以在 Config Sync 中定义服务账号访问权限，并使用 Kubernetes 基于角色的访问权限控制 (RBAC) 角色和角色绑定来实现它。启用此模型后，团队可以将任何资源直接部署到其管理的命名空间中，但会阻止在其他命名空间内覆盖或删除资源。

目标

  • 部署单项目参考架构。
  • 探索代码库。
  • 探索流水线和基础架构。

费用

在本文档中，您将使用 Google Cloud 的以下收费组件：

您可使用价格计算器根据您的预计使用情况来估算费用。 Google Cloud 新用户可能有资格申请免费试用。

完成本文档中描述的任务后，您可以通过删除所创建的资源来避免继续计费。如需了解详情，请参阅清理。

准备工作

  1. 在 Google Cloud Console 中的项目选择器页面上，选择或创建一个 Google Cloud 项目。

    转到“项目选择器”

  2. 确保您的 Google Cloud 项目已启用结算功能。

  3. 在 Google Cloud 控制台中，激活 Cloud Shell。

    激活 Cloud Shell

部署参考架构

  1. 在 Cloud Shell 中，设置项目：

    gcloud config set core/project PROJECT_ID

    将 PROJECT_ID 替换为您的 Google Cloud 项目 ID。

  2. 在 Cloud Shell 中，克隆 Git 代码库：

    git clone https://github.com/GoogleCloudPlatform/software-delivery-blueprint.git
cd software-delivery-blueprint/launch-scripts
git checkout single-project-blueprint

  3. 在 GitHub 中创建具有以下范围的个人访问令牌：

    • repo
    • delete_repo
    • admin:org
    • admin:repo_hook

  4. 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 组织的名称。

  5. 运行 bootstrap.sh 脚本： 如果 Cloud Shell 提示您授权，请点击授权：

    ./bootstrap.sh

    该脚本会引导软件交付平台。

探索代码库

在本部分中，您将探索代码库。

登录 GitHub

  1. 在网络浏览器中，转到 github.com 并登录您的账号。
  2. 点击界面顶部的图片图标。
  3. 点击您的组织。
  4. 选择您在 vars.sh 文件中作为输入而提供的组织。
  5. 点击代码库标签页。

探索入门、运营商、配置和基础架构代码库

入门、运营商、配置和基础架构代码库是运营商和平台管理员用于定义构建和运营平台的常见最佳做法的地方。当引导架构被引导时，这些代码库将在您的 GitHub 组织下创建。

列表中的每个代码库都包含简要说明。

入门代码库

入门级代码库有助于在平台上采用 CI/CD、基础架构和开发最佳做法。如需了解详情，请参阅借助 GKE 实现现代 CI/CD：软件交付框架

应用入门代码库

在应用入门代码库中，运营商可以协调并记录最佳做法，例如应用的 CI/CD、指标收集、日志记录、容器步骤和安全。参考架构中包含 Go、Python 和 Java 应用的入门代码库示例。

app-template-python、app-template-java 和 app-template-golang 应用入门级代码库包含可用于创建新应用的样板代码。除了创建新应用之外，您还可以根据应用要求创建新的模板。参考架构提供的应用入门代码库包含：

  • kustomize 基础和 k8s 文件夹下的补丁。

  • 应用源代码

  • 它是一个 Dockerfile，描述如何构建和运行应用

  • 一个 cloudbuild.yaml 文件，描述 CI 步骤的最佳做法。

  • 描述部署步骤的 skaffold.yaml 文件。

在本系列的下一个文档（即借助 GKE 实现现代 CI/CD：应用开发者工作流）中，您可以使用 app-template-python 代码库创建一个新应用。

基础架构入门代码库

在基础架构入门代码库中，运营商和基础架构管理员可以编写代码并记录最佳做法，例如 CI/CD 流水线、IaC、指标收集、日志记录和安全基础架构。参考架构中包含使用 Terraform 的基础架构入门代码库示例。infra-template 基础架构起始代码库包含 Terraform 的样板代码，可用于创建应用所需的基础架构资源（例如 Cloud Storage 存储桶或 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。添加新集群时，这些集群会自动同步到最新配置，并持续协调集群状态与配置，以防有人引入带外更改。

如需详细了解 Config Sync，请参阅其文档。

政策

在此参考实现中，您可以使用基于 Open Policy Agent 的 Policy Controller 来拦截和验证向平台中的 Kubernetes 集群发送的每个请求。您可以使用 Rego 政策语言创建政策，该语言可让您完全控制提交至集群的资源类型及其配置。

下图中的架构显示使用 Policy Controller 创建资源的请求流：

先定义政策规则，然后使用 kubectl 和 API 客户端等各种工具应用该规则。

您将在 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 集群的共享基础架构。流水线是 Google Cloud 项目中名为 create-infra 的 Cloud Build 触发器，与基础架构代码库 gke-infrastructure-repo 相关联。您可以按照 GitOps 方法创建基础架构，如使用 Cloud Build 基础架构即代码流水线规模化创建可重复的 GCP 环境视频中所述。

gke-infrastructure-repo 具有开发、预演和生产分支。该代码库中还有开发、预演和生产文件夹，分别对应于这些分支。代码库中有分支保护规则，用于确保代码只能推送到开发分支。如需将代码推送到预演分支和生产分支，您需要创建拉取请求。

通常，有权访问代码库的人员会审核更改，然后合并拉取请求，以确保仅将预期更改提升到较高的分支。为了让个人试用蓝图，分支架构在参考架构中已放宽，以便代码库管理员可以绕过审核并合并拉取请求。

推送到 gke-infrastructure-repo 时，它会调用 create-infra 触发器。该触发器可识别推送所在的分支，并转到该分支上代码库的相应文件夹。找到相应的文件夹后，它会使用文件夹包含的文件运行 Terraform。例如，如果将代码推送到开发分支，则触发器会在开发分支的开发文件夹上运行 Terraform 以创建开发 GKE 集群。同样，当推送到 staging 分支时，触发器会在预演分支的预演文件夹上运行 Terraform 以创建预演 GKE 集群。

运行流水线以创建 GKE 集群：

  1. 在 Google Cloud 控制台中，转到 Cloud Build 页面。

    转到 Cloud Build 页面

    • 有五个 Cloud Build Webhook 触发器。查找名为 create-infra 的触发器。此触发器会创建共享基础架构，包括 GKE 集群。

  2. 点击触发器名称。触发器定义随即打开。

  3. 点击打开编辑器，以查看触发器运行的步骤。

    当您在借助 GKE 实现现代 CI/CD：应用开发者工作流中初始配置应用时，便会使用其他触发器。

    Cloud Build 触发器。

  4. 在 Google Cloud 控制台中，转到 Cloud Build 页面。

    转到“Cloud Build 历史记录”页面

    查看历史记录页面上存在的流水线。当您使用 bootstrap.sh 部署软件交付平台时，脚本会将代码推送到启动该流水线并创建开发 GKE 集群的 gke-infrastructure-repo 代码库的开发分支。

  5. 如需创建预演 GKE 集群，请将开发分支中的拉取请求提交到预演分支：

    1. 转到 GitHub 并导航到代码库 gke-infrastructure-repo。

    2. 点击拉取请求，然后点击新建拉取请求。

    3. 在基本菜单中，选择预演，然后在比较菜单中，选择开发。

    4. 点击创建拉取请求。

  6. 如果您是代码库的管理员，请合并拉取请求。否则，请让管理员合并拉取请求。

  7. 在 Google Cloud 控制台中，进入 Cloud Build 历史记录页面。

    转到“Cloud Build 历史记录”页面

    第二个 Cloud Build 流水线在项目中启动。此流水线创建预演 GKE 集群。

  8. 如需创建生产 GKE 集群，请将 pull request 从预演环境提交到生产环境分支：

    1. 转到 GitHub 并导航到代码库 gke-infrastructure-repo。

    2. 点击拉取请求，然后点击新建拉取请求。

    3. 在基本菜单中，选择生产，在比较菜单中，选择预演。

    4. 点击创建拉取请求。

  9. 如果您是代码库的管理员，请合并拉取请求。否则，请让管理员合并拉取请求。

  10. 在 Google Cloud 控制台中，进入 Cloud Build 历史记录页面。

    转到“Cloud Build 历史记录”页面

    第三个 Cloud Build 流水线在项目中启动。此流水线创建生产 GKE 集群。

基础架构

在本部分中，您将探索由流水线创建的基础架构。

  • 在 Google Cloud 控制台中，转到 Kubernetes 集群页面。

    转到“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 账号收取费用，您可以删除项目或手动移除资源。

删除项目

  1. 在 Google Cloud 控制台中，进入管理资源页面。

    转到“管理资源”

  2. 在项目列表中，选择要删除的项目，然后点击删除。
  3. 在对话框中输入项目 ID，然后点击关闭以删除项目。

手动移除资源

  • 在 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

后续步骤