为“基础架构即代码”使用建议

概览

Google Cloud Policy Intelligence 有助于企业了解和管理其政策,从而降低相关风险。通过提供更多可见性和自动化功能,客户可以在不增加工作量的情况下提高安全性。

Recommender 使您可以检索 Google Cloud 资源的建议,从而帮您提高云安全性、节省费用等。如需查看受支持的建议列表,请参阅 Recommender 文档。本教程介绍如何使用虚拟机实例的容量建议以及 Identity and Access Management (IAM) 建议。Recommender 使用机器学习为管理员提供建议,以移除对 Google Cloud 资源不必要的访问,以及调整 Compute Engine 实例的容量,以便更高效的利用资源。

每项建议都包含建议的操作及其影响。在审查了针对确定的影响的建议以及特定于您的环境的其他考虑事项之后,您可以选择要采纳的建议。您可以通过 Google Cloud Console 手动采纳建议,也可以将其作为代码流水线集成到基础架构中,通过程序化方式采纳这些建议。

基础设施即代码 (IaC) 可让您自动创建 Google Cloud 资源。您必须保持最新的 IaC 代码库并通过它路由对 Google Cloud 组织进行的更改。当严格地执行 IaC 策略并将其作为云基础架构的唯一版本时,组织中的 IaC 策略通常被证明是有益的。保持 IaC 存储库是最新的,这对于防止 IaC 代码库反映的基础设施版本与组织中所拥有的版本之间的偏移至关重要。

IAM 建议

除了其他主要实践中,一个常见的做法是最小特权的安全原则,以及仔细考虑如何对组织进行更改并与 IaC 代码库同步。

虚拟机的容量建议

容量建议通过提供有关如何调整实例的机器类型容量的建议,帮助您更高效地使用实例资源,从而降低费用

本教程介绍如何架构和构建自动化流水线,以便以编程方式应用 Policy Intelligence 建议。作为这种自动化流水线的一部分,您将了解如何根据适用于 Recommender 的虚拟机容量和 IAM 政策绑定建议,使用对 Google Cloud 组织所做的更改来使基础设施即代码 (IaC) 代码库保持最新状态。

本教程使用 Hashicorp Terraform 作为 IaC 工具,但是即使您正在使用其他 IaC 管理工具(如Deployment Manager),也可以利用上述自动化流水线中使用的体系结构模式和组件。您需要修改本教程提供的开源代码库,以适应您的特定 IaC 实现。

本指南面向可能负责 Google Cloud 管理、安全性和基础架构规划的架构师、产品所有者和开发者。

自动化流水线架构

下图展示了此自动化流水线中使用的组件。

自动化流水线中的组件

已安排的 Cloud Scheduler 作业运行 Recommender Parser 服务。该服务调用 Recommender API 来检索指定项目的 Recommender 建议。然后,它会解析这些虚拟机容量和 IAM 建议,并将它们映射到 Terraform 清单中的配置。该服务会更新 IaC 清单以反映这些建议。它会生成一个包含更改的拉取请求,以便您查看更新。在查看并合并拉取请求后,Cloud Build 作业将对 Google Cloud 组织中的基础架构进行更改。

流水线中使用的多项辅助 Google Cloud 服务,可用于跟踪已处理的建议,在构建完成时生成通知和存储 Terraform 状态。在本教程中,您将进一步了解这些服务。

以下列表介绍了组件角色和访问权限控制要求:

Platform Intelligence Recommenders
角色:生成安全和虚拟机容量建议

访问权限控制:Google Cloud 服务帐号必须具有所需的 IAM 权限才能使用 Recommender API 检索建议。

查看 Recommender 角色和权限,以选择适用于运行 Recommender-parser 服务的服务帐号的最合适角色。

Cloud Scheduler

角色:Cloud Scheduler 运行 Recommender Parser 服务。通过 Cloud Scheduler,您可以设置多个作业,并且可以根据需要调用解析器服务的多个实例。每次调用都需要传入以下输入

  • 应处理建议的项目列表
  • 建议类型
  • IaC 代码库名称

访问权限控制:您可以使用为调用解析器服务而创建的特定服务帐户运行 Cloud Scheduler 作业。

