验证配置

除手动或作为预提交钩子在本地运行 nomos vet 外,我们建议您验证 CI/CD 流水线中的所有配置更改。本指南介绍如何在使用 GKE 集群时通过 Cloud Build 验证配置。经过少量更改后,同样的设置也适用于任何其他基于容器的 CI/CD 系统,例如 CircleCI。

准备工作

要遵照本指南操作,您必须首先完成 Anthos Config Management 快速入门

配置 Cloud Build

启用 Cloud Build API

gcloud

要启用 Cloud Build API,请运行以下命令:

gcloud services enable cloudbuild.googleapis.com

控制台

启用 Cloud Build API

授予 Cloud Build 服务帐号访问 GKE 集群的权限

gcloud

如需将 Kubernetes Engine Developer 角色添加到 Cloud Build 服务帐号,请运行以下命令:

PROJECT_ID=$(gcloud config get-value project)
PROJECT_NUM=$(gcloud projects list --filter="$PROJECT_ID" --format="value(PROJECT_NUMBER)")
gcloud projects add-iam-policy-binding $PROJECT_ID \
  --member=serviceAccount:$PROJECT_NUM@cloudbuild.gserviceaccount.com \
  --role=roles/container.developer

控制台

  1. 在 Cloud Console 中打开 Cloud IAM 页面。

    转到 Cloud IAM 页面

  2. 会员列中找到 Cloud Build 服务帐号:

    [PROJECT_NUMBER]@cloudbuild.gserviceaccount.com

  3. 点击该行的铅笔图标。

  4. 点击添加其他角色,选择“Kubernetes Engine Developer”,然后点击保存

创建 Cloud Build 配置

创建 Cloud Build 配置文件并将其存储在包含配置文件的代码库的根目录下(例如 my-repo/cloudbuild.yaml):

steps:
- name: 'gcr.io/cloud-builders/kubectl'
  args: ['config', 'current-context']
  volumes:
  - name: 'kube'
    path: '/kube'
  env:
  - 'KUBECONFIG=/kube/config'
  - 'CLOUDSDK_COMPUTE_ZONE=[ZONE]'
  - 'CLOUDSDK_CONTAINER_CLUSTER=[CLUSTER_NAME]'
  - 'CLOUDSDK_CONTAINER_USE_APPLICATION_DEFAULT_CREDENTIALS=true'
- name: 'bash'
  args: ['chmod', '444', '/kube/config']
  volumes:
  - name: 'kube'
    path: '/kube'
- name: 'gcr.io/config-management-release/nomos:stable'
  args: ['nomos', 'vet', '--path', '/workspace/[POLICY_DIR]']
  volumes:
  - name: 'kube'
    path: '/kube'
  env:
  - 'KUBECONFIG=/kube/config'
  timeout: 30s

其中,ZONE 是集群运行的地区,CLUSTER_NAME 是集群的名称,POLICY_DIR 是 Git 代码库中的路径,表示要同步的代码库的顶层目录。

此配置包含三个步骤:

  1. 运行 kubectl config current-context 以生成向 my-cluster GKE 集群进行身份验证所需的 kubeconfig 文件。根用户生成的此文件具有受限的权限。
  2. 运行 chmod 444 /kube/config 使此文件在一步中可被读取。
  3. 对在 /workspace 中自动克隆的 Git 代码库运行 nomos vet

创建构建触发器

以下示例将创建一个触发器。当每次提交到 Cloud Source Repo 的主分支时,该触发器会运行。使用上一步中的 Cloud Build 配置文件:

  1. 在 Cloud Console 中打开“触发器”页面。

    转到“触发器”页面

  2. 点击连接代码库

  3. 选择 GitHub(已创建镜像),然后点击继续

  4. 选择您的代码库,然后点击关联代码库

  5. 点击添加触发器

  6. 在下表中的每个字段中输入或选择相应的条目:

    字段 条目
    事件 推送到分支
    分支 ^master$
    构建配置文件类型 Cloud Build 配置文件(yaml 或 json)
    Cloud Build 配置文件位置 / cloudbuild.yaml
  7. 点击创建以保存您的构建触发器。

测试构建触发器

您可以通过手动运行触发器来测试设置。

  1. 在 Cloud Console 中打开“触发器”页面。

    转到“触发器”页面

  2. 找到您创建的触发器,然后点击运行触发器

    系统会显示消息“已启动‘master’分支的构建 显示”。

  3. 点击显示

    如果设置正确,Cloud Build 步骤会显示为绿色。

Cloud Build 配置无效

如果 Cloud Build 配置文件无效,则触发器无法运行。

例如,将您的代码库中的 Cloud Build 配置更新为以下文件。请注意第 6 行中的无效缩进:

steps:
- name: 'gcr.io/cloud-builders/kubectl'
  args: ['config', 'current-context']
  volumes:
  - name: 'kube'
  path: '/kube'
  env:
  - 'KUBECONFIG=/kube/config'
  - 'CLOUDSDK_COMPUTE_ZONE=[ZONE]'
  - 'CLOUDSDK_CONTAINER_CLUSTER=[CLUSTER_NAME]'
  - 'CLOUDSDK_CONTAINER_USE_APPLICATION_DEFAULT_CREDENTIALS=true'
- name: 'bash'
  args: ['chmod', '444', '/kube/config']
  volumes:
  - name: 'kube'
    path: '/kube'
- name: 'gcr.io/nomos-release/nomos:stable'
  args: ['nomos', 'vet', '--path', '/workspace/[POLICY_DIR]']
  volumes:
  - name: 'kube'
    path: '/kube'
  env:
  - 'KUBECONFIG=/kube/config'
  timeout: 30s

如果您再次手动运行触发器,则会收到以下错误消息,因为第 6 行上的 path: 未正确缩进:

Failed to trigger build: failed unmarshalling build config cloudbuild.yaml:
unknown field "path" in cloudbuild_go_proto.BuildStep.

如需更正此配置,请缩进第 6 行的 path:,使其与第 5 行的 name: 齐平。如需详细了解 Cloud Build 配置文件的结构,请参阅创建基本 Cloud Build 配置

后续步骤