feat: 重构 Docker 配置结构，添加 compute 模块及新增文档
- 将 Dockerfile 和 docker-compose.yml 迁移至 docker/ 目录下统一管理 - 新增 compute 计算模块（API 入口、依赖配置） - 新增 docker/app 和 docker/compute 部署配置 - 新增 demo-development-plan.md 演示开发计划文档 - 更新后端 API 设计、部署计划、架构需求等文档 - 更新 postgres 数据库 schema Co-Authored-By: Claude <noreply@anthropic.com>
This commit is contained in:
wuyongtao
@@ -139,7 +139,7 @@ flowchart LR
|
||||
A --> L["LLaMA-Factory"]
|
||||
A --> G["GPU/CUDA"]
|
||||
A --> FS["算力服务器本地磁盘"]
|
||||
A -- "状态回调/日志摘要" --> B
|
||||
B -- "定时轮询任务状态/指标/产物索引" --> C
|
||||
```
|
||||
|
||||
### 5.3 部署边界
|
||||
@@ -170,8 +170,8 @@ GPU 算力服务器部署：
|
||||
- 协议：内部 HTTPS REST，后续可扩展 gRPC。
|
||||
- 鉴权：服务间 Token，生产建议 mTLS + IP 白名单。
|
||||
- 幂等：训练任务提交使用 `Idempotency-Key` 或 `job_id`。
|
||||
- 回调：算力平台向应用平台回调任务状态、指标摘要、产物索引。
|
||||
- 拉取：应用平台也可以定时轮询 Compute API，避免回调失败导致状态丢失。
|
||||
- 状态同步：默认由应用平台定时轮询 Compute API，拉取任务状态、指标摘要和产物索引。
|
||||
- 回调策略：第一阶段关闭算力侧回调，避免算力服务器访问应用服务器，减少双向网络策略开通。
|
||||
|
||||
文件互通：
|
||||
|
||||
@@ -196,9 +196,46 @@ GPU 算力服务器部署：
|
||||
### 5.6 风险
|
||||
|
||||
- 文件传输链路比单机部署复杂。
|
||||
- 需要处理跨服务器网络失败、回调失败、任务状态对账。
|
||||
- 需要处理跨服务器网络失败、轮询延迟、任务状态对账。
|
||||
- 需要明确模型、数据集、产物在应用侧和算力侧的索引关系。
|
||||
|
||||
### 5.7 多算力节点部署约定
|
||||
|
||||
多算力节点阶段仍然按“单机多 GPU 节点”部署，每台 GPU 服务器都是一个独立算力节点。每个参与调度的节点都必须部署：
|
||||
|
||||
- Compute API。
|
||||
- Compute Agent。
|
||||
- File Gateway。
|
||||
- LLaMA-Factory 宿主机目录和训练依赖。
|
||||
- CUDA、NVIDIA Driver、NCCL、PyTorch。
|
||||
- 本地数据盘 `/data/yg-ft`。
|
||||
- 本地日志和训练产物目录。
|
||||
|
||||
网络策略保持单向：
|
||||
|
||||
```text
|
||||
应用服务器 -> 算力节点 A Compute API/File Gateway
|
||||
应用服务器 -> 算力节点 B Compute API/File Gateway
|
||||
应用服务器 -> 算力节点 C Compute API/File Gateway
|
||||
```
|
||||
|
||||
默认不要求：
|
||||
|
||||
```text
|
||||
算力节点 -> 应用服务器
|
||||
算力节点 A -> 算力节点 B
|
||||
```
|
||||
|
||||
多节点任务调度由应用平台统一完成。应用平台从 `compute_nodes` 读取节点地址、权重、标签、启用状态、维护状态和健康检查结果；从 `resource_replicas` 判断目标节点是否已有所需数据集/模型副本；缺失时创建 `resource_sync_jobs`，通过目标节点 File Gateway 同步资源。
|
||||
|
||||
调度策略：
|
||||
|
||||
- 默认自动调度，按节点健康、标签、GPU 空闲、队列长度、节点权重和资源副本命中率排序。
|
||||
- 支持管理员/高级用户手动指定节点或 GPU。
|
||||
- `disabled` 节点不参与调度。
|
||||
- `draining` 节点不接收新任务，但允许已有任务跑完。
|
||||
- `maintenance/offline` 节点只允许查看和清理，不允许提交训练任务。
|
||||
|
||||
## 6. Compute API 接入标准
|
||||
|
||||
为预留其他训练平台，应用平台只依赖统一算力接口，不直接依赖 LLaMA-Factory 命令。
|
||||
@@ -241,6 +278,9 @@ LOG_DIR=/opt/yg-ft/logs/backend
|
||||
COMPUTE_API_BASE_URL=https://compute.internal:9100
|
||||
COMPUTE_SERVICE_TOKEN=***
|
||||
FILE_GATEWAY_BASE_URL=https://compute.internal:9101
|
||||
COMPUTE_STATUS_SYNC_MODE=polling
|
||||
COMPUTE_POLL_INTERVAL_SECONDS=10
|
||||
COMPUTE_POLL_BATCH_SIZE=100
|
||||
```
|
||||
|
||||
算力平台：
|
||||
@@ -250,9 +290,10 @@ COMPUTE_ENV=prod
|
||||
COMPUTE_HOST_ID=gpu-node-01
|
||||
COMPUTE_API_PORT=9100
|
||||
FILE_GATEWAY_PORT=9101
|
||||
APP_CALLBACK_BASE_URL=https://app.internal/api/v1/compute/callbacks
|
||||
APP_SERVICE_TOKEN=***
|
||||
COMPUTE_SERVICE_TOKEN=***
|
||||
ENABLE_APP_CALLBACK=false
|
||||
LLAMA_FACTORY_HOME=/opt/LLaMA-Factory
|
||||
LLAMA_FACTORY_HOST_PATH=/opt/LLaMA-Factory
|
||||
YG_FT_DATA_ROOT=/data/yg-ft
|
||||
LOG_DIR=/opt/yg-ft/logs/compute
|
||||
CUDA_VISIBLE_DEVICES=0,1,2,3
|
||||
@@ -295,11 +336,74 @@ CUDA_VISIBLE_DEVICES=0,1,2,3
|
||||
- ERROR 日志能触发告警。
|
||||
- 日志、数据集、模型、产物所在磁盘容量有监控和告警。
|
||||
|
||||
## 11. 仍需确认的问题
|
||||
## 11. Docker Compose 文件规划
|
||||
|
||||
当前项目按应用服务器和算力服务器拆分了两套 Docker 部署文件，均采用代码外挂方式运行：
|
||||
|
||||
```text
|
||||
docker/
|
||||
app/
|
||||
Dockerfile.backend # Backend API 运行时镜像，代码通过 volume 挂载到 /app
|
||||
Dockerfile.frontend # Nginx 前端运行时镜像，frontend/dist 通过 volume 挂载
|
||||
docker-compose.yml # 应用服务器：frontend、backend-api、postgres、redis
|
||||
.env.example
|
||||
compute/
|
||||
Dockerfile.compute # CUDA + Python + Compute API 运行时镜像
|
||||
docker-compose.yml # 算力服务器：compute-api，预留 agent/file gateway 拆分
|
||||
.env.example
|
||||
```
|
||||
|
||||
项目根目录不再保留 `Dockerfile` 和 `docker-compose.yml`，避免与拆分部署入口混淆。
|
||||
|
||||
应用服务器启动：
|
||||
|
||||
```bash
|
||||
cd docker/app
|
||||
cp .env.example .env
|
||||
docker compose --profile build run --rm frontend-builder
|
||||
docker compose up -d --build
|
||||
```
|
||||
|
||||
算力服务器启动：
|
||||
|
||||
```bash
|
||||
cd docker/compute
|
||||
cp .env.example .env
|
||||
docker compose up -d --build
|
||||
```
|
||||
|
||||
应用服务器与算力服务器独立部署时，需要在 `docker/app/.env` 中配置：
|
||||
|
||||
```env
|
||||
COMPUTE_API_BASE_URL=http://<compute-server-ip>:9100
|
||||
FILE_GATEWAY_BASE_URL=http://<compute-server-ip>:9101
|
||||
COMPUTE_SERVICE_TOKEN=change_me
|
||||
```
|
||||
|
||||
这些地址在当前 Docker 阶段通过环境变量动态配置。后续多算力节点阶段建议升级为数据库配置，由应用平台从 `compute_nodes` 表读取节点地址、权重、标签、健康状态和启用状态，并在“算力节点管理”页面维护。
|
||||
|
||||
多节点后，每台算力服务器各自进入 `docker/compute` 启动一套算力服务，并在应用平台中登记为一条 `compute_nodes` 记录：
|
||||
|
||||
```text
|
||||
gpu-node-01 -> http://10.10.20.31:9100 / http://10.10.20.31:9101
|
||||
gpu-node-02 -> http://10.10.20.32:9100 / http://10.10.20.32:9101
|
||||
gpu-node-03 -> http://10.10.20.33:9100 / http://10.10.20.33:9101
|
||||
```
|
||||
|
||||
算力服务器需要在 `docker/compute/.env` 中配置：
|
||||
|
||||
```env
|
||||
ENABLE_APP_CALLBACK=false
|
||||
COMPUTE_SERVICE_TOKEN=change_me
|
||||
LLAMA_FACTORY_HOST_PATH=/opt/LLaMA-Factory
|
||||
YG_FT_DATA_ROOT_HOST=/data/yg-ft
|
||||
```
|
||||
|
||||
## 12. 仍需确认的问题
|
||||
|
||||
- 生产环境是否已有统一 ELK/OpenSearch、Filebeat/Vector 标准配置。
|
||||
- 数据库和 Redis 是否由企业基础设施统一提供，还是由项目自行部署。
|
||||
- PostgreSQL/Redis 开发阶段采用项目自带部署；生产阶段是否切换企业统一基础设施，以及对应 SLA 仍需确认。
|
||||
- 是否需要 PostgreSQL 主备、备份恢复、审计日志长期归档的明确 SLA。
|
||||
- 大文件上传是否需要断点续传、限速、病毒扫描或 DLP 检测。
|
||||
- 应用服务器与算力服务器之间是否允许双向访问，还是只能应用侧主动访问算力侧。
|
||||
- 是否需要未来支持多台 GPU 节点调度；如果需要，Compute API 需要提前设计节点注册和调度策略。
|
||||
- 应用服务器与算力服务器默认只开通应用侧主动访问算力侧；如后续需要实时回调，再单独评估双向网络策略。
|
||||
- 多算力节点已按单机多 GPU 节点扩展设计；仍需确认是否需要节点组、租户绑定节点、同步限速和资源副本清理审批。
|
||||
|
||||
Reference in New Issue
Block a user