创建或标识一个 Google Cloud 服务帐号,用于 Cloud Scheduler 对 Recommender Parser 服务的调用。

向服务帐号授予 Cloud Scheduler Service Agent 角色,使其可以运行 Cloud Scheduler 作业。此外,请向服务帐号授予 Cloud Run Invoker 角色,因为该帐号会调用 Cloud Run 服务

如需了解详情,请参阅有关如何为调度程序作业配置经过身份验证的访问权限的文档。

Cloud Run 服务

角色:Recommender-parser 服务存储所有处理逻辑。它有多个路由,每个路由都有一个特定的用途:

  • 解析每种建议类型的建议。
  • 更新正在处理的建议的状态

访问权限控制:使用 IAM 管理对此服务的访问权限

此外,将服务分配到一个专用服务帐号。这样可以确保只有该服务才能调用其他服务,例如 Firestore。

Hashicorp Terraform

角色:Terraform 0.12 是基础架构即代码工具。

Terraform 的 Cloud Build 构建器用于调用 Terraform 命令,Cloud Build 服务帐号也用于此目的。

Cloud Build

角色:Google Cloud Build 根据每个政策智能建议的对 IaC 清单所做的更改自动部署基础架构。

访问权限控制:Cloud Build 服务帐号必须具有可与测试项目中的资源进行交互的适当权限组。

请参阅配置 Cloud Build 服务帐号文档。

GitHub

角色:IaC 代码库使用 GitHub 进行源代码控制。GitHub 中的 IaC 代码库已与 Cloud Build 集成。当提交递交到主分支时,会触发 Cloud Build 作业运行一组预配置任务。

访问权限控制:您需要生成 SSH 密钥来启用对 IaC 代码库的访问权限。

此外,您需要生成个人访问令牌,用于将提交推送到 GitHub。

Firestore

Firestore 是一个全代管式的可扩缩的 NoSQL 文档数据库,此架构用于保存与 Recommender Parser 服务解析的建议 ID 相关的信息以及与 Git 提交相关的详细信息。

Firestore 中保留的详细信息在端到端流水线的反馈环中发挥着不可或缺的作用。在提取 Recommender API 生成的建议之后和处理该建议之前,该服务会将建议的状态标记为 CLAIMED。成功采纳建议后,服务会查询数据库以检索 Cloud Build 作业已成功采纳的建议 ID,并将建议状态更改为 SUCCEEDED。如果 Cloud Build 作业失败,建议状态会更改为 FAILED

访问权限控制:如需了解详情,请参阅 Firestore 角色。roles/datastore.user 角色需要使用 Recommender-parser 服务从 Firestore 读取数据。

Pub/Sub

角色:Cloud Build 会在构建状态更改时(例如,创建构建时、构建转换到工作状态时、构建完成时)在 Pub/Sub 主题上发布消息。

Cloud Build 将消息发布到名为 Cloud-Build 的 Pub/Sub 主题,并且在您启用项目中的 Cloud Build API 时,自动为您创建该主题。

访问权限控制:推送订阅可以配置为提供身份验证标头,以允许服务对请求进行授权。如需了解详情,请参阅使用推送订阅

目标

  • 构建自动化流水线以
    • 主动监控平台 Policy Intelligence 建议
    • 解析建议并将更新应用于现有 IaC 代码库
  • 了解如何使用一套 Google Cloud 服务、Hashicorp TerraformGitHub 来构建此流水线。
  • 了解构建此流水线需要遵循的假设和最佳做法
  • 测试流水线

费用

本教程使用 Google Cloud 的以下收费组件:

  • Cloud Run
  • Cloud Build
  • Compute Engine
  • Cloud Storage
  • Firestore
  • 发布/订阅
  • Cloud Scheduler
  • Recommender

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

准备工作

本教程假定您拥有 GitHub 帐号,并熟悉 GitNode.jsTerraformDocker

版本说明和假设

在如何使用 IaC 工具和清单方面有很多可变性。

