Google Cloud Build 与 Artifact Registry 生产级实战：从CI/CD流水线到容器镜像管理与安全扫描

PHP Warning: Invalid argument supplied for foreach() in /usr/share/nginx/html/wp-content/themes/dux/widgets/widget-index.php on line 28
Warning: Invalid argument supplied for foreach() in /usr/share/nginx/html/wp-content/themes/dux/widgets/widget-index.php on line 28

引言：为什么选择 Cloud Build + Artifact Registry

在现代云原生开发中，CI/CD 流水线和容器镜像仓库是基础设施的核心组件。Google Cloud Build 是一个全托管的持续集成/持续交付（CI/CD）平台，无需管理构建服务器即可执行构建、测试和部署；而 Artifact Registry 则是 Google Cloud 推出的统一制品仓库，支持 Docker 镜像、Maven、npm、Python 等多种格式，是 Container Registry 的升级替代品。

两者组合使用可以构建完整的 DevOps 闭环：代码提交 → Cloud Build 自动构建和测试 → 镜像推送至 Artifact Registry → 自动部署到 Cloud Run 或 GKE。本文将深入讲解这两个服务的生产级配置，包括流水线设计、镜像管理、漏洞扫描、权限控制和成本优化。

Cloud Build 核心概念与配置

架构概览

Cloud Build 的工作流程非常直观：它从一个源代码仓库拉取代码，按照

配置文件中定义的步骤依次执行，每个步骤运行在一个独立的 Docker 容器中。所有步骤共享一个挂载的工作区（

），可以传递文件和中间产物。

关键特性包括：

• 全托管：无需预配或管理构建服务器，按构建时间计费
• 步骤隔离：每个步骤运行在独立容器中，可以选择不同的基础镜像
• 并行执行：无依赖关系的步骤可以自动并行运行
• 超长超时：单个构建最长可运行 24 小时
• 私有池：可以使用 Private Pool 在自己的 VPC 中运行构建

cloudbuild.yaml 详解

一个生产级的

通常包含多个阶段：代码检查、单元测试、构建、安全扫描和部署。以下是一个完整的示例：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
steps:

  # 步骤1：代码质量检查

  - name: 'gcr.io/cloud-builders/gcloud'

    entrypoint: 'bash'

    args:

      - '-c'

      - |

        echo "=== Running lint checks ==="

        gcloud config set project $PROJECT_ID



  # 步骤2：运行单元测试

  - name: 'python:3.11-slim'

    entrypoint: 'bash'

    args:

      - '-c'

      - |

        pip install -r requirements.txt

        pip install pytest pytest-cov

        pytest tests/ --cov=src --cov-report=xml --junitxml=test-results.xml

    id: 'unit-tests'



  # 步骤3：构建Docker镜像

  - name: 'gcr.io/cloud-builders/docker'

    args:

      - 'build'

      - '-t'

      - '${_REGION}-docker.pkg.dev/$PROJECT_ID/${_REPO}/myapp:$COMMIT_SHA'

      - '-t'

      - '${_REGION}-docker.pkg.dev/$PROJECT_ID/${_REPO}/myapp:latest'

      - '--cache-from'

      - '${_REGION}-docker.pkg.dev/$PROJECT_ID/${_REPO}/myapp:latest'

      - '--build-arg'

      - 'VERSION=$COMMIT_SHA'

      - '.'

    id: 'docker-build'

    waitFor: ['unit-tests']



  # 步骤4：推送镜像到Artifact Registry

  - name: 'gcr.io/cloud-builders/docker'

    args: ['push', '--all-tags', '${_REGION}-docker.pkg.dev/$PROJECT_ID/${_REPO}/myapp']

    id: 'docker-push'

    waitFor: ['docker-build']



  # 步骤5：部署到Cloud Run

  - name: 'gcr.io/cloud-builders/gcloud'

    args:

      - 'run'

      - 'deploy'

      - 'myapp'

      - '--image=${_REGION}-docker.pkg.dev/$PROJECT_ID/${_REPO}/myapp:$COMMIT_SHA'

      - '--region=${_REGION}'

      - '--platform=managed'

    id: 'deploy'

    waitFor: ['docker-push']



