58 lines
2.2 KiB
Markdown
58 lines
2.2 KiB
Markdown
# 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)。
|