查看以下信息,以确定本教程是否适合您的 IaC 流水线以及可能需要进行哪些类型的更改。

  • 此流水线使用 Terraform ver. 0.12。HCL 配置语法的重大更改或对 Terraform 状态文件结构的更改可能会带来重大问题。
  • 此流水线假设 IaC 目录结构未嵌套,并且一个 IaC 代码库可管理一个或多个 Google Cloud 项目中的资源。
  • Terraform 变量作为环境变量传入,不支持命令行参数。该原型假定 Terraform 变量的声明性配置位于 tfvars 文件中。
  • 当角色的某权限子集在 60 天内未使用时,Recommender 会生成 IAM 建议,而虚拟机容量建议遵循类似的模式。在本教程中,我们提供了可用于测试流水线的示例建议负载。
  • 此版本不支持 Terraform 中的循环
  • 不支持 Terraform 模块。代码库是开源的,并假设您会对解析流进行必要的特定增强,以适应您的目录结构和模块的使用。

当前版本的开源 Recommender 解析器服务已遵循以下 IAM 建议限制:

前提条件

  1. 选择或创建两个 Google Cloud 项目。

    转到项目选择器页面

    • 托管和运行自动化流水线的构建项目。
    • 托管用于测试自动化流水线的 Google Cloud 资源的 测试 项目。
  2. 确保您的 Google Cloud 项目已启用结算功能。 了解如何确认您的项目已启用结算功能

  3. 测试项目中,启用 Compute Engine API。

    启用 API

  4. 构建 项目中,启用 Cloud Run、Firestore、Pub/Sub 和 Cloud Scheduler、IAM 和 CloudResourceManager API。

    启用 API

完成本教程后,您可以删除所创建的资源以避免继续计费。如需了解详情,请参阅清理

设置环境

  1. 在 Cloud Console 中,选择您的 build 项目。
  2. 在 Cloud Console 中,转到 Cloud Shell。

    转到 Cloud Shell

    Cloud Shell 会话随即会在 Cloud Console 的底部打开,并显示命令行提示。Cloud Shell 是一个已安装 Cloud SDK 的 shell 环境,其中包括 gcloud 命令行工具以及已为当前项目设置的值。该会话可能需要几秒钟来完成初始化。

    请使用 Cloud Shell 执行本教程中的所有终端命令。

  3. 使用以下命令创建环境变量,来保存 build 项目的项目编号:

    export BUILD_PROJECT_ID=$DEVSHELL_PROJECT_ID
    
  4. 创建环境变量来保存 test 项目的项目编号。手动复制测试项目 ID,并将 PROJECT-ID 替换为测试项目 ID。

    export TEST_PROJECT_ID=PROJECT-ID
    
  5. 您可以为整个教程中使用的值(例如区域和地区)分配默认设置。本教程使用 us-central1 作为默认区域,使用 us-central1-b 作为默认地区。

  6. 通过运行以下命令为本教程设置默认区域和地区:

    gcloud config set compute/zone us-central1-b --project $BUILD_PROJECT_ID
    gcloud config set compute/zone us-central1-b --project $TEST_PROJECT_ID
    
  7. build 项目设置为默认项目:

    gcloud config set project $BUILD_PROJECT_ID
    
  8. build 项目编号创建一个名为 BUILD_PROJECT_NUMBER 的环境变量

    export BUILD_PROJECT_NUMBER=$(gcloud projects describe $DEVSHELL_PROJECT_ID --format='value(projectNumber)')
    
  9. 克隆本教程的 GitHub 代码库

为 Terraform State 创建存储分区

在构建项目中创建 Cloud Storage 存储分区以存储 Terraform 状态文件。

gsutil mb -p ${BUILD_PROJECT_ID} -l us-central1 \
 gs://recommender-tf-state-$BUILD_PROJECT_ID

创建一个 GitHub 代码库。