# 替换变量

substitutions:

  _REGION: asia-east1

  _REPO: myapp-repo



# 构建选项

options:

  logging: CLOUD_LOGGING_ONLY

  machineType: 'E2_HIGHCPU_8'

  dynamic_substitutions: true



# 超时设置

timeout: '1200s'



# 构建镜像列表（Cloud Build会自动推送这些镜像）

images:

  - '${_REGION}-docker.pkg.dev/$PROJECT_ID/${_REPO}/myapp:$COMMIT_SHA'

  - '${_REGION}-docker.pkg.dev/$PROJECT_ID/${_REPO}/myapp:latest'

替代变量与动态替换

Cloud Build 提供了丰富的内置替代变量和自定义替代变量机制，方便在不同环境中复用同一个构建配置：

启用

后，可以在 bash 脚本步骤中使用这些变量进行字符串拼接和条件判断，这在多环境部署中尤为关键。

Cloud Build 高级配置

Private Pool：在 VPC 中安全构建

默认情况下，Cloud Build 在 Google 管理的公共池中运行。如果你的构建需要访问 VPC 内的资源（如私有 GCR 镜像、内部数据库等），就需要使用 Private Pool。Private Pool 运行在你指定的 VPC 网络中，构建节点可以通过内网访问你的资源。

1
2
3
4
5
6
7
8
# 创建Private Pool配置文件 private-pool.yaml

name: projects/my-gcp-project/locations/asia-east1/workerPools/my-private-pool

workerConfig:

  machineType: E2_HIGHCPU_32

  diskSizeGb: 500

networkConfig:

  peeredNetwork: projects/my-gcp-project/global/networks/my-vpc

  peeredNetworkIpRange: '10.0.0.0/28'

1
2
3
4
5
6
7
8
# 使用gcloud创建Private Pool

gcloud builds worker-pools create my-private-pool 

  --region=asia-east1 

  --config=private-pool.yaml



# 在构建中使用Private Pool

gcloud builds submit --config=cloudbuild.yaml 

  --worker-pool=projects/my-gcp-project/locations/asia-east1/workerPools/my-private-pool

并行步骤与依赖管理

Cloud Build 支持通过

和

字段来控制步骤的执行顺序。默认情况下，所有步骤按顺序执行。如果你想并行运行无依赖的步骤，只需设置

，表示该步骤不需要等待任何前序步骤：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
steps:

  # 前端测试（并行）

  - name: 'node:18-slim'

    args: ['npm', 'run', 'test']

    id: 'frontend-test'

    waitFor: ['-']

    dir: 'frontend'



  # 后端测试（并行）

  - name: 'python:3.11-slim'

    args: ['pytest', 'tests/']

    id: 'backend-test'

    waitFor: ['-']

    dir: 'backend'



  # 安全扫描（并行）

  - name: 'aquasec/trivy:latest'

    args: ['fs', '--severity', 'HIGH,CRITICAL', '.']

    id: 'security-scan'

    waitFor: ['-']



  # 集成测试（等待所有并行步骤完成）

  - name: 'python:3.11-slim'

    args: ['pytest', 'integration_tests/']

    id: 'integration-test'

    waitFor: ['frontend-test', 'backend-test', 'security-scan']

构建触发器（Trigger）配置

构建触发器是实现 CI/CD 自动化的关键。你可以基于代码仓库的事件（推送、标签、Pull Request）自动触发构建：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
# 创建触发器：main分支推送时自动构建

gcloud builds triggers create github 

  --repo-name=myapp 

  --repo-owner=myorg 

  --branch-pattern='^main$' 

  --build-config=cloudbuild.yaml 

  --include-build-logs-exclude-privacy



