Collabora Online 深度解析一条请求的旅程与完整部署实战【免费下载链接】onlineIssue tracker only. Active development is on Gerrit at https://gerrit.collaboraoffice.com/.项目地址: https://gitcode.com/gh_mirrors/on/onlineCollabora Online 是基于 LibreOffice 引擎的开源在线办公套件在浏览器中提供文档、表格、演示的实时协作编辑典型场景是配合 Nextcloud 等文件服务器做企业私有化部署。没有下载—编辑—上传之后Collabora Online 解决什么问题没有它的时候浏览器里的办公体验是下载到本地 → 编辑 → 再传回去两人打开同一份文件立刻版本打架想要实时协作就得依赖 SaaS文档内容必须出网。引入 Collabora Online 之后LibreOffice 引擎跑在服务端浏览器退化成只负责画像素的瘦客户端文件本身始终留在你自己的文件服务器上通过 WOPI 协议按需取回。所谓实时协作就是多个 WebSocket 会话复用同一个服务端文档进程把操作增量互相同步。追踪一条 WOPI 请求从浏览器到 Kit 渲染进程按数据流顺序走一遍用户在 Nextcloud 里点打开文件服务器带着WOPISrc参数向办公域名发起 WOPI 请求反向代理 / Ingresskubernetes/helm/collabora-online/templates/reverse-proxy/—— 做按文档的亲和路由。关键设计同一文档的所有请求必须落到同一实例nginx 对 WOPISrc 做哈希取模保证路由稳定coolwsd 主服务docker/from-source-gh-action/start-collabora-online.sh—— 入口守护进程监听 9980 端口处理 HTTP 与 WebSocket。两个要点先校验文件服务器签名再为该文档分配或复用渲染进程Kit 渲染进程chroot 于 /opt/cool/child-roots—— 真正在服务器上跑的 LibreOffice。每个文档一个独立进程由 coolforkit-caps 以 chroot 方式 fork 进去文件视野只有只读的 systemplate 系统模板。后续的按键、光标、选区都走那条长连接 WebSocket客户端只接收瓦片图更新文档内容状态存在 Kit 进程内存里保存时经 WOPI 写回文件服务器。上游源码里 wsd/入口、kit/渲染、common/两者共享的协议与加密的三层分工正是这条链路的体现——注意本仓库托管的是构建与发布物C 源码评审在上游 Gerrit。从克隆到运行最短路径先说一个容易踩空的点克隆本仓库你会发现里面没有 C 源码——它承担 issue 跟踪、nightly 镜像和 Helm chart 的发布。所以跑起来有两条现实路径。最快的一条拉官方镜像起单实例无需文件服务器自带测试页适合先体验docker run -d --name cool -p 9980:9980 -e aliasgroup1http://office.example.com collabora/code生产的一条chart 就在这个仓库里直接安装git clone https://gitcode.com/gh_mirrors/on/online cd online/kubernetes/helm/collabora-online helm install cool . -f my-values.yamlKit 进程内存预算怎么算量级参考全部可对照 chart 默认值单个文档渲染进程内存按 256MB 计pod 内存 基础开销 256MB × 想同时打开的文档数chart 自带告警模板kit_assigned_count单 pod 打开的文档数warning8、critical10即单 pod 舒适区约 10 篇文档HPA 默认 minReplicas2、maxReplicas100按 CPU 70% / 内存 50% 扩缩但 HPA 只能靠 CPU 内存间接估算容量硬约束仍是单 pod 文档数瓦片/幻灯片缓存由 coolwsd.xml 里的缓存开关控制容器内已挂好 /opt/cool/cache配置文件与安全设计一个进程被攻破后如何不扩散关键配置文件coolwsd.xml/etc/coolwsd/—— 主配置端口、SSL、进程池chart 的coolwsd_xml_content可整文件覆盖coolkitconfig.xcu—— LibreOffice 引擎侧参数proof_keyRSA 4096—— WOPI 签名密钥必须在副本间、升级间保持稳定否则所有文件服务器签名校验失效GitOpsArgo/Flux环境务必自建 secret 并用proofKeysSecretRef指向它否则 chart 内置的自动生成会在每次渲染时换钥start-collabora-online.shdocker/from-source-gh-action/—— 容器入口指认 chroot、缓存与系统模板路径安全部分按目的 → 手段读渲染进程被攻破也不外溢到宿主→ 每个 Kit 进程关在 chroot child root 里文件视野只剩只读 systemplate收窄系统调用面→ Seccomp 过滤器默认拒绝defaultAction: SCMP_ACT_ERRNO白名单见 docker/cool-seccomp-profile.jsonchart 的installCOOLSeccompProfile通过 DaemonSet 下发到各节点 kubelet 目录防止文件服务器被仿冒→ WOPI proof key 的 RSA 签名校验防止管理接口暴露→ /cool/getMetrics、/cool/adminws、/browser/dist/admin 需对外封禁chart 附带 nginxDeny 假服务专门兜这些路径监控盯两个指标就够kit_assigned_count是单 pod 打开的文档数最直接的容量信号document_active_views_active_count_total是并发编辑人数一篇文档几十人同编会显著推高内存。选型与落地建议什么时候值得引入 Collabora Online适合并发协作人数 10 人以上、数据不能出网、已有 Nextcloud/ownCloud 的企业——后两者原生支持 WOPI接入成本最低高可用副本数 2 起步即可容忍单 pod 故障多副本必须搭配 WOPISrc 哈希亲和chart 的 reverseProxy 或 Ingress 注解否则用户会随机打到没有该文档的实例容量估算1 pod ≈ 10 篇文档50 人团队按 20% 文档打开率算需 10 个 pod再加两成余量边界它不是完整办公平台——没有日历、邮件也不提供文件存储存储与账号体系全部要你自己给只有零星只读预览需求或团队很小的话引入它是过度设计下一步Collabora Online 的价值可以一句话概括文档引擎跑在你自己的网络里浏览器只负责画瓦片文件服务器始终掌握文件与权限。建议先按上文第一条命令在本地起单实例熟悉界面再打开 values.yaml 逐行注释规划生产参数上线前把 prometheus-rules.yaml 里的告警规则读一遍确认你的监控覆盖了文档数与编辑人数这两个核心指标。【免费下载链接】onlineIssue tracker only. Active development is on Gerrit at https://gerrit.collaboraoffice.com/.项目地址: https://gitcode.com/gh_mirrors/on/online创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考