创建一个 GitHub 代码库作为 IaC 代码库示例

  1. 创建一个新的非公开 GitHub 代码库。在本教程中,此 IAC-REPO-NAME 代码库可用作 IaC 代码库

  2. 在以下步骤中,您需要将克隆代码库的 sample-iac 子目录中的文件推送到 GitHub 帐号。

    1. 在 Cloud Shell 中,将 sample-iac 目录复制到主目录。您可使用此目录创建一个新的本地代码库,并将其推送到 GitHub。

      cp -r recommender-iac-pipeline-nodejs-tutorial/sample-iac $HOME
      
    2. 导航到新目录

      cd $HOME/sample-iac
      
    3. 在本地机器上初始化代码库。

      git init
      
    4. 添加 IAC-REPO-NAME 为远程代码库,并将 IAC-REPO-NAMEGITHUB-ACCOUNT 替换为适当的值

      git remote add origin
      https://github.com/GITHUB-ACCOUNT/IAC-REPO-NAME
      
    5. 将此代码库的文件中的占位符替换为 test 项目 ID 和 Terraform Cloud Storage 存储分区名称。

      sed -i "s|__PROJECT_ID__|${TEST_PROJECT_ID}|g" ./terraform.tfvars
      
      sed -i "s|__STATE_BUCKET_NAME__|recommender-tf-state-$BUILD_PROJECT_ID|g" ./backend.tf
      
    6. 添加、提交并推送到 GitHub。

      git add .
      git commit -m "First Commit"
      git push origin master
      
    7. 出现提示时,请登录您的 GitHub 帐号。

为代码库生成 SSH 密钥

使用 GitHub 中的 IaC 代码库设置 SSH 密钥身份验证,并将密钥上传到 Cloud Storage。

  1. 为 GitHub 代码库生成 SSH 密钥。

    1. 生成 SSH 密钥对将 *your_email@example.com* 替换为您的 GitHub 电子邮件地址。在 Cloud Shell 中:

      ssh-keygen -t rsa -b 4096 -C "your_email@example.com"
      
    2. 当系统提示“输入保存密钥的文件”时,请按 Enter 键。此操作接受默认文件位置。

    3. 在提示输入密码时,请按 Enter 键。

  2. 记下您保存下载的 SSH 密钥的目录 SSH-KEYS-DIR。默认情况下,位置为 $HOME/.ssh/

  3. 将生成的 SSH 公钥作为部署密钥复制到 GitHub 代码库。

    1. 复制您在 Cloud Shell 中生成的 SSH 公钥。将 SSH-KEYS-DIR 替换为您的目录路径。

      cat SSH-KEYS-DIR/id_rsa.pub
      
    2. 在 GitHub 帐号中,导航到 IAC-REPO-NAME 代码库

    3. 点击设置 > 部署密钥

    4. 点击添加部署密钥,然后粘贴您复制的 SSH 公钥。为该密钥选择标题

    5. 选中“允许写入权限”复选框

    6. 点击保存

  4. 导航回 Cloud Shell 会话

  5. 为 GitHub 创建 known_hosts 文件。在 Cloud Shell 会话中,运行以下命令:

    ssh-keyscan github.com >> ~/.ssh/known_hosts
    
  6. build 项目中创建一个 Cloud Storage 存储分区,并将 SSH 密钥和 known_hosts 文件上传到其中。将 SSH-KEYS-DIR 替换为生成 SSH 密钥的目录的路径。

    gsutil mb -p ${BUILD_PROJECT_ID} -l us-central1 gs://github-keys-$BUILD_PROJECT_ID
    
    gsutil cp SSH-KEYS-DIR/id_rsa* gs://github-keys-$BUILD_PROJECT_ID
    gsutil cp SSH-KEYS-DIR/known_hosts gs://github-keys-$BUILD_PROJECT_ID
    
  7. 为 GitHub 生成个人访问令牌。在使用 Recommender-parser 服务生成拉取请求和签入更新的 IaC 清单的 API 调用执行 Git 操作时,会使用此令牌。

    1. 在 GitHub 帐号中,在任意页面的右上角,点击您的个人资料照片,然后点击设置

    2. 在左侧边栏,点击开发者设置

    3. 在左侧边栏,点击个人访问令牌

    4. 点击“生成新令牌”。

    5. 为您的令牌指定一个描述性名称。

    6. 选择代码库的范围。

    7. 点击 生成令牌

    8. 将令牌复制到剪贴板。

    9. 在 Cloud Shell 会话中,创建环境变量。

      export GITHUB_PAT=<personal-access-token-you-copied>
      