# 创建触发器：打标签时自动发布

gcloud builds triggers create github 

  --repo-name=myapp 

  --repo-owner=myorg 

  --tag-pattern='^v[0-9]+.[0-9]+.[0-9]+$' 

  --build-config=cloudbuild-release.yaml 

  --substitutions=_ENV=production

对于更复杂的触发条件，可以使用 Cloud Build 的过滤语法（基于 CEL 表达式），例如只在特定文件变更时触发：

1
2
3
4
5
6
7
# 仅当src/目录或Dockerfile变更时触发构建

gcloud builds triggers create github 

  --repo-name=myapp 

  --repo-owner=myorg 

  --branch-pattern='^main$' 

  --build-config=cloudbuild.yaml 

  --filter='STATUS == "SUCCESS" && source.dirs.changed.contains("src") || source.files.changed.contains("Dockerfile")'

Artifact Registry 深度配置

仓库创建与管理

Artifact Registry 支持多种制品格式，在创建仓库时需要指定格式类型。以下是创建 Docker 仓库的完整流程：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
# 启用Artifact Registry API

gcloud services enable artifactregistry.googleapis.com



# 创建Docker仓库

gcloud artifacts repositories create myapp-repo 

  --repository-format=docker 

  --location=asia-east1 

  --description="Production Docker images" 

  --async



# 创建Maven仓库（Java项目）

gcloud artifacts repositories create maven-repo 

  --repository-format=maven 

  --location=asia-east1 

  --mode=remote 

  --description="Remote Maven proxy"



# 创建npm仓库（Node.js项目）

gcloud artifacts repositories create npm-repo 

  --repository-format=npm 

  --location=asia-east1 

  --mode=remote 

  --description="Remote npm proxy"

注意

参数：

（默认）是本地仓库，存储你自己的制品；

是代理仓库，缓存上游公共仓库的制品；

是虚拟仓库，聚合多个上游仓库提供统一访问入口。

多区域镜像复制

在全球化部署场景中，你需要将镜像复制到多个区域以减少拉取延迟。Artifact Registry 原生支持跨区域复制：

1
2
3
4
5
6
7
8
9
10
11
12
13
# 创建支持多区域复制的Docker仓库

gcloud artifacts repositories create myapp-repo 

  --repository-format=docker 

  --location=asia 

  --description="Multi-region Docker repo for Asia"



# 查看复制状态

gcloud artifacts repositories describe myapp-repo 

  --location=asia



# 镜像推送后自动复制到所有配置的区域

docker tag myapp:latest asia-docker.pkg.dev/my-project/myapp-repo/myapp:latest

docker push asia-docker.pkg.dev/my-project/myapp-repo/myapp:latest

多区域仓库使用区域级端点（如

、

、

），推送一次镜像即可在所有配置的区域自动复制，拉取时客户端会自动选择最近的区域。

镜像版本管理策略

生产环境中合理的标签策略对于镜像管理和回滚至关重要。推荐使用以下标签体系：

• 语义化版本标签：

  1

  v1.2.3

  — 精确对应某个发布版本

• 提交哈希标签：

  1	sha-a1b2c3d

  — 对应代码提交，便于追溯

• 环境标签：

  1

  staging

  、

  1	production

  — 指向当前各环境的部署版本

• latest标签：仅用于开发环境，生产环境禁止使用

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
# 在cloudbuild.yaml中实现多标签策略

