在CI/CD中用Docker自动化数据库Schema迁移，核心是将迁移逻辑封装进专用轻量级容器，通过健康检查、重试脚本和流水线集成确保迁移在应用启动前可靠执行，并前置设计安全回滚与校验机制。
在CI/CD中用Docker自动化执行数据库Schema迁移，核心是把迁移逻辑封装进容器生命周期，并确保它在应用启动前、依赖服务就绪后可靠运行。关键不在于“能不能做”，而在于“谁来触发、何时触发、失败怎么处理”。
把迁移脚本打包进专用迁移容器
不要让主应用容器承担迁移职责，而是单独定义一个轻量级迁移服务。例如使用官方PostgreSQL镜像为基础，叠加迁移工具和SQL脚本：
- 编写Dockerfile：基于
postgres:15-alpine，COPY迁移脚本（如V1__init.sql、V2__add_user_status.sql）和flyway或sqldef二进制文件 - 设置ENTRYPOINT为迁移命令，如
flyway -url=jdbc:postgresql://db:5432/myapp -user=postgres migrate - 构建镜像并推送到私有Registry，版本号与代码分支/Tag对齐（如
myapp-migrator:v1.2.0）
在Docker Compose中控制执行时机
迁移必须等数据库容器真正可连接后再运行，不能只靠depends_on的启动顺序。推荐组合使用健康检查与entrypoint脚本：
- 在
docker-compose.yml中为数据库服务配置healthcheck，例如用pg_isready -U postgres -d myapp - 迁移服务声明
depends_on: { db: { condition: service_healthy } } - 迁移容器的entrypoint脚本内嵌重试逻辑：
until psql -h db -U postgres -c '\l' > /dev/null 2>&1; do sleep 2; done && ./run-migrations.sh
与CI/CD流水线深度集成
迁移不是一次性的部署动作，而是每次代码合并到main分支时自动触发的验证环节：
- 在CI阶段（如GitHub Actions或Jenkins Pipeline）增加步骤：拉取最新迁移镜像 → 启动临时数据库容器 → 运行迁移 → 执行SQL lint或schema diff校验 → 清理环境
- 将
sqldef diff或mysqldump --no-data输出与基线Schema比对，失败则阻断流水线 - 生成迁移报告存档（如上传到S3或写入Git Tag注释），包含变更摘要、执行耗时、影响表数量
安全与回滚必须前置设计
自动化迁移一旦出错，人工干预窗口极小，所以机制要默认防呆：
- 所有SQL迁移脚本强制要求含
DOWN反向语句（或使用支持双向迁移的工具如Liquibase） - 生产环境迁移容器启动时加
--read-only和--tmpfs /tmp:rw,size=100M限制副作用 - 记录每次迁移的checksum到数据库
flyway_schema_history表，并在CI中校验是否与Git提交一致