设置 Cloud Build

  1. 连接 IAC-REPO-NAME Git 代码库与 Cloud Build 集成。

    1. 转到 GitHub Marketplace 中的 Cloud Build 应用页面
    2. 向下滚动,然后点击页面底部的使用 Google Cloud Build 进行设置 (Setup with Google Cloud Build)。
    3. 如果系统提示,请登录 GitHub
    4. 选择仅选择代码库。使用选择代码库下拉列表仅允许在 Cloud Build 应用中访问 IAC-REPO-NAME
    5. 点击安装
    6. 登录 Google Cloud。

      随即将显示授权页面,在该页面中系统会要求您授权 Google Cloud Build 应用连接到 Google Cloud。

    7. 点击授权 Google Cloud Build by GoogleCloudBuild (Authorize Google Cloud Build by GoogleCloudBuild)。 系统会将您重定向至 Cloud Console。

    8. 选择您的 Google Cloud 项目。

    9. 选中同意复选框,然后点击下一步

    10. 在显示的选择代码库页面中,选择 IAC-REPO-NAME GitHub 代码库

    11. 点击连接代码库

    如需了解详情,请参阅在 GitHub 上运行构建

  2. 点击创建推送触发器。这样即可为您创建一个触发器。

  3. 复制的目录包含 cloudbuild.yaml 文件。此配置文件概述了 Cloud Build 作业触发时执行的步骤。

    steps:
    - name: hashicorp/terraform:0.12.0
      args: ['init']
    - name: hashicorp/terraform:0.12.0
      args: ['apply', '-auto-approve']
    
  4. 向您的 Cloud Build 服务帐号添加权限,使其能够在测试项目中创建服务帐号、关联角色和虚拟机(Compute Engine 实例)

    gcloud projects add-iam-policy-binding $TEST_PROJECT_ID \
      --member serviceAccount:$BUILD_PROJECT_NUMBER@cloudbuild.gserviceaccount.com \
      --role roles/compute.admin \
      --project $TEST_PROJECT_ID
    
    gcloud projects add-iam-policy-binding $TEST_PROJECT_ID \
      --member serviceAccount:$BUILD_PROJECT_NUMBER@cloudbuild.gserviceaccount.com \
      --role roles/iam.serviceAccountAdmin \
      --project $TEST_PROJECT_ID
    
    gcloud projects add-iam-policy-binding $TEST_PROJECT_ID \
    --member serviceAccount:$BUILD_PROJECT_NUMBER@cloudbuild.gserviceaccount.com \
    --role roles/iam.securityAdmin \
    --project $TEST_PROJECT_ID
    
  5. 在 Cloud Console 中打开构建触发器页面

  6. 选择 build 项目,点击打开

  7. 更新触发器的定义:

    1. 点击运行触发器右侧的修改
    2. 分支(正则表达式)文本字段中,输入 master
    3. 构建配置部分,选择 Cloud Build 配置文件选项,然后在文本字段中输入 cloudbuild.yaml
    4. 点击保存
  8. 要手动测试构建触发器,请点击触发器列表中触发器条目上的运行触发器

  9. 验证在上一步中运行的 Cloud Build 作业在测试项目中创建了一个名为 tf-compute-1 的 Compute Engine 实例和一个名为 Terraform Recommender Test 的服务帐户