steps:

  - name: 'gcr.io/cloud-builders/docker'

    args:

      - 'build'

      - '-t'

      - '${_REGION}-docker.pkg.dev/$PROJECT_ID/${_REPO}/myapp:$COMMIT_SHA'

      - '-t'

      - '${_REGION}-docker.pkg.dev/$PROJECT_ID/${_REPO}/myapp:v${_VERSION}'

      - '.'



  # 更新环境标签（将staging指向新镜像）

  - name: 'gcr.io/cloud-builders/docker'

    entrypoint: 'bash'

    args:

      - '-c'

      - |

        docker pull ${_REGION}-docker.pkg.dev/$PROJECT_ID/${_REPO}/myapp:$COMMIT_SHA

        docker tag ${_REGION}-docker.pkg.dev/$PROJECT_ID/${_REPO}/myapp:$COMMIT_SHA 

          ${_REGION}-docker.pkg.dev/$PROJECT_ID/${_REPO}/myapp:${_ENV}

        docker push ${_REGION}-docker.pkg.dev/$PROJECT_ID/${_REPO}/myapp:${_ENV}

安全扫描与合规

Artifact Registry 内置漏洞扫描

Artifact Registry 集成了 Google 的漏洞扫描服务，可以自动检测 Docker 镜像中的已知安全漏洞。开启此功能只需在仓库上启用扫描：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
# 为仓库启用漏洞扫描

gcloud artifacts repositories update myapp-repo 

  --location=asia-east1 

  --enable-vulnerability-scanning



# 查看镜像漏洞报告

gcloud artifacts docker images scan 

  ${_REGION}-docker.pkg.dev/$PROJECT_ID/myapp-repo/myapp:$COMMIT_SHA 

  --show-latest-severity-only



# 列出特定镜像的所有漏洞

gcloud artifacts docker images list-vulnerabilities 

  ${_REGION}-docker.pkg.dev/$PROJECT_ID/myapp-repo/myapp@sha256:abc123 

  --format=json

漏洞扫描报告包含 CVE 编号、CVSS 评分、影响包和修复版本等详细信息。在生产流水线中，你应该在构建步骤后增加一个漏洞检查步骤：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
# cloudbuild.yaml中的安全检查步骤

  - name: 'gcr.io/cloud-builders/gcloud'

    entrypoint: 'bash'

    args:

      - '-c'

      - |

        # 扫描镜像

        SCAN_RESULT=$(gcloud artifacts docker images scan 

          ${_REGION}-docker.pkg.dev/$PROJECT_ID/myapp-repo/myapp:$COMMIT_SHA 

          --format=json)

        

        # 检查是否有CRITICAL级别漏洞

        CRITICAL_COUNT=$(echo $SCAN_RESULT | jq '[.[] | .vulnerabilities[] | select(.severity=="CRITICAL")] | length')

        

        if [ "$CRITICAL_COUNT" -gt 0 ]; then

          echo "Found $CRITICAL_COUNT CRITICAL vulnerabilities!"

          echo "$SCAN_RESULT" | jq '.[] | .vulnerabilities[] | select(.severity=="CRITICAL")'

          exit 1

        fi

        

        echo "Security scan passed. No CRITICAL vulnerabilities found."

    id: 'security-check'

    waitFor: ['docker-push']

IAM 权限精细控制

Artifact Registry 使用 IAM 进行细粒度权限控制。以下是推荐的权限分配策略：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
# 为Cloud Build服务账号授予写入权限

gcloud artifacts repositories add-iam-policy-binding myapp-repo 

  --location=asia-east1 

  --member='serviceAccount:PROJECT_NUMBER@cloudbuild.gserviceaccount.com' 

  --role='roles/artifactregistry.writer'



# 为GKE服务账号授予只读权限

gcloud artifacts repositories add-iam-policy-binding myapp-repo 

  --location=asia-east1 

  --member='serviceAccount:my-gke-sa@my-project.iam.gserviceaccount.com' 

  --role='roles/artifactregistry.reader'



# 使用条件绑定限制只允许推送特定tag

# （需要Organization Policy支持）

成本优化与最佳实践

构建成本优化

Cloud Build 提供每天 120 分钟的免费构建时间（E2机型），超出部分按分钟计费。以下是降低构建成本的策略：

