数据库 Docker 给 QA：达梦 / 瀚高少交安装税

真正的问题不是「达梦能不能装」

在政企与合规栈里，达梦 / 瀚高 / 人大金仓经常是硬性要求。QA 很少死在「库很神秘」上——死在通往可用实例的路径全靠口口相传：裸机安装包、缺依赖、一次性虚拟机快照，以及「等 DBA 有空」。

这税在第一条断言跑起来之前就已经交了。新人环境要一天；CI 在数据库启动阶段就抖；自动化作者把账号密码写进脚本，因为没人留下可复用的约定。如果 Postgres 能 pull → run → connect，这些数据库对测试也应该是同一套体感。

这篇不是 DBA 手册。我优化的是 QA 契约：可预期的标签、尽量一容器一服务、凭据走环境变量、全量回归前先做连通性冒烟。

数字怎么说（本站实时刷新）

在 Docker Hub 的 xuxuclassmate 命名空间下，我维护一套面向 QA 的镜像。首页指标经 Docker Hub API Gateway 刷新——README 徽章也走同一网关——所以不是宣传册数字。

达梦与瀚高贡献主要拉取量。这是信号：团队会先复用最痛的库。人大金仓与 TiDB 负责覆盖面，不是面子工程。

让拉取量持续上涨的设计取舍

我把镜像名和标签当成公开 API。花哨的标签方案会在套件从笔记本毕业到流水线的那周炸掉。无聊反而赢。

• 尽量一镜像一主服务——启动失败更好定位
• 可预期标签优先于「什么都 latest」；CI 钉死，本地实验再浮动
• 文档跟镜像走，避免新人满世界找内部 Wiki
• 达梦 / 瀚高 / 金仓 / TiDB 统一心智：拉取 → 启动 → 连接
• 尽早发布，让拉取量证伪或证实痛点——不要只活在演示里

能活过 CI 的最小工作流

选你真正断言的那套库。暴露客户端已期望的端口。凭据放环境变量——永远不要写进提交的测试代码。全量 Playwright / 接口回归前先做连通性冒烟，让数据库启动问题在几秒内失败，而不是二十分钟 UI 噪音之后。

• 本地：团队共享 compose，端口与 CI 一致
• CI：钉死 digest 或不可变标签；runner 允许则缓存拉取
• 密钥：CI 变量 / 密封密钥——不要把密码截图丢进群聊
• 顺序：库健康 → 如需则迁移/造数 → 接口冒烟 → UI 回归

                      # CI 钉标签——不要在实验标签上漂
docker pull xuxuclassmate/dameng:<pinned-tag>
docker run -d --name qa-dameng \
  -p 5236:5236 \
  -e DM_PASSWORD=ChangeMe \
  xuxuclassmate/dameng:<pinned-tag>

# 快速失败：全量套件前先做连通性冒烟
#（JDBC / SQL 客户端 / 健康检查——以镜像文档为准）

                    

我反复看到的失败模式

大多数「数据库 CI 不稳定」故事，本质是环境契约问题，不是断言写错。契约修一次，整组套件都会安静下来。

• 浮动标签：周五绿、周一红，因为上游重建了 latest
• 共享容器：自托管 runner 上两个任务抢同一端口
• 隐藏主机名：本地用 localhost、CI 用 docker 网络名，却没有抽象层
• 巨型全家桶镜像：启动失败时分不清是哪个进程挂了
• 没有冒烟步骤：整份 UI 套件变成了数据库健康检查

如何支撑 AI 工具与 Agent 技能

用例生成器和 ClawHub 技能在演示里很亮眼。如果底下的环境团队起不来，它们就没有价值。可复用数据库镜像是让多模态生成和评审闭环「诚实」的那层无聊底座。

Docker Hub API Gateway 也是同一理由：README 徽章和本站首页应该读实时拉取，而不是过期截图。自用网关，证据才站得住。

镜像「算给 QA 准备好了」之前的清单

• 陌生人只看 Docker Hub 页就能拉取启动，不依赖私有 Wiki
• 标签策略写清楚：CI 钉什么、实验漂什么
• 凭据走环境变量；默认值有文档且非生产
• 有一条命令级连通性冒烟路径
• 拉取量可见——没人拉，你就不知道痛点是否真实