部署 Recommender-parser Cloud Run 服务

  1. 在 Cloud Shell 中,将目录更改为通过克隆代码库创建的目录

    cd $HOME/recommender-iac-pipeline-nodejs-tutorial/parser-service
    
  2. 将 Google Cloud 配置为使用 Cloud Run 服务的默认区域。在本教程中,您可以使用 us-central1 区域,也可以根据需要选择其他受支持的区域。

    gcloud config set run/region us-central1
    
  3. parser-service 目录有一个存根子目录,其中包含一些示例负载 JSON,以便您用来测试 Recommender-parser 服务。运行以下 sed 命令,将这些 JSON 中的 PROJECT_ID 占位符替换为测试项目 ID。

    sed -i "s|__PROJECT_ID__|${TEST_PROJECT_ID}|g" ./stub/iam.json
    sed -i "s|__PROJECT_ID__|${TEST_PROJECT_ID}|g" ./stub/vm.json
    
  4. 运行以下命令,为 Docker 映像创建环境变量。

    export IMAGE=gcr.io/$BUILD_PROJECT_ID/recommender-parser:1.0
    
  5. 构建映像并上传到 Container Registry

    gcloud builds submit --tag $IMAGE .
    
  6. 为 Recommender-parser 服务创建服务帐号,以便与流水线中的其他 Google Cloud 服务进行交互。为 Cloud Run 服务授予精细权限是一种很好的做法。如需了解详情,请参阅 Cloud Run 服务身份

    gcloud beta iam service-accounts create recommender-parser-sa \
      --description "Service account that the recommender-parser service uses to invoke other GCP services" \
      --display-name "recommender-parser-sa" \
      --project $BUILD_PROJECT_ID
    
  7. Recommender-parser 服务需要访问您上传到之前创建的 Cloud Storage 存储分区的 GitHub SSH 密钥和 Terraform 状态。将服务帐号作为成员添加到 Cloud Storage 存储分区。

    gsutil iam ch serviceAccount:recommender-parser-sa@$BUILD_PROJECT_ID.iam.gserviceaccount.com:objectCreator,objectViewer \
    gs://github-keys-$BUILD_PROJECT_ID
    
    gsutil iam ch serviceAccount:recommender-parser-sa@$BUILD_PROJECT_ID.iam.gserviceaccount.com:objectCreator,objectViewer \
    gs://recommender-tf-state-$BUILD_PROJECT_ID
    
  8. 为 Recommender-parser 服务服务帐号授予对 Firestore 和 Recommender API 的访问权限。

    gcloud projects add-iam-policy-binding $BUILD_PROJECT_ID \
      --member serviceAccount:recommender-parser-sa@$BUILD_PROJECT_ID.iam.gserviceaccount.com \
      --role roles/datastore.user
    
    gcloud projects add-iam-policy-binding $TEST_PROJECT_ID \
      --member serviceAccount:recommender-parser-sa@$BUILD_PROJECT_ID.iam.gserviceaccount.com \
      --role roles/recommender.iamAdmin
    
    gcloud projects add-iam-policy-binding $TEST_PROJECT_ID \
      --member serviceAccount:recommender-parser-sa@$BUILD_PROJECT_ID.iam.gserviceaccount.com \
      --role roles/recommender.iamViewer
    
    gcloud projects add-iam-policy-binding $TEST_PROJECT_ID \
      --member serviceAccount:recommender-parser-sa@$BUILD_PROJECT_ID.iam.gserviceaccount.com \
      --role roles/recommender.computeAdmin
    
  9. 通过运行命令来部署名为 recommender-parser 的 Cloud Run 服务。接受所有系统提示。

    gcloud beta run deploy \
     --image=${IMAGE} \
     --no-allow-unauthenticated \
     --region us-central1 \
     --platform managed \
     --service-account recommender-parser-sa@$BUILD_PROJECT_ID.iam.gserviceaccount.com \
    --set-env-vars="GITHUB_ACCOUNT=github.com:GITHUB-ACCOUNT,GITHUB_PAT=${GITHUB_PAT},SSH_KEYS_BUCKET=github-keys-${BUILD_PROJECT_ID},TERRAFORM_STATE_BUCKET=recommender-tf-state-$BUILD_PROJECT_ID" \
     --project $BUILD_PROJECT_ID \
     recommender-parser
    

设置 Firestore

  1. 在 Google Cloud Console 的 build 项目中,导航到 Firestore 页面
  2. 当系统提示您选择模式时,请点击选择原生模式
  3. 选择 us-east1 作为默认位置
  4. 点击创建数据库
  5. 点击开始收集合
  6. 集合 ID 中,输入 applied-recommendations
  7. 点击保存

recommender-parser 服务为实现以下目的会将文档写入此集合:

  • 跟踪从 Recommender API 检索到的建议
  • 在处理完建议后,请调用 Recommender API 根据需要将每条已处理建议的状态更新为 SUCCEEDEDFAILED。这是通过确保流水线不会被不完全或多次处理,进而实现流水线幂等的关键步骤。

