feat(deploy): 为更新组件增加定时维护与双保险

README.md

@@ -184,9 +184,11 @@ update.sh 脚本用于自动更新 EasyAI 应用，包含以下功能：
 
 新安装默认启用可查询进度的在线更新模式。管理员在页面发起更新后，即使主服务重启导致原请求断开，页面也会根据任务编号继续查询最终结果。存量部署如果没有 `easyai-updater` 容器，更新脚本会保留 Watchtower 模式；已经显式设置 `SYSTEM_UPDATE_MODE=legacy_watchtower` 的环境也保持该模式。只有新安装默认启用 updater。新模式只管理 `easyai-server`、`easyai-web` 和 `ws-gateway`，数据库、Redis、RabbitMQ 等基础服务仍按原部署流程维护。
 
-更新执行器 `easyai-updater` 由 Watchtower 单独守护，默认每 24 小时检查并更新自身。它的任务状态保存在宿主机 `data/update-state` 中，自身更新或意外重启后会继续恢复未完成任务；Watchtower 不再接管三个核心服务，因此页面任务结果不会与后台静默替换相互冲突。
+更新执行器 `easyai-updater` 由 Watchtower 默认每 24 小时检查更新，同时由宿主机定时任务每六小时直接检查更新，提供两条独立维护路径。它的任务状态保存在宿主机 `data/update-state` 中，自身更新或意外重启后会继续恢复未完成任务；Watchtower 不再接管三个核心服务，因此页面任务结果不会与后台静默替换相互冲突。
 
-受控更新使用仓库内的 `system-update/release-manifest.json` 作为稳定发布清单，Compose 会以只读方式挂载给 updater。发布新正式镜像时必须同步更新清单中的不可变摘要、镜像大小和版本标识；服务器执行 `update.sh` 拉取部署仓库后即可获得清单，不需要手工向运行目录复制文件。
+受控更新默认直接获取部署仓库 `main` 分支的 `system-update/release-manifest.json`，无需先在服务器执行 `git pull`。页面检测、手动更新和自动更新使用同一发布清单；任务开始后将清单保存在任务记录中，服务重启恢复时继续使用原目标。发布新正式镜像时必须同步发布清单中的不可变摘要、镜像大小和版本标识，不能只修改官方站运行版本或推送 `latest` 镜像。
+
+发布源不可用时会提示暂时无法检查更新，并保留当前服务；不会用历史清单宣称已是最新。`UPDATE_MANIFEST_URL` 可配置私有发布源，留空时使用官方部署仓库。离线部署可显式设置 `UPDATE_MANIFEST_SOURCE=local`，此时读取 Compose 只读挂载的本地清单；需要自行维护该清单。旧部署中的 `UPDATE_MANIFEST_FILE` 路径覆盖不再影响默认远程模式。
 
 新安装或已有 updater 的部署无需手工编辑 `.env`。更新脚本会从 `scripts/update-env.d/010-managed-system-update.env` 应用以下缺省值：
 
@@ -203,7 +205,11 @@ EASYAI_DEPLOYMENT_SCHEMA_VERSION=2
 
 `SYSTEM_UPDATE_INTERNAL_TOKEN` 由 `start.sh` / `update.sh` 自动生成并持久化，不需要手工填写。`UPDATE_HEALTH_TIMEOUT_MS` 控制每个核心服务替换后的恢复等待时间，默认 300000 毫秒。私有镜像仓库需要先执行 `docker login`；更新器与仅负责其自更新的 Watchtower 都会只读挂载 `DOCKER_CONFIG_FILE` 指向的 Docker 登录配置。切换后执行一次 `./update.sh`，确认 `easyai-updater` 以及三个核心服务均处于可用状态。
 
-Watchtower 固定使用 `1.22.3`。内网启用更新、事件、历史、状态和健康接口，不映射主机端口。`WATCHTOWER_API_KEY` 与 `WATCHTOWER_HTTP_API_EVENTS_TOKEN` 是两个独立随机令牌，由 Bash 和 PowerShell 安全初始化流程补齐；浏览器只访问后端，不接触这些令牌。managed 模式只扫描 updater 并定期检查自身；Watchtower 模式关闭定期扫描，只在用户或系统明确提交更新时更新核心服务，避免任务与定时扫描无法对应。
+Watchtower 默认使用 `latest`。`start.sh/update.sh` 自动安装宿主机 cron，`start.ps1/update.ps1` 自动注册 Windows 计划任务；每六小时分别对 Watchtower 和已启用的 updater 执行 `docker compose pull <服务>`、`docker compose up -d --no-deps <服务>` 并确认健康状态。只在镜像或配置有变化时重建，拉取失败不会停止该服务的现有容器。一项维护失败仍继续处理另一项，日志保留各自结果并报告失败；因此 updater 的宿主机维护不依赖 Watchtower 可用。未启用 updater 的 legacy 部署跳过 updater，不自动切换更新模式。Watchtower 的 updater 24 小时更新计划保持不变，无需额外容器。Windows 任务使用当前登录用户，以便访问其 Docker Desktop；Docker 不可用时保留失败日志，下次计划重试。
+
+内网启用更新、事件、历史、状态和健康接口，不映射主机端口。`WATCHTOWER_API_KEY` 与 `WATCHTOWER_HTTP_API_EVENTS_TOKEN` 是两个独立随机令牌，由 Bash 和 PowerShell 安全初始化流程补齐；浏览器只访问后端。新安装及默认整组升级使用独立 `WATCHTOWER_SCOPE`（`easyai`），防止启动时清理其他部署的 Watchtower；定向升级和自定义监控目标保留原 scope，避免未重建的容器标签与新范围不匹配。managed 模式只扫描 updater，legacy 模式仍只在明确提交业务更新时执行原更新链路。
+
+定时任务按部署目录去重，重复运行部署脚本不会重复注册。最近一次结果写入 `data/infrastructure-update/last-run.log`。设置 `INFRASTRUCTURE_AUTO_UPDATE_ENABLED=false` 后再次执行部署脚本可移除本部署的定时任务；不改变 updater 的原有维护计划。启用时，官方镜像的旧版本标签自动迁移到 `latest`，自定义仓库或镜像摘要保持原值。旧客户需先由运维执行一次新版部署脚本，之后不用客户手工升级 Watchtower；只发布仓库不会自动把宿主机定时任务安装到未接入的机器。发布到官方 Watchtower `latest` 的镜像应先通过部署及旧接口兼容验收。
 
 两个页面入口共用计时和步骤窗口。updater 保存阶段完成时间到 `data/update-state/jobs`；无 updater 时后端保存任务和单任务锁到 MongoDB。刷新或重新登录后按站点与账号恢复任务查询。请求超时或服务断开不会自动创建另一项更新，旧接口无法读取的阶段会明确提示。后端重启时页面保留进度，提醒在 3–5 分钟后刷新检查版本；只有确认目标版本和服务恢复才显示完成。