Revert "merge: integrate extension auto-update"
This reverts commit322475860a, reversing changes made tof52d9d7413.
This commit is contained in:
inman committed
1 parent
b2e33e2e5d
commit
81a0cdac8e
47 files changed
+169
-3108
No files matched your search
+2
-35
@@ -31,39 +31,6 @@
|
||||
- `user_channels`、`tasks.channel_id` 和 `agentbus_deliveries` 共同保存入站归属、accepted 受理回执和最终 result 回执。回执以 `(channel_id, inbound_frame_id, delivery_kind)` 幂等，发送失败会重试，进程重启或 WebSocket 重连后仍会继续投递；因此不会因为超过原等待时长而丢掉最终回复。
|
||||
- ERP 插件领取按任务 `assigned_user_id` 使用账户级数据库锁和 FIFO confirmed 队列：同一平台/ERP 账户在任意时刻最多一个 ERP execution，该账户的其他任务留在服务端等待；不同账户的活跃或待执行任务互不占用队列位置、可独立领取执行。管理员的组织级查看权限与执行权限完全分离：实时执行事件、插件领取、执行回执以及强制删除后的浏览器清理命令都只发送或接受任务 `assigned_user_id` 对应的登录账号，管理员不会因为能查看员工任务而收到或处理该员工的插件任务。已开始写入但结果不确定的任务只阻塞同一账户的后续领取，直到人工回查收敛或任务被明确强制删除。
|
||||
|
||||
## Chrome 插件自动更新
|
||||
|
||||
插件更新由本控制平面统一编排，不在 Windows Server 上增加单独的 LTJT 更新服务。中央 Node 服务把管理员批准的 ZIP 写入 OSS 私有对象，再通过阿里云 ECS 云助手向目标 Windows Server 下发一次性 PowerShell 命令。云助手只负责本次文件部署；版本判断、空闲门禁、重试、状态和验版均保存在控制平面与 PostgreSQL 中。
|
||||
|
||||
更新链路为：
|
||||
|
||||
```text
|
||||
管理员发布版本化 ZIP
|
||||
→ 服务端校验 ZIP 边界、Manifest 身份/版本、必需文件和 SHA-256
|
||||
→ 私有对象写入 OSS，并把该版本设为组织活动版本
|
||||
→ 浏览器心跳上报当前版本与插件内存/持久化空闲证明
|
||||
→ 服务端汇总同一 ECS 实例上全部账号、任务、执行尝试与待回查状态
|
||||
→ 完全空闲后，以主机级数据库锁启动 ECS 云助手命令
|
||||
→ Windows 下载短时、主机绑定的服务端地址并再次校验 SHA-256 与 Manifest
|
||||
→ 新目录暂存，旧目录保留为 `.previous`，原子切换失败则回滚
|
||||
→ 平台请求插件后台再次检查空闲状态并执行 `chrome.runtime.reload()`
|
||||
→ 刷新平台页；目标版本的新心跳到达后标记 `verified`，再开放新 ERP 任务
|
||||
```
|
||||
|
||||
不存在固定的业务等待时间：已经空闲的主机会立即开始；仍有 `accepted/running/write_started/submitted/uncertain/reconciliation_pending` 边界时持续等待真实状态收敛。更新处于等待、执行、待重载、配置缺失或最终失败时，页面和服务端领取接口都会阻止新的 ERP 写任务。单个主机版本最多自动尝试三次；失败信息经过 URL/令牌脱敏后才写入状态。
|
||||
|
||||
多台、多账号 Windows Server 按以下方式配置：
|
||||
|
||||
1. 每台 ECS Windows Server 必须安装并正常连接阿里云云助手。中央服务所在机器需要访问 OSS 与 ECS API；每台 Windows Server 需要能访问 `APP_ORIGIN` 的 HTTPS 插件下载接口。该链路不依赖 Google 服务。
|
||||
2. 每台 Windows Server 统一使用 `C:\ProgramData\LTJT\chrome-extension\ltjt-order-assistant`。同机的每个 Windows/Chrome profile 都只需在 `chrome://extensions` 中把这个相同目录“加载已解压的扩展程序”一次。
|
||||
3. `0.5.167` 是引导版本，包含安全状态与受控重载协议。现有 `0.5.166` 及更旧 profile 必须最后一次人工迁移到上述共享目录；旧代码无法凭服务端单方面获得新协议。完成全部 profile 引导前保持 `EXTENSION_AUTO_UPDATE_ENABLED=false`。
|
||||
4. 为中央服务配置仅允许目标 ECS 实例执行命令和读取调用结果的 RAM 身份，并填写 `ALIBABA_CLOUD_ACCESS_KEY_ID`、`ALIBABA_CLOUD_ACCESS_KEY_SECRET`，使用临时身份时同时填写 `ALIBABA_CLOUD_SECURITY_TOKEN`。不要复用宽权限 OSS 身份。
|
||||
5. 配置 OSS、`EXTENSION_UPDATE_OSS_KEY_PREFIX`、共享安装目录、包大小与命令超时，再启用 `EXTENSION_AUTO_UPDATE_ENABLED=true` 并重启控制平面。生产 `APP_ORIGIN` 必须是 Windows Server 可达的 HTTPS 地址。
|
||||
6. 管理员在 `/accounts` 给每个非管理员账号填写 ECS 地域 ID 与实例 ID。同一 Windows Server 上的多个账号填写完全相同的一组值，服务端会把它们合并成一个主机级空闲门禁和更新状态。
|
||||
7. 管理员在 `/accounts` 的“插件版本发布”区域选择版本化 ZIP。服务端只接受比当前活动版本更高的版本；同一版本不同哈希会被拒绝。发布后无需逐台登录，在线浏览器的正常心跳会启动更新并完成验版。
|
||||
|
||||
更新命令只允许操作配置的 `ProgramData\LTJT` 子目录，不安装 CRX、不修改 Chrome 策略、不操纵交互式桌面。若某个 profile 长期离线，它不会阻塞在线 profile；再次启动时会从已更新的共享目录加载目标版本并在下一次心跳完成验证。发布、迁移和运行状态由迁移 `019_extension_host_updates` 中的 `extension_releases`、`extension_host_updates` 以及账号 ECS 映射保存。
|
||||
|
||||
## 任务级会话续接
|
||||
|
||||
- `agent_sessions` 将一个业务任务绑定到一个 Superagent 会话；`agent_session_messages` 加密保存每一轮用户/Agent 消息并使用独立幂等键。
|
||||
@@ -174,13 +141,13 @@ npm run data:retention
|
||||
npm run dev
|
||||
```
|
||||
|
||||
`npm run dev` 和 `npm start` 会先执行数据库迁移，再启动控制平面；直接运行 `control-plane/src/server.ts` 或构建后的 `server.js` 时，服务也会在启动前检查必需迁移 `019_extension_host_updates`，缺失时拒绝监听端口。`db:migrate` 和管理员初始化需要可连接的 PostgreSQL。开发机没有数据库时，可以运行 `npm run test:control-plane` 完成无数据库静态/健康烟测。
|
||||
`npm run dev` 和 `npm start` 会先执行数据库迁移，再启动控制平面；直接运行 `control-plane/src/server.ts` 或构建后的 `server.js` 时，服务也会在启动前检查必需迁移 `018_agentbus_account_workers`，缺失时拒绝监听端口。`db:migrate` 和管理员初始化需要可连接的 PostgreSQL。开发机没有数据库时，可以运行 `npm run test:control-plane` 完成无数据库静态/健康烟测。
|
||||
|
||||
`/health/ready` 同时检查 PostgreSQL 可用性和必需 schema 版本；迁移未完成时返回 503，并标明 `required_migration`，避免任务在数据库结构未升级时进入解析队列。
|
||||
|
||||
## 生产部署
|
||||
|
||||
1. 复制 `.env.production.example` 为部署机受保护的 `.env.production`，填入 `DEPLOYMENT_REVISION`、PostgreSQL URL、`DATABASE_SCHEMA`、字段加密密钥、外部解析 Key 和 OSS 凭据，并确认 `AGENTBUS_LOG_PAYLOADS=false`。首次部署 `0.5.167` 时保持 `EXTENSION_AUTO_UPDATE_ENABLED=false`；只有完成共享目录引导、HTTPS 可达性、受限 ECS RAM 凭据和账号实例映射后再启用。生产数据库可使用现有 PostgreSQL 实例中的新 Schema；迁移程序会创建 Schema，不会触碰其他 Schema 的测试表。
|
||||
1. 复制 `.env.production.example` 为部署机受保护的 `.env.production`，填入 `DEPLOYMENT_REVISION`、PostgreSQL URL、`DATABASE_SCHEMA`、字段加密密钥、外部解析 Key 和 OSS 凭据，并确认 `AGENTBUS_LOG_PAYLOADS=false`。生产数据库可使用现有 PostgreSQL 实例中的新 Schema；迁移程序会创建 Schema，不会触碰其他 Schema 的测试表。
|
||||
2. 在正式数据库上线前执行并验证备份：`infra/backup-postgres.sh`。
|
||||
3. 使用 `docker compose --env-file .env.production up -d --build` 启动；Compose 会先执行数据库迁移，再启动控制平面。Compose 中的本地 PostgreSQL 仅用于 `--profile local`，生产 `DATABASE_URL` 指向受保护的远程数据库。
|
||||
4. 首次启动后在容器内通过 `docker compose exec -e ADMIN_USERNAME=admin -e ADMIN_PASSWORD='replace-with-password' control-plane node .build/control-plane/src/admin-cli.js bootstrap` 创建管理员；不要把密码写入镜像或 Git。
|
||||
|
||||
Reference in new issue
Block a user