GCP架构疑问：如何实现App代码与IaC的职责分离及自动部署

当前架构的核心问题 #

这套架构的最大问题是镜像更新和部署流程断了档：

• Dev团队只管把代码做成镜像推去仓库，但没法触发后续的Cloud Run部署，完全依赖架构师手动推app-infra代码才能更新，效率极低
• 职责分离做得太过头，把Dev的部署链路彻底掐断了，不符合DevOps里“谁开发谁负责部署”的基本逻辑，也让镜像版本和基础设施配置没法自动同步

兼顾安全与职责分离的解决方法 #

方法1：用镜像仓库的事件触发部署 #

• 给Artifact Registry（或者GCR）加个事件通知：只要有新镜像推到指定标签（比如固定的版本标签，别用容易被覆盖的latest），就自动触发app-infra的Cloud Build触发器
• 给Cloud Build的服务账号开两个权限：一是能读app-infra仓库的代码，二是有Terraform部署Cloud Run需要的资源权限，但绝对不能让它改app-infra的代码
• 在app-infra的Cloud Build流程里加个步骤：自动拉取最新的镜像标签，更新Terraform里的镜像版本变量，然后直接跑terraform apply

  举个Terraform配置的例子，得用变量而非硬编码版本：

  variable "image_tag" {
    type        = string
    description = "要部署的容器镜像标签"
  }
  
  resource "google_cloud_run_service" "app" {
    # 其他配置省略
    template {
      spec {
        containers {
          image = "us-docker.pkg.dev/${var.project_id}/repo/app:${var.image_tag}"
        }
      }
    }
  }
  

方法2：用GitOps模式，PR触发更新 #

• 在app-infra仓库里专门放个记录镜像版本的文件（比如image-version.yaml），当Dev推完新镜像后，用Cloud Function之类的工具自动给app-infra发个PR，把里面的镜像版本号改成刚推送的那个
• 架构师只需要审核这个PR合不合理（比如标签是不是符合团队的版本规范），合并之后就会触发Cloud Build的Terraform部署
• 给Dev团队配置权限：只能给app-infra提PR，不能直接推代码，既守住了架构的安全底线，又让Dev能发起部署流程

方法3：拆分部署模块，让Dev能触发但限死权限 #

• 把Cloud Run的部署配置从app-infra的全局配置里拆出来，单独做一个app-deploy的Terraform模块
• 给Dev团队的Cloud Build服务账号只开这个模块的terraform apply权限，其他基础设施资源的权限一概不给
• 在app-code的Cloud Build流程最后加一步：调用这个app-deploy模块，把刚推的镜像标签当参数传进去，直接触发部署

安全和职责分离的关键注意点 #

• 所有自动化操作必须用服务账号执行，绝对不能用个人账号的权限
• 给镜像仓库加标签规则：比如必须用语义化版本（v1.0.1这种），禁止随便覆盖latest标签，防止错发或者恶意镜像触发部署
• 保留所有部署操作的审计日志，谁触发的、用的哪个镜像都要能查得到

内容的提问来源于stack exchange，提问作者Gabriele B