实现 LightOps 运维面板基础功能

docs/application-management.md

@@ -0,0 +1,79 @@
+# 应用管理
+
+LightOps 应用管理是在现有 Agent 任务架构上的增量模块。它不会替代进程、服务、Docker、Nginx、文件或日志模块，而是把用户真正需要运维的运行资产统一归一为 `Application` 模型，并与已有模块建立跳转和关联。
+
+## 模型
+
+`lightops-common` 定义：
+
+- `Application`
+- `ApplicationType`
+- `ApplicationProviderType`
+- `ApplicationStatus`
+- `ApplicationRelation`
+- `ApplicationDetail`
+
+Server 使用 SQLite 保存应用发现结果：
+
+- `applications`
+- `application_relations`
+- `application_actions`
+
+这些表是缓存和操作历史，不是第二套控制面。机器上的真实操作仍然只通过 Agent 任务执行。
+
+## Server 流程
+
+- `GET /api/apps` 返回所有 Agent 的应用缓存。
+- `GET /api/agents/:id/apps` 返回某个 Agent 的应用缓存。
+- `POST /api/agents/:id/apps/discover` 向 Agent 下发 `app.discover`，并写入返回的应用和关系。
+- 启动、停止、重启、日志等应用操作会通过任务系统下发给 Agent。
+- 危险操作写入 `audit_logs` 和 `application_actions`。
+- `is_system = true` 的应用默认只读。
+
+## Agent 流程
+
+Agent 通过现有动作白名单暴露 `app.*` 动作，并聚合多个 Provider 的结果：
+
+- `SystemdAppProvider`
+- `DockerAppProvider`
+- `NginxSiteAppProvider`
+- `PackageAppProvider`
+- `LightOpsManagedAppProvider`
+
+MVP 的发现策略会主动过滤系统包和系统服务，不会把所有系统包、系统依赖或基础服务都展示为应用。它只识别具有明确运维价值的服务型应用。
+
+## MVP 动作
+
+已实现：
+
+- `app.discover`
+- `app.list`
+- `app.get`
+- `app.start`
+- `app.stop`
+- `app.restart`
+- `app.reload`，当前支持 Nginx/systemd 的可用场景
+- `app.logs`
+- `app.manage_custom`
+- `app.create_systemd_service`
+- `app.unmanage`
+
+暂缓实现：
+
+- 完整卸载
+- 完整备份/恢复
+- PM2
+- Supervisor
+- 完整 Docker Compose 生命周期
+- 复杂应用关系图谱
+- 批量更新
+
+## 安全策略
+
+- Agent 使用 `tokio::process::Command` 并通过参数数组传参。
+- 不暴露通用 shell 执行。
+- 系统应用默认只读。
+- 自定义 systemd 服务名会被安全过滤。
+- `start_command` 会拒绝常见 shell 拼接字符。
+- 命令执行使用短超时，避免任务长期卡住。
+

docs/architecture.md

@@ -0,0 +1,61 @@
+# LightOps 架构
+
+LightOps 是一个极轻量探针式运维面板。一个 Server 负责 Web UI、SQLite 数据、认证、审计日志、任务调度和 Agent 连接注册；每台被管理主机只运行一个 Rust Agent，不提供 Web UI，也不保存本地复杂状态。
+
+## 控制面
+
+- Server 向浏览器提供 REST API，并向 Agent 提供一个 WebSocket 入口。
+- 浏览器请求通过 Bearer JWT 鉴权。浏览器 WebSocket 端点也支持通过 `?token=` 携带同一个 Token。
+- SQLite 是默认数据库，不依赖 Redis、MySQL、Elasticsearch 或外部队列。
+- Agent 连接保存在内存中，结构为 `agent_id -> sender`。
+- 任务响应通过 `task_id` 关联，并受超时机制约束。
+- 每个 Agent 连接都有独立 `connection_id`。同一个 Agent 重连时，新连接会替换旧连接；旧连接退出时不会把新连接误标为离线。
+- 危险操作写入 `audit_logs`。
+
+## 数据面
+
+- Agent 主动连接 `wss://server/api/agent/ws`。
+- 首次连接使用一次性注册 Token。
+- Server 返回长期 Secret，Agent 将其保存到 `/etc/lightops/agent.toml`。
+- 后续连接使用 `agent_id + secret` 鉴权。
+- 默认每 30 秒发送心跳和指标。
+- Server 默认每 30 秒发送协议级 `server.ping`，Agent 收到后立即返回 `agent.pong`。
+- Server 和 Agent 都会检测约 100 秒的连接静默时间，超时后主动断开并触发 Agent 退避重连。
+- Agent 连接失败使用指数退避并增加毫秒级抖动，避免大量节点同时重连冲击 Server。
+- Agent 断开后，Server 会立即失败该 Agent 未完成的 pending 任务，避免用户等待任务超时。
+- Server 不主动连接被管理节点，被管理节点无需开放入站端口。
+
+## 协议
+
+所有 Agent 消息都是带 `type` 字段的 JSON：
+
+- `agent.hello`
+- `agent.heartbeat`
+- `agent.pong`
+- `server.ping`
+- `agent.accepted`
+- `task.request`
+- `task.response`
+- `stream.open`
+- `stream.data`
+- `stream.close`
+- `error`
+
+## 安全模型
+
+- 生产环境 Server 应只通过 HTTPS/WSS 暴露。
+- 注册 Token 一次性使用并带过期时间。
+- Agent Secret 和注册 Token 在 Server 端只保存哈希。
+- 密码使用 Argon2 保存。
+- Agent 只执行白名单动作。
+- 不提供通用 shell 执行 API。
+- 终端打开、文件删除、服务停止、Nginx 重载和 Docker 破坏性操作都会审计。
+- 文本文件读写默认限制大小。
+- Docker CLI 访问意味着 Docker Socket/root 等价风险，请只在可信主机上部署 Agent。
+
+## MVP 边界
+
+- Docker Provider 抽象为 `DockerProvider`，MVP 使用 Docker CLI 实现。
+- Nginx 目录布局优先支持 Debian/Ubuntu 的 `/etc/nginx/sites-available` 和 `/etc/nginx/sites-enabled`。
+- 文件管理是懒加载、非递归扫描。
+- 日志按需读取或订阅，不做持久化日志索引。