GCP Cloud Build是否有GitLab CI/CD环境文件等效功能及替换方案

Cloud Build 有完全可以替代 GitLab 环境文件的功能，根据存储内容的敏感程度，分为两类实现方案：

• 敏感类内容（密码、密钥、API 令牌等）：使用 Secret Manager 存储，这是 GCP 官方的敏感信息托管服务，Cloud Build 原生支持直接从 Secret Manager 拉取内容注入到构建环境的环境变量或者文件中，不会在构建日志中泄露明文。
• 非敏感类配置（公共构建参数、通用配置文件等）：使用 Cloud Storage（GCS） 私有存储桶存储，构建时直接拉取到构建工作目录即可。

具体操作配置如下：

1. 先给 Cloud Build 默认服务账号授权：
   • 要拉取 Secret Manager 内容，授予 roles/secretmanager.secretAccessor 权限
   • 要拉取 GCS 存储桶文件，授予对应存储桶的 roles/storage.objectViewer 权限
2. 在 cloudbuild.yaml 中添加对应的配置逻辑：
   拉取密钥注入环境变量示例：

   availableSecrets:
     secretManager:
     - versionName: projects/你的GCP项目ID/secrets/你的密钥名称/versions/latest
       env: 'DB_PASSWORD' # 注入到构建环境的环境变量名
   

   拉取 GCS 中的 .env 配置文件示例：

   steps:
   - name: 'gcr.io/cloud-builders/gsutil'
     args: ['cp', 'gs://你的存储桶名称/路径/.env', './.env']
   

按照以下步骤操作即可完成完整替换：

• 第一步：迁移 CI 配置逻辑，将原 .gitlab-ci.yml 中的构建、测试、打包等阶段，对应转换为 cloudbuild.yaml 中的 steps 配置，Cloud Build 支持所有主流语言的官方构建镜像，也支持使用自定义镜像，逻辑和 GitLab Runner 镜像使用规则完全一致。
• 第二步：配置触发规则，原 GitLab 中配置的分支触发、标签触发、合并请求触发等规则，都可以在 Cloud Build 触发器页面完成对应配置，支持绑定 GitHub、GitLab、Bitbucket 等外部代码库，也支持 GCP 自身的 Cloud Source Repositories。
• 第三步：验证构建流程，手动触发一次构建，验证配置拉取、依赖安装、构建编译、自动化测试各环节是否正常，输出产物是否符合预期。
• 第四步：配置部署逻辑，如果需要部署到 GKE、Cloud Run、App Engine 等 GCP 服务，Cloud Build 提供了官方的部署步骤模板，直接调用即可，不需要额外编写部署脚本，权限通过服务账号配置即可，无需像 GitLab CI 那样额外配置 GCP 服务密钥。
• 第五步：配置通知与日志，原 GitLab 中的构建状态通知、构建日志查询能力，Cloud Build 原生集成了 Cloud Logging 存储全量构建日志，也可以通过 Cloud Monitoring 配置构建失败/成功告警，推送到邮件、企业微信、Slack 等渠道。

• 如果原 GitLab CI 配置了依赖缓存加速构建，Cloud Build 支持配置 GCS 存储桶作为缓存存储，示例配置如下：

  options:
    cache:
      paths: ['node_modules/'] # 要缓存的目录路径
      gcs:
        path: gs://你的缓存存储桶名称/build-cache/
  

• 构建超时时间、构建机器资源规格等配置，可以在触发器配置或者 cloudbuild.yaml 的 options 字段中自定义，逻辑和 GitLab CI 的 Runner 配置一致。

内容的提问来源于stack exchange，提问作者Neron Joseph