WeKnora：有据问答、限定记忆与可维护运维
部署 WeKnora：固定镜像、按需启用服务，并验证数据恢复
区分 Compose、Lite 和开发模式，理解缓存镜像、迁移风险与可选组件的边界。
你将学会
- 先选择部署形态，再增加组件
- 更新源码不会自动替换旧镜像
- 健康、功能与恢复分别验收
开始前需要
- 了解 HTTP 与容器基本概念
- 理解文档段落和模型提供方的区别
分清入库、检索、答案支持和记忆范围，并设计基于证据的验收练习。
先看结论
- 核心服务与可选组件的成本不同。
- 升级时应确认拉取了选定版本镜像。
- 健康检查不能代替功能和恢复验证。
先选择部署形态，再增加组件
安装文档区分基于 PostgreSQL 与 Redis 的标准 Compose、使用 SQLite 和内存协调的 Lite，以及应用进程运行在宿主机上的开发模式。该版本将桌面应用标记为尚未正式发布，不能把目录里出现的所有打包入口都当成同等成熟的发行产品。
标准部署应先启动核心服务，再为明确需求增加 profile。文档中的硬件起点只是规划参考，不是本地模型、大型扫描文档或完整可观测栈的容量保证。模型推理和解析任务的资源需求应单独估算，而不是直接照抄最低配置。
更新源码不会自动替换旧镜像
在审核过的配置中选定 WEKNORA_VERSION，拉取对应镜像，再重建相关服务。README 明确提示，只执行 up 可能复用本地缓存，导致界面版本落后于下载的 release。本系列固定的源码提交，也不会替读者固定镜像标签或摘要。
密钥应在部署环境生成和保存，不能贴进文章或提交到仓库。前后端端口只是默认值，并不证明服务处于私网。应明确绑定地址或防火墙规则，在访问控制验证完成之前保持内部访问，避免把“本地启动成功”误当成可以直接公开上线。
健康、功能与恢复分别验收
后端健康检查只是第一关，还需验证模型连接、解析虚构文档、召回预期段落并打开回答引用。容器中的 localhost 指向容器自身；文档使用 host.docker.internal 连接宿主机 Ollama，但目标系统是否支持这个地址仍需实际确认。
自动数据库迁移意味着升级不只是替换镜像。重要数据升级前应备份数据库、存储文件和必要配置，并进行恢复演练。不要把删除数据卷的停止命令或数据库清理目标当作常规排错手段。本系列没有执行真实部署或恢复演练。
如何选择
| 比较维度 | 方案 A | 方案 B |
|---|---|---|
| Best when | You need predictable behavior and easy auditing | You need adaptive optimization and have reliable telemetry |
| Main risk | May leave performance on the table | Can become difficult to explain or debug |
实施步骤
- 1
明确标准、Lite 或开发形态。
- 2
审核密钥、镜像版本和暴露端口。
- 3
启动核心服务并验收虚构问答。
- 4
数据迁移前验证备份与恢复。
可复制示例
docker compose ps
curl http://localhost:8080/health常见问题
升级后界面为什么可能没变？
文档提示 up 可能复用缓存镜像，应检查选定标签和实际拉取结果。
首次部署要启用 full 吗？
只有需要相应组件且已审核资源和安全设置时才启用。
资料来源
- WeKnora / README.md来源核查 2026-09-14
- WeKnora / website-docs/01-getting-started/02-installation.md来源核查 2026-09-14
- WeKnora / website-docs/01-getting-started/03-quickstart.md来源核查 2026-09-14