设置 Cloud Scheduler 作业

  1. 创建 Cloud Scheduler 作业用于运行 Recommender-parser 服务的服务帐号。

    gcloud beta iam service-accounts create recommender-scheduler-sa \
      --description "Service Account used by Cloud Scheduler to invoke the recommender-parser service" \
      --display-name "recommender-scheduler-sa" \
      --project $BUILD_PROJECT_ID
    
  2. 为服务帐号授予 run/invoker 角色,以便其调用 Cloud Run 服务。

    gcloud beta run services add-iam-policy-binding recommender-parser \
    --member=serviceAccount:recommender-scheduler-sa@$BUILD_PROJECT_ID.iam.gserviceaccount.com \
    --role=roles/run.invoker \
    --region=us-central1
    
  3. 获取 Recommender-service 网址:

    gcloud beta run services list --platform managed --project $BUILD_PROJECT_ID
    

    Cloud Scheduler 作业会调用 Recommender-parser 服务的 /recommendation/iam 路由来解析 IAM 建议,并调用 /recommender/vm 路由来解析虚拟机容量建议。

  4. 为 Cloud Scheduler 作业调用的端点创建变量。将 RECOMMENDER-SERVICE-URL 替换为您在上一步中复制的 Recommender-service 网址。

    export RECOMMENDER_ROUTE_TO_INVOKE_IAM=RECOMMENDER-SERVICE-URL/recommendation/iam
    

    附加路由信息后,您的网址应跟此示例网址类似:

    https://RECOMMENDER-SERVICE-URL/recommendation/iam
    
  5. 创建名为 recommender-iam-scheduler. 的 Cloud Scheduler 作业

    • 根据您的位置更改所选时区。
    • <you-iac-repo> 替换为您创建的 GitHub 代码库名称。

    消息正文获取三个输入,您必须按照如下所示构建它:

  6. repo:这是您在创建 GitHub 代码库中创建的 GitHub 代码库 IAC-REPO-NAME 的名称。

  7. projects:此 IaC GitHub 代码库映射到的 Google Cloud 项目 ID 的列表/数组。在本教程中,它是您的 test 项目。

  8. stub:当角色的某权限子集在 60 天内未使用时,Recommender 会生成 IAM 建议,而虚拟机容量建议遵循类似的模式为了按需测试此流水线,可将 stub 作为 true 传入,以便使用为本教程克隆的代码库中提供的示例 Recommender 负载来测试流水线。

    gcloud beta scheduler jobs create http recommender-iam-scheduler \
      --project $BUILD_PROJECT_ID \
      --time-zone "America/Los_Angeles" \
      --schedule="0 */3 * * *" \
      --uri=$RECOMMENDER_ROUTE_TO_INVOKE_IAM \
      --description="Scheduler job to invoke recommendation pipeline" \
    --oidc-service-account-email="recommender-scheduler-sa@$BUILD_PROJECT_ID.iam.gserviceaccount.com" \
      --headers="Content-Type=application/json" \
      --http-method="POST" \
      --message-body="{ \"repo\": \"<var>IAC-REPO-NAME</var>\", \"projects\": [\"$TEST_PROJECT_ID\"], \"stub\": true }"
    

其他步骤

