在Cloud Build中运行Prisma Migrate连接Cloud SQL失败求助

一、修复Cloud Build到Cloud SQL的连接问题 #

1. 检查Cloud SQL公网访问配置 #

• 确认Cloud SQL实例的授权网络已包含Cloud Build的出站IP范围，测试阶段可临时添加0.0.0.0/0（生产环境务必收紧）。Cloud Build的IP是动态的，长期来看推荐用VPC peering或Cloud SQL Auth Proxy替代公网开放。
• 验证MySQL用户权限：确保迁移用的数据库用户允许从Cloud Build来源IP（或通配符%）连接，且拥有CREATE、ALTER、DROP等迁移所需的权限。

2. 使用Cloud SQL Auth Proxy建立安全连接（生产环境首选） #

公网IP开放存在安全风险，用Auth Proxy在Cloud Build步骤中建立隧道是更稳妥的方案：
修改cloudbuild.yaml，添加代理启动步骤：

steps:
  # 原有构建步骤（安装依赖、编译应用等）
  - name: 'node:20'
    args: ['npm', 'install']
  
  # 启动Cloud SQL Auth Proxy
  - name: 'gcr.io/cloud-builders/gcloud'
    entrypoint: 'bash'
    args:
      - '-c'
      - |
        wget https://dl.google.com/cloudsql/cloud_sql_proxy.linux.amd64 -O cloud_sql_proxy
        chmod +x cloud_sql_proxy
        ./cloud_sql_proxy -instances=你的项目ID:区域:实例名称=tcp:3306 &
        sleep 10 # 等待代理初始化完成
  
  # 执行Prisma迁移
  - name: 'node:20'
    args: ['npx', 'prisma', 'migrate', 'deploy']
    env:
      - 'DATABASE_URL=mysql://用户名:密码@127.0.0.1:3306/数据库名'

此时DATABASE_URL指向本地3306端口，由Auth Proxy转发至Cloud SQL实例。

3. 验证环境变量与连接可用性 #

• 检查Cloud Build步骤中的DATABASE_URL：确认用户名、密码、IP、端口、数据库名无拼写错误。
• 可添加测试步骤排查问题：

  - name: 'mysql:8'
    args: ['mysql', '-h', '34.171.173.136', '-u', '用户名', '-p密码', '-e', 'SELECT 1;']
  

  如果该步骤失败，说明是网络或数据库认证问题；如果成功，再聚焦Prisma配置。

二、迁移执行的最佳位置：Cloud Build而非Dockerfile #

1. 为什么不选Dockerfile？ #

• 镜像构建阶段执行迁移会导致重复执行风险：每次构建镜像都会跑迁移，多实例部署时可能引发锁表或迁移冲突。
• 敏感信息暴露：数据库密码等信息会被嵌入镜像层，存在安全隐患。

2. 为什么选Cloud Build？ #

• 迁移与部署流程绑定：在镜像构建完成、推送至容器注册表后，部署Cloud Run之前执行迁移，确保仅执行一次。
• 安全可控：通过Cloud Build的Secret Manager存储数据库密码，无需暴露在代码或镜像中。
• 失败阻断：迁移失败时可终止后续部署，避免应用连接到未完成迁移的数据库。

额外排查点 #

• 检查Cloud Build服务账号权限：确保其拥有cloudsql.client角色，以允许访问Cloud SQL实例或使用Auth Proxy。
• 本地验证：用相同的DATABASE_URL在本地执行npx prisma migrate deploy，如果本地成功，说明问题出在Cloud Build的网络或权限配置；如果本地也失败，重点排查数据库实例的用户权限或网络规则。

内容的提问来源于stack exchange，提问作者James Daly