Gitlab shared runners结合liquibase经SSH堡垒机执行数据库迁移的方案咨询

先评估你提到的两类常见方案的适配场景 #

方案1：替换为GitLab专用Runner（生产环境首选） #

• 优势：
  • 可直接部署在和堡垒机同内网的资源池中，无需将数据库访问权限暴露到公网，安全等级高
  • 流水线配置改动极小，仅需给liquibase迁移任务绑定对应Runner标签即可，无需修改原有迁移脚本，执行日志直接沉淀在GitLab流水线中，溯源方便
  • 权限管控粒度灵活，可给专用Runner单独配置最小权限的堡垒机账号，也支持将临时SSH凭证加密挂载到Runner环境变量，降低长期凭证泄露风险
• 注意事项：
  • 专用Runner需做任务隔离，仅承接数据库迁移类任务，避免其他非授权任务读取Runner内的访问凭证
  • 可配置仅保护分支的流水线有权限调用该Runner，避免非正式分支误触生产库变更

方案2：ECS部署独立迁移执行实例（多业务线大规模场景首选） #

• 优势：
  • 迁移能力可全域复用，无需为每个项目单独配置Runner，所有业务线的数据库变更都可统一调用该实例执行，方便落地统一的变更审核、日志留存、回滚预案等管控规则
  • 和GitLab Runner体系完全解耦，即使共享Runner出现安全问题也不会触达数据库层
• 注意事项：
  • 需要额外开发调用接口/CLI工具并配套鉴权逻辑，避免未授权调用触发非法变更
  • 实例需做安全加固，仅开放必要端口给GitLab Runner的出口IP段

补充轻量适配方案（测试/预发环境适用） #

如果不想调整Runner部署架构，也不想新增ECS资源，可采用共享Runner+SSH临时隧道的方案实现：

• 实现逻辑：在liquibase执行步骤前，先运行ssh -fN -L 本地端口:数据库内网地址:数据库端口 堡垒机账号@堡垒机地址建立端口转发隧道，将堡垒机后方的数据库端口映射到Runner本地，liquibase直接连接本地端口执行迁移，任务结束后隧道自动断开
• 优势：改造成本极低，仅需调整.gitlab-ci.yml配置即可，无需额外投入资源
• 注意事项：绝对禁止用于生产环境，共享Runner为多租户共用，存在凭证被其他租户窃取的风险，堡垒机凭证必须存储在GitLab加密变量中，禁止硬编码到流水线脚本

选择建议 #

生产环境优先选择专用Runner方案，是当前业内该场景的主流最佳实践，安全可控且运维成本低；
公司内部有统一管控数据库变更需求的多业务线场景，选择ECS独立迁移实例方案更适合长期运维；
临时测试验证场景可直接使用共享Runner+SSH隧道的轻量方案。

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