• 利用 Docker 缓存：使用

  1	--cache-from

  参数复用之前的镜像层，大幅减少构建时间

• 并行步骤：使用

  1	waitFor: ['-']

  并行运行独立步骤，减少总构建时间

• 按需选择机型：小型项目使用默认 E2 机型即可，大型构建使用 E2_HIGHCPU_8 或 E2_HIGHCPU_32
• 利用免费额度：每天前 120 分钟免费，将非紧急构建安排在空闲时段

Artifact Registry 存储优化

镜像存储和跨区域复制会产生持续费用。以下策略可以有效控制存储成本：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
# 设置清理策略：自动删除超过90天的旧镜像

gcloud artifacts repositories set-cleanup-policies myapp-repo 

  --location=asia-east1 

  --policy=cleanup-policy.json



# cleanup-policy.json 内容

# [

#   {

#     "name": "cleanup-old-images",

#     "type": "CONDITION_BASED",

#     "condition": {

#       "newerThan": "90d",

#       "tagState": "untagged"

#     },

#     "action": { "type": "DELETE" }

#   },

#   {

#     "name": "keep-latest-versions",

#     "type": "KEEP_COUNT_BASED",

#     "condition": {

#       "packageName": "myapp"

#     },

#     "action": {

#       "type": "KEEP",

#       "count": 10

#     }

#   }

# ]

清理策略支持两种类型：

（基于条件删除）和

（保留最近N个版本）。可以组合使用，先保留再删除，确保不会误删正在使用的镜像。

Docker 镜像体积优化

更小的镜像意味着更快的推送/拉取速度和更低的存储成本：

1
2
3
4
5
6
7
8
9
10
11
12
# 多阶段构建示例

FROM python:3.11-slim AS builder

WORKDIR /app

COPY requirements.txt .

pip install --user -r requirements.txt



FROM python:3.11-slim

WORKDIR /app

COPY --from=builder /root/.local /root/.local

COPY . .

ENV PATH=/root/.local/bin:$PATH

CMD ["gunicorn", "--bind", "0.0.0.0:8080", "app:app"]

• 使用

  1

  slim

  或

  1

  alpine

  基础镜像

• 多阶段构建（multi-stage build），只复制运行时需要的文件
• 合并 RUN 指令减少层数
• 使用

  1	.dockerignore

  排除不必要的文件

完整生产级流水线示例

以下是一个包含完整 CI/CD 流程的端到端配置，涵盖构建、测试、安全扫描、多环境部署和通知：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
# cloudbuild.yaml - 生产级CI/CD流水线

