forked from Eeveid/lightOps
80 lines
2.3 KiB
Markdown
80 lines
2.3 KiB
Markdown
# 应用管理
|
||
|
||
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 拼接字符。
|
||
- 命令执行使用短超时，避免任务长期卡住。
|
||
|