orbit/docs/reports/phase-9-compose-deployment.md

Compose 部署基线验证

验证日期：2026-09-22
验证范围：MySQL 健康检查、迁移、运行账号权限收紧、schema 核验、Orbit 启动、就绪探针和核验失败门禁。
验证环境：Docker Desktop、MySQL 8.4、当前 orbit:dev 镜像。

已通过

静态配置门禁

使用临时数据库用户名、密码和镜像标签执行：

docker compose -f deploy/docker-compose.yml config

结果：Compose 配置成功展开，五个服务的依赖条件、健康检查、数据卷、端口和运行时 DSN 均可解析；密码没有写入仓库。

同时通过：

git diff --check
make docs-check

正常启动链路

在一次性 MySQL 8.4 和临时数据库卷中执行 Compose 服务链。当前开发机已有大量 Docker 自定义网络，地址池不足，因此本次测试只在临时覆盖文件中把容器放到 Docker 默认 bridge 网络并添加链接；生产 Compose 文件仍使用标准项目隔离网络，服务依赖语义没有改变。

验证顺序和结果：

1. mysql 通过 mysqladmin ping 健康检查。
2. migrate 使用 root 迁移连接完成当前迁移。
3. grant 撤销运行账号的额外数据库权限，仅保留运行所需的 DML 权限。
4. verify 使用运行账号完成 orbit-admin verify。
5. orbit 在前述一次性服务成功后启动。
6. GET /health/ready 返回成功。

最后输出：

compose-e2e=passed readiness=ok grant=ok

失败门禁

第二次使用临时 MySQL，故意让 verify 使用错误的运行账号密码。迁移成功后，verify 以退出码 1 结束，Compose 报告：

service "verify" didn't complete successfully: exit 1

Orbit 没有进入运行状态，证明 schema 核验失败不会把未核验节点拉入流量。

尚未由本报告关闭的事项

本报告只证明单节点 Compose 的启动顺序和失败边界，不代表生产高可用。数据库自动切换、跨故障域多节点、正式 Secret 注入、反向代理 TLS、备份恢复、容量余量和 RPO/RTO 仍按生产验收总清单逐项留证。首次管理员和控制台任务闭环的真实证据见phase-8 控制台闭环。