steps:

  # ===== 阶段1：并行检查 =====

  - name: 'python:3.11-slim'

    entrypoint: 'bash'

    args: ['-c', 'pip install -q flake8 && flake8 src/ --max-line-length=120']

    id: 'lint'

    waitFor: ['-']



  - name: 'python:3.11-slim'

    entrypoint: 'bash'

    args: ['-c', 'pip install -q -r requirements.txt pytest && pytest tests/unit/ -v']

    id: 'unit-tests'

    waitFor: ['-']



  # ===== 阶段2：构建与推送 =====

  - name: 'gcr.io/cloud-builders/docker'

    args:

      - 'build'

      - '-t'

      - '${_REGION}-docker.pkg.dev/$PROJECT_ID/${_REPO}/${_APP}:$COMMIT_SHA'

      - '--cache-from'

      - '${_REGION}-docker.pkg.dev/$PROJECT_ID/${_REPO}/${_APP}:build-cache'

      - '.'

    id: 'build'

    waitFor: ['lint', 'unit-tests']



  - name: 'gcr.io/cloud-builders/docker'

    args: ['push', '${_REGION}-docker.pkg.dev/$PROJECT_ID/${_REPO}/${_APP}:$COMMIT_SHA']

    id: 'push'

    waitFor: ['build']



  # ===== 阶段3：安全扫描 =====

  - name: 'gcr.io/cloud-builders/gcloud'

    entrypoint: 'bash'

    args:

      - '-c'

      - |

        gcloud artifacts docker images scan 

          ${_REGION}-docker.pkg.dev/$PROJECT_ID/${_REPO}/${_APP}:$COMMIT_SHA 

          --format=value(vulnerability.severity) | 

          grep -q CRITICAL && exit 1 || exit 0

    id: 'vuln-scan'

    waitFor: ['push']



  # ===== 阶段4：部署 =====

  - name: 'gcr.io/cloud-builders/gcloud'

    entrypoint: 'bash'

    args:

      - '-c'

      - |

        if [ "$BRANCH_NAME" = "main" ]; then

          gcloud run deploy ${_APP}-prod 

            --image=${_REGION}-docker.pkg.dev/$PROJECT_ID/${_REPO}/${_APP}:$COMMIT_SHA 

            --region=${_REGION} 

            --platform=managed

        else

          gcloud run deploy ${_APP}-staging 

            --image=${_REGION}-docker.pkg.dev/$PROJECT_ID/${_REPO}/${_APP}:$COMMIT_SHA 

            --region=${_REGION} 

            --platform=managed 

            --no-traffic

        fi

    id: 'deploy'

    waitFor: ['vuln-scan']



  # ===== 阶段5：通知 =====

  - name: 'gcr.io/cloud-builders/gcloud'

    entrypoint: 'bash'

    args:

      - '-c'

      - |

        gcloud pubsub topics publish cloud-builds 

          --message='{"app":"${_APP}","sha":"$COMMIT_SHA","status":"$BUILD_STATUS"}'

    id: 'notify'

    waitFor: ['deploy']



substitutions:

  _REGION: asia-east1

  _REPO: myapp-repo

  _APP: myapp



options:

  machineType: E2_HIGHCPU_8

  logging: CLOUD_LOGGING_ONLY



timeout: '1800s'



images:

  - '${_REGION}-docker.pkg.dev/$PROJECT_ID/${_REPO}/${_APP}:$COMMIT_SHA'

监控与可观测性

生产环境中对构建流水线的监控同样重要。Cloud Build 与 Cloud Monitoring 深度集成，你可以通过指标和日志了解构建状态和性能：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
# 查看最近的构建状态

gcloud builds list --limit=10 --format='table(id,status,createTime,duration)'



# 查看特定构建的详细日志

gcloud builds log BUILD_ID



# 创建构建失败的告警策略

gcloud alpha monitoring policies create 

  --display-name="Cloud Build Failure Alert" 

  --condition='{

    "displayName": "Build failure rate > 20%",

    "conditionThreshold": {

      "filter": "metric.type="build.googleapis.com/build/count" resource.type="cloud_build"",

      "comparison": "COMPARISON_GT",

      "thresholdValue": 0.2,

      "duration": "300s"

    }

  }'

你还可以将 Cloud Build 的日志导出到 BigQuery 进行长期分析和趋势追踪，这对于优化构建时间、识别频繁失败的步骤非常有价值。

总结

Google Cloud Build 与 Artifact Registry 组合提供了一套完整的、生产级的 CI/CD 解决方案。Cloud Build 的全托管特性让你无需运维构建服务器，而 Artifact Registry 的多格式支持和内置安全扫描则为制品管理提供了强大的保障。通过合理配置替代变量、并行步骤、清理策略和权限控制，你可以构建一个既高效又安全的持续交付流水线。

关键建议总结：

• 始终使用语义化版本标签，生产环境禁止使用 latest
• 启用漏洞扫描并在流水线中加入安全检查门禁
• 利用 Docker 缓存和并行步骤优化构建速度
• 配置清理策略控制存储成本
• 使用 Private Pool 处理需要 VPC 访问的构建
• 基于分支/标签条件实现多环境部署
• 设置监控告警，及时感知构建异常