如何在CI/CD中对无公网端点的云托管数据库执行迁移及回滚
2026-8-11
私有VPC内数据库的CI/CD迁移最佳实践（Prisma + AWS 栈）
核心问题拆解
要解决无公网端点的私有RDS在CI/CD中执行Prisma迁移的问题，核心是让迁移执行环境接入数据库所在的VPC网络，同时利用Prisma自带的迁移能力避免依赖付费工具，还要保证应用与数据库版本的一致性，以及部署失败时的回滚机制。
最优流程方案
方案1：复用应用镜像的Fargate轻量迁移（优化原方案）
针对你的新栈，可简化之前的Fargate流程，无需单独构建迁移镜像：
- 因为Prisma CLI已包含在你的Node.js应用镜像中，只需在启动时指定迁移命令即可
- 流程步骤：
- 构建包含Prisma依赖与schema的应用镜像，推送到私有ECR
- 触发与RDS同VPC的Fargate任务，拉取该镜像并执行
prisma migrate deploy - 迁移成功后，部署应用到AWS App Runner
- 若App Runner部署失败，触发Fargate任务执行回滚命令：可逆迁移用
prisma migrate down --steps <步数>，不可逆迁移则执行预定义的回滚脚本
方案2：Github Actions + SSM跳板实例（无额外容器服务）
无需依赖Fargate，直接通过AWS Session Manager（SSM）打通CI/CD与VPC的网络：
- 前置准备：在VPC内部署一个无公网IP的跳板实例，安装SSM Agent，安全组允许其访问RDS
- 流程步骤：
- 在Github Actions中配置具备SSM权限的AWS凭证
- 通过AWS CLI的
ssm start-session命令，在跳板实例上同步代码或拉取ECR镜像，执行prisma migrate deploy - 迁移成功后部署App Runner，失败则触发回滚命令
方案3：App Runner内置迁移（最简洁）
如果你的App Runner服务已配置VPC访问（可直接连接私有RDS），可将迁移整合到App Runner的部署流程中：
- 流程步骤：
- 修改应用的启动脚本，先执行
prisma migrate deploy，再启动应用服务 - 推送镜像到ECR后部署到App Runner（确保App Runner的VPC配置允许访问RDS）
- 若App Runner启动失败（迁移或应用服务出错），自动回滚到上一稳定版本，同时触发CI/CD步骤执行迁移回滚
- 修改应用的启动脚本，先执行
回滚策略（适配Prisma特性）
- 可逆迁移：直接通过
prisma migrate down --steps <步数>回滚指定版本 - 不可逆迁移：提前编写回滚脚本，在CI/CD中触发执行；同时配合AWS RDS的快照功能，在迁移前自动创建快照，作为兜底回滚方案
- 联动回滚：在CI/CD流水线中设置触发条件，一旦App Runner部署失败，立即执行数据库回滚流程，确保应用与数据库版本匹配
关键注意事项
- 严格控制迁移执行环境的网络权限：安全组/网络ACL仅开放RDS所需端口，最小化权限范围
- 迁移前自动触发RDS快照，避免不可逆操作导致的数据丢失
- 用
prisma migrate status在迁移前检查状态，防止重复执行或版本冲突 - CI/CD中的AWS凭证仅授予迁移所需的最小权限（如ECR拉取、Fargate启动、SSM访问、RDS快照管理等）
内容的提问来源于stack exchange，提问作者JC97
相关产品推荐
相关产品推荐
