# 应用管理

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 拼接字符。
- 命令执行使用短超时，避免任务长期卡住。