Cloud Build 将构建信息发布到名为 cloud-builds 的 Pub/Sub 主题,并且在您启用构建项目中的 Cloud Build API 时,自动为您创建该主题。

  1. 创建 Pub/Sub 用于调用 Recommender-parser 服务端点的服务帐号。

    gcloud beta iam service-accounts create recommender-ci-subscription-sa \
      --description "Service Account used by Cloud Pub/Sub to push Cloud Build events to the recommender-parser service" \
      --display-name "recommender-ci-subscription-sa"
      --project $BUILD_PROJECT_ID
    
  2. Pub/Sub 服务帐号应与发布消息和调用 Recommender-parser 服务所需的角色相关联。

    gcloud projects add-iam-policy-binding $BUILD_PROJECT_ID \
      --member serviceAccount:recommender-ci-subscription-sa@$BUILD_PROJECT_ID.iam.gserviceaccount.com \
      --role roles/pubsub.publisher \
      --project $BUILD_PROJECT_ID
    
    gcloud projects add-iam-policy-binding $BUILD_PROJECT_ID \
      --member serviceAccount:recommender-ci-subscription-sa@$BUILD_PROJECT_ID.iam.gserviceaccount.com \
      --role roles/pubsub.subscriber \
      --project $BUILD_PROJECT_ID
    
    gcloud projects add-iam-policy-binding $BUILD_PROJECT_ID \
      --member serviceAccount:recommender-ci-subscription-sa@$BUILD_PROJECT_ID.iam.gserviceaccount.com \
      --role roles/run.invoker \
      --project $BUILD_PROJECT_ID
    
  3. 将您创建的 recommender-ci-subscription-sa 服务帐号作为具有 invoker 角色的成员添加到 Recommender-parser 服务中

    gcloud beta run services add-iam-policy-binding recommender-parser \
    --member=serviceAccount:recommender-ci-subscription-sa@$BUILD_PROJECT_ID.iam.gserviceaccount.com \
    --role=roles/run.invoker --region=us-central1
    
  4. 导航至 Google Cloud Console 中的 Pub/Sub

  5. 点击 cloud-builds 主题。

  6. 点击创建订阅

  7. 对于订阅 ID,请输入 recommender-service-build-events

  8. 对于传送类型,选择推送

  9. 勾选启用身份验证

    1. 选择您创建的服务帐号 recommender-ci-subscription-sa
    2. 点击授权以响应提示消息。
  10. 对于端点,输入由 /ci 附加的 Recommender-service 网址。

  11. 选择确认截止时间为 60 秒

  12. 保留其余默认设置。

  13. 点击创建

测试流水线

当角色的某权限子集在 60 天内未使用时,Recommender 会生成 IAM 建议虚拟机容量建议遵循类似的模式。为了根据需要测试此流水线,您可使用为本教程克隆的代码库中提供的 stub 子目录中提供的示例 JSON 负载。这使您可以测试流水线,禁止 Recommender-parser 对 Recommender API 端点发出的 API 调用,以更新它所采纳的建议状态。

或者,如果您的 Google Cloud 项目中具有有效的建议,则可以在不使用存根的情况下端对端测试流水线。下文中列出的结果与您使用示例负载测试流水线相关。但是,在不使用示例的情况下测试此流水线,其步骤仍保持不变。

  1. 在 Cloud Console 中,导航到测试项目并查看已创建的资源。您应具备以下条件:

    1. 名为 tf-compute-1 且机器类型为 g1-small 的 Compute Engine 实例。
    2. 名为 Terraform Recommender Test 的服务帐号,其角色为测试项目的 editor
  2. build 项目的 Cloud Scheduler 控制台页面中,点击 Recommender-iam-scheduler 作业的立即运行

  3. 点击作业查看日志。您还可以查看 Recommender-parser 服务日志,来详细了解服务正在执行的步骤。

  4. 服务完成运行后,会导航到 GitHub IAC-REPO-NAME 代码库。recommender-parser 服务将为您生成拉取请求。检查构成此拉取请求的已修改 IaC 清单,如果您对 IaC 清单的更改感到满意,请点击合并拉取请求

  5. 当您合并拉取请求时,将创建一个新的提交到主分支。这会触发一个 Cloud Build 作业,该作业可将修改发布到 test 项目中的 Google Cloud 资源。请等待 Cloud Build 作业完成,您便可在 Cloud Console 中查看其状态

  6. 作业完成后,导航到您的测试项目。提供的示例负载会对测试项目中的资源进行以下更改。

    • 在部署后,角色为 editor 的 Terraform 测试服务帐号将更改为 viewer

清理

为避免因本教程中使用的资源导致您的 Google Cloud 帐号产生费用,请删除您已创建的两个项目。

为了避免产生费用,最简单的方法是删除您为本教程创建的项目。

如需删除项目,请执行以下操作:

  1. 在 Cloud Console 中,转到管理资源页面。

    转到“管理资源”页面

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

后续步骤

  • 试用其他 Google Cloud 功能。查阅我们的教程
  • 如需详细了解 Google Cloud Policy Intelligence,请参阅文档