# Compose 部署基线验证

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

## 已通过

### 静态配置门禁

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

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

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

同时通过：

```sh
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` 返回成功。

最后输出：

```text
compose-e2e=passed readiness=ok grant=ok
```

### 失败门禁

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

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

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

## 尚未由本报告关闭的事项

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