在公司內(nèi)網(wǎng)搭一套能在線打開、編輯、協(xié)同處理 Word、Excel、PPT 的文檔服務(wù)OnlyOffice 幾乎是最繞不開的選擇只要你的機(jī)器上裝了 Docker用 Docker Compose 部署 OnlyOffice 又是目前公認(rèn)最省心的一條路。官方鏡像把 Nginx、Node.js、PostgreSQL、Redis 這些依賴都打在一個容器里寫一份十幾行的 yaml 就能把整套服務(wù)拉起來。這篇文章不打算只貼一份 docker-compose.yml 了事。我會把自己在實際部署里踩過的坑、反復(fù)確認(rèn)過的配置項、以及像 JWT 密鑰、持久化卷、反向代理、Moodle 集成這類容易翻車的地方全部串起來講清楚。適合正在做 OA、網(wǎng)盤、知識庫集成的開發(fā)也適合想在實驗環(huán)境快速體驗在線協(xié)同編輯的運維同學(xué)。1. 為什么用 Docker Compose 部署 OnlyOffice架構(gòu)與選型思路1.1 OnlyOffice 到底解決什么問題OnlyOffice 是一套開源的在線辦公套件核心能力是讓用戶直接在瀏覽器里打開和編輯 docx、xlsx、pptx 等 Office 格式文檔同時支持多人協(xié)同編輯、批注評論、版本歷史。和本地 Office 最大的區(qū)別在于你不需要把文件下載到桌面再上傳回去瀏覽器里改完服務(wù)端負(fù)責(zé)保存和回調(diào)整個編輯鏈路都在你自建的服務(wù)里完成。這套東西最常見的落地位置有三類一類是私有網(wǎng)盤或知識庫里的在線預(yù)覽和編輯比如 Nextcloud、Seafile一類是 OA/ERP 里的附件預(yù)覽讓審批附件不用下載就能看還有一類是教育平臺里的作業(yè)批改比如 Moodle 里直接打開 Word 文檔批注。說到底它解決的是“文檔內(nèi)容不出內(nèi)網(wǎng)”的問題數(shù)據(jù)在自己手里離線可用也方便做權(quán)限控制。1.2 Docker Compose 方案為什么比裸裝更省心OnlyOffice 底層不是一個單進(jìn)程應(yīng)用。它需要 Nginx 做入口Node.js 跑文檔服務(wù)PostgreSQL 存元數(shù)據(jù)Redis 做緩存RabbitMQ 做隊列。如果裸裝你得手動把這些依賴一個個準(zhǔn)備好版本不匹配、環(huán)境變量漏配、端口沖突任何一個環(huán)節(jié)都可能讓你半天起不來。官方提供的 onlyoffice/documentserver 鏡像把這些服務(wù)全部封進(jìn)一個容器里容器啟動時由內(nèi)部進(jìn)程管理器統(tǒng)一拉起。但問題是直接用 docker run 部署的命令越來越長環(huán)境變量、卷掛載、網(wǎng)絡(luò)參數(shù)混在一起時間久了根本沒法維護(hù)。Docker Compose 干的就是把這一堆參數(shù)寫進(jìn)聲明式配置一條 docker compose up -d 全部搞定。它帶來的好處很直接配置可以放進(jìn) Git 做版本管理換機(jī)器可以一鍵恢復(fù)團(tuán)隊協(xié)作時大家用同一份 yaml 而不是復(fù)制粘貼長命令。1.3 部署拓?fù)渥钚∨c生產(chǎn)兩種形態(tài)最簡部署只需要一個文檔服務(wù)器容器加幾個數(shù)據(jù)卷。官方鏡像在容器內(nèi)部已經(jīng)把 PostgreSQL、Redis、RabbitMQ 都內(nèi)置了所以你不需要額外跑數(shù)據(jù)庫容器。對中小團(tuán)隊、測試環(huán)境、內(nèi)部工具來說這種單容器形態(tài)是最穩(wěn)的因為少一個組件就少一類故障。生產(chǎn)環(huán)境如果想拆細(xì)可以把 PostgreSQL、Redis、RabbitMQ 分別用獨立容器或外部托管再把 OnlyOffice 容器通過環(huán)境變量指過去。這么做的收益是資源隔離更徹底、數(shù)據(jù)庫可以單獨備份擴(kuò)容但維護(hù)成本也上來了。我的建議是初期先用單容器跑通業(yè)務(wù)后再按需拆分別一上來就把整個架構(gòu)復(fù)雜化。流量路徑大致是這樣外部請求先到反向代理443代理轉(zhuǎn)發(fā)到宿主機(jī)映射端口比如 8080再進(jìn)入容器內(nèi)部 Nginx 的 80 端口。容器內(nèi)部再路由到文檔服務(wù)、轉(zhuǎn)換服務(wù)或者協(xié)同編輯的 WebSocket 服務(wù)。理解這條鏈路后面排查 502、WebSocket 連不上才有清晰的方向。2. 從零編寫 docker-compose.yml核心配置逐項拆解2.1 鏡像版本latest 還是固定 tag示例配置里我用的是 onlyoffice/documentserver:latest因為演示方便、第一次拉取不需要查版本號。但生產(chǎn)環(huán)境我強(qiáng)烈建議固定一個具體 tag。原因很簡單OnlyOffice 升級有時候會改存儲結(jié)構(gòu)、數(shù)據(jù)庫遷移腳本、JWT 策略你昨天還跑得好好的鏡像今天重新 pull 一下可能就起不來了。固定 tag 后升級變成你主動選擇的一個動作而不是某次重建容器時被動的意外。鏡像體積非常大印象里解壓后好幾個 GB拉取時間也比一般鏡像長。內(nèi)網(wǎng)環(huán)境如果拉不動正確做法是找一臺能聯(lián)網(wǎng)的機(jī)器先 docker pull再 docker save 成 tar 包導(dǎo)入內(nèi)網(wǎng)后面我會專門說。另外要注意這個容器對內(nèi)存不客氣。因為它內(nèi)部同時跑著數(shù)據(jù)庫、緩存、隊列、文檔服務(wù)實測內(nèi)存小于 2GB 時啟動很容易失敗或者用一段時間被 OOM 殺死。個人經(jīng)驗是至少 4GB 內(nèi)存起步生產(chǎn)場景建議 4 核 8GB。2.2 端口、網(wǎng)絡(luò)與容器名容器內(nèi)部 Nginx 監(jiān)聽的是 80 端口。宿主機(jī)如果已經(jīng)有 Nginx、Apache 或者別的 Web 服務(wù)占了 80就把對外端口映射成 8080 或某個高位端口。這里有個很多人不理解的點你暴露的是宿主機(jī)端口不是容器內(nèi)端口所以 8080:80 表示訪問宿主機(jī) 8080 就等價于訪問容器內(nèi) 80。容器名固定有一個好處日志、備份、docker exec 排查時不用每次去查隨機(jī) ID。restart 策略我統(tǒng)一用 unless-stopped意思是容器異常退出會自動拉起但你手動 stop 后它不會自己跑起來很適合長期運行的服務(wù)。網(wǎng)絡(luò)方面建議創(chuàng)建一個獨立 bridge 網(wǎng)絡(luò)。如果你的 OnlyOffice 要對接 Moodle、Nextcloud 或者其他容器化應(yīng)用把這些服務(wù)放進(jìn)同一個 docker network就可以用容器名互相訪問不需要把業(yè)務(wù)服務(wù)端口完全暴露到宿主機(jī)。2.3 JWT 與安全項最容易翻車的三個點OnlyOffice 從 7.2 版本開始默認(rèn)把 JWT 鑒權(quán)拉得很緊。文檔編輯器、文檔轉(zhuǎn)換服務(wù)、回調(diào)通知之間會通過 JWT 簽名做身份校驗一旦啟用所有請求都得帶上正確的簽名否則直接 401 或拒絕處理。環(huán)境變量里最關(guān)鍵的是這三個JWT_ENABLED 控制開關(guān)JWT_SECRET 是簽名密鑰JWT_HEADER 指定簽名放在請求頭的哪個字段。集成的第三方系統(tǒng)必須和 OnlyOffice 使用完全相同的 JWT_SECRET否則編輯器加載不出來、保存回調(diào)失敗、轉(zhuǎn)換接口報錯問題看起來五花八門根源往往就是這個密鑰對不上。密鑰生成可以用 openssl rand -hex 3232 字節(jié)的隨機(jī)十六進(jìn)制字符串足夠安全。如果你是在內(nèi)網(wǎng)使用還需要注意一個反向場景容器的回調(diào)請求目標(biāo)是某個內(nèi)網(wǎng)地址時可能會被 OnlyOffice 內(nèi)部的“拒絕訪問私有 IP”策略攔掉。遇到這種情況可以加上環(huán)境變量 ALLOW_PRIVATE_IP_ADDRESStrue讓容器允許回調(diào)到 192.168 / 10 / 172.16 這類私有網(wǎng)段。2.4 持久化卷哪些目錄必須掛不掛卷的容器就像一次性用品容器一刪數(shù)據(jù)全沒。OnlyOffice 官方鏡像聲明的持久化目錄有這幾個容器內(nèi)路徑作用丟失影響/var/www/onlyoffice/Data證書、配置、文件存儲需要重新配置自定義證書丟失/var/log/onlyoffice運行日志排查問題沒有歷史日志/var/lib/onlyoffice文檔緩存和部分運行數(shù)據(jù)緩存失效需要重新渲染/var/lib/postgresqlPostgreSQL 數(shù)據(jù)目錄版本歷史、文檔元數(shù)據(jù)全部丟失/var/lib/rabbitmqRabbitMQ 數(shù)據(jù)隊列任務(wù)狀態(tài)丟失/var/lib/redisRedis 持久化數(shù)據(jù)緩存數(shù)據(jù)丟失很多人在意文件本體放哪其實 OnlyOffice 本身一般不存源文件源文件由集成方Moodle、網(wǎng)盤、OA來保管。但如果版本歷史、協(xié)同編輯狀態(tài)、文檔轉(zhuǎn)換緩存這些沒了體驗會大打折扣。特別是 /var/lib/postgresql版本歷史記錄就在數(shù)據(jù)庫里想保留“誰在什么時候改過哪里”這個卷必須掛好。Docker 的命名卷named volume遷移方便適合只通過 docker compose 管理綁定掛載bind mount適合你想直接用 vim 看日志、備份文件。我一般用命名卷然后用 docker run --volumes-from 的方式做備份后面實操部分會寫具體命令。2.5 一份可直接復(fù)制的最小 compose 文件下面這份是我給多數(shù)項目起底的模板去掉了外部數(shù)據(jù)庫和隊列最大程度降低初次部署的復(fù)雜度。services: onlyoffice-documentserver: image: onlyoffice/documentserver:latest container_name: onlyoffice-documentserver restart: unless-stopped ports: - 8080:80 environment: JWT_ENABLED: true JWT_SECRET: replace-with-openssl-rand-hex-32-output JWT_HEADER: Authorization JWT_IN_BODY: true ALLOW_PRIVATE_IP_ADDRESS: true volumes: - ds_data:/var/www/onlyoffice/Data - ds_log:/var/log/onlyoffice - ds_lib:/var/lib/onlyoffice - ds_db:/var/lib/postgresql - ds_rabbitmq:/var/lib/rabbitmq - ds_redis:/var/lib/redis networks: - onlyoffice_net volumes: ds_data: ds_log: ds_lib: ds_db: ds_rabbitmq: ds_redis: networks: onlyoffice_net: driver: bridge你不需要真的把這段全部照抄關(guān)鍵是理解每個字段在干什么。image 決定版本ports 做端口映射environment 傳鑒權(quán)信息volumes 定義持久化networks 讓容器有獨立網(wǎng)絡(luò)。JWT_SECRET 這一項務(wù)必替換成自己的隨機(jī)字符串不要用模板里的占位符否則等于沒設(shè)密碼。注意如果你用的是新版 Docker Compose v2命令是 docker compose中間有空格不是老舊的 docker-compose。配置文件里也不需要寫 version 字段Compose 會根據(jù)文件內(nèi)容自動選擇語法版本。3. 部署實操從下載鏡像到啟動驗證3.1 環(huán)境準(zhǔn)備與 Docker Compose 安裝系統(tǒng)里沒有 Docker 的話先裝基礎(chǔ)運行時。以 Ubuntu/Debian 為例可以直接用系統(tǒng)包管理器安裝 Docker Engine 和 Compose 插件。sudo apt update sudo apt install -y docker.io docker-compose-plugin sudo systemctl enable --now docker docker compose version執(zhí)行完 docker compose version 能看到版本號說明 Compose 插件已經(jīng)就位。如果你之前只裝了 docker 沒裝 compose 插件也可以單獨補(bǔ)裝。CentOS/RHEL 系列則是用 dnf 裝 docker-ce 和 docker-compose-plugin名字略有差異。內(nèi)網(wǎng)離線環(huán)境裝 Docker 是另一個話題這里先給一個最實用的思路在有外網(wǎng)的機(jī)器上把鏡像打成 tar 包再導(dǎo)入內(nèi)網(wǎng)。docker pull onlyoffice/documentserver:latest docker save onlyoffice/documentserver:latest -o onlyoffice-documentserver.tar到了內(nèi)網(wǎng)機(jī)器上執(zhí)行 docker load -i onlyoffice-documentserver.tar鏡像就進(jìn)本地了。此時再跑 docker compose up -dCompose 發(fā)現(xiàn)本地有同名鏡像就不會去遠(yuǎn)程拉取。3.2 啟動服務(wù)與常用管理命令把上面的 docker-compose.yml 保存到某個目錄比如 /opt/onlyoffice然后在這個目錄里執(zhí)行cd /opt/onlyoffice docker compose up -d第一次啟動會先拉鏡像鏡像很大需要耐心等一會兒。拉完鏡像后容器開始內(nèi)部初始化這時候你會看到容器狀態(tài)從 created 變成 starting最后變成 running。內(nèi)部要同時拉起好幾個服務(wù)初始化時間通常在一到兩分鐘不要剛看到容器起來就急著訪問。日常管理最常用的幾條命令一起列出來# 查看容器狀態(tài) docker compose ps # 跟蹤日志排查啟動過程中的報錯 docker compose logs -f onlyoffice-documentserver # 進(jìn)入容器排查 docker exec -it onlyoffice-documentserver bash # 重啟容器 docker compose restart onlyoffice-documentserver # 停止并刪除容器卷不會被刪除 docker compose down注意 docker compose down 默認(rèn)只刪容器和網(wǎng)絡(luò)不會刪命名卷所以數(shù)據(jù)還在。如果你想連卷一起清掉要加 -v 參數(shù)但這句話我必須說在前頭加了 -v 等于把 OnlyOffice 的數(shù)據(jù)庫、日志、緩存全刪了非必要不要碰。3.3 驗證部署健康檢查、首頁與臨時文檔容器起來后別急著開會先做三個層面的驗證。第一層是看進(jìn)程狀態(tài)docker compose ps 里 STATUS 顯示 Up 且沒有 Restarting 字樣基本說明容器沒崩潰。第二層是探測健康檢查接口curl http://localhost:8080/healthcheck如果服務(wù)正常這個接口會返回一段文本常見結(jié)果是 true 或類似狀態(tài)信息。如果返回 404 或者連接拒絕說明容器內(nèi)部服務(wù)還沒就緒或端口映射不對先看日志。第三層是確認(rèn) API 文件能訪問因為 OnlyOffice 的前端編輯器依賴這段腳本curl -I http://localhost:8080/web-apps/apps/api/documents/api.jsHTTP 狀態(tài) 200 就說明 Web 服務(wù)正常。之后可以用瀏覽器打開主機(jī)地址比如 http://你的服務(wù)器IP:8080看到 OnlyOffice 的歡迎頁或編輯器頁面。如果要更仔細(xì)地驗證在線編輯可以準(zhǔn)備一個最簡單的 HTML 頁面把 DocsAPI 編輯器嵌進(jìn)去指向服務(wù)器上的 test.docx這樣能確認(rèn) JWT、回調(diào)、WebSocket 整條鏈路是通的。3.4 常見啟動問題與排查技巧實錄部署過程里翻車最多的不是配置復(fù)雜而是基礎(chǔ)環(huán)境出了問題。我把自己遇到過的幾類典型問題整理成一張速查表現(xiàn)象排查方向解決辦法容器一直 Restarting日志里有 OOM內(nèi)存不夠給機(jī)器加內(nèi)存至少 4GB或檢查是不是同時跑了太多容器訪問 8080 端口 404 / 502容器內(nèi)部還沒完全啟動等 1-2 分鐘再訪問docker compose logs 看啟動進(jìn)度8080 端口被占用宿主機(jī)上已有服務(wù)占端口把映射改成 8081:80或先停掉占用端口的服務(wù)編輯器加載失敗接口報 401JWT 密鑰不一致確認(rèn)集成方配置的 secret 與容器環(huán)境變量 JWT_SECRET 完全一致轉(zhuǎn)換文檔報錯提示無法訪問文件容器無法回調(diào)內(nèi)網(wǎng)地址設(shè)置 ALLOW_PRIVATE_IP_ADDRESStrue并檢查網(wǎng)絡(luò)連通性協(xié)同編輯時對方看不到文檔刷新WebSocket 沒透傳反向代理必須支持 Upgrade 和 Connection 頭排查這些問題有個統(tǒng)一的順序先 docker compose ps 看存活狀態(tài)再 docker compose logs 看最近的錯誤最后 curl 健康檢查接口看服務(wù)是否就緒。大多數(shù)“起不來”的問題到這一步就能定位清楚了。4. 生產(chǎn)環(huán)境進(jìn)階HTTPS、Moodle 集成與轉(zhuǎn)換參數(shù)4.1 讓域名走 HTTPS反向代理與 WebSocket 透傳OnlyOffice 文檔編輯用了 WebSocket 做協(xié)同通信所以反向代理不能只是簡單轉(zhuǎn)發(fā) HTTP必須額外處理 WebSocket 的 Upgrade 握手。很多人配完 Nginx 后打開頁面是好的但一旦兩個人同時編輯文檔狀態(tài)不同步十有八九是代理層把 WebSocket 請求當(dāng)成普通請求轉(zhuǎn)發(fā)導(dǎo)致長連接建立失敗。這里給一份 Nginx 反向代理的關(guān)鍵配置片段location / { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection upgrade; client_max_body_size 100m; }注意 proxy_set_header Connection 一定要是 upgrade而且這一行不能與普通的 keepalive 邏輯混掉。X-Forwarded-Proto 也很重要它告訴 OnlyOffice 用戶當(dāng)前通過 HTTPS 訪問這樣內(nèi)部生成的回調(diào)地址、下載鏈接才不會錯誤地使用 http。如果你用 Caddy配置會簡單不少它默認(rèn)就會處理 WebSocket 和 HTTPS 證書申請。但生產(chǎn)系統(tǒng)里 Nginx 依然是主流掌握上面的寫法比背工具更重要。4.2 和 Moodle 集成裝插件與密鑰對齊Moodle 接入 OnlyOffice 的官方路徑是安裝由 OnlyOffice 提供的 Moodle 插件。插件可以在 Moodle 后臺直接上傳 Zip 安裝站點管理 - 插件 - 安裝插件然后上傳下載到的插件壓縮包按提示啟用。裝完插件后進(jìn)入插件的配置頁面需要填兩個最核心的信息文檔服務(wù)器地址和 JWT 密鑰。文檔服務(wù)器地址要填完整比如 https://doc.example.com/結(jié)尾斜杠別漏JWT 密鑰必須和 docker-compose.yml 里的 JWT_SECRET 一模一樣。這兩處對不上你在 Moodle 里打開附件時會一直轉(zhuǎn)圈或者直接報錯。比較隱蔽的一個問題是Moodle 所在的服務(wù)器必須能訪問到 OnlyOffice 容器最好在同一網(wǎng)絡(luò)或者通過防火墻放行。如果 Moodle 和 OnlyOffice 都在 Docker 里推薦讓兩個容器加入同一個外部網(wǎng)絡(luò)這樣 Moodle 可以用容器名解析 OnlyOffice。提示集成完以后先上傳一個小文件試一下“在線編輯”和“保存回傳”。OnlyOffice 編輯完會回調(diào) Moodle 保存文件如果回調(diào)地址被安全策略攔截版本歷史和編輯保存都會失效。4.3 轉(zhuǎn)換請求里的 assemblyformatasorigintrue 到底是干嘛的如果你對接過 OnlyOffice 的轉(zhuǎn)換接口大概率見過某個 URL 參數(shù)叫 assemblyformatasorigintrue。這個參數(shù)不常出現(xiàn)在文檔里但真遇到格式錯亂的問題時它往往是關(guān)鍵。我個人的理解和使用經(jīng)驗是它告訴 OnlyOffice請以文件的原始裝配格式作為轉(zhuǎn)換基準(zhǔn)不要只憑 URL 后綴或者外部傳入的 filetype 做判斷。舉個例子有些系統(tǒng)導(dǎo)出的文件后綴是 .doc但內(nèi)部實際是 docx 的 Open XML 結(jié)構(gòu)不帶這個參數(shù)時轉(zhuǎn)換服務(wù)可能按老二進(jìn)制格式去解析結(jié)果導(dǎo)出 PDF 后排版錯亂、中文亂碼。加上 assemblyformatasorigintrue服務(wù)端會先嘗試識別文件真實的內(nèi)部格式再決定轉(zhuǎn)換路徑。在實際對接時你可能不是在頁面上直接改這個參數(shù)而是在集成代碼的轉(zhuǎn)換請求 URL 里把它拼接進(jìn)去。比如https://doc.example.com/ConvertService.ashx?url...#outputtypepdfassemblyformatasorigintrue如果你當(dāng)前沒有遇到轉(zhuǎn)換異常不需要刻意加。但把這條經(jīng)驗記在腦子里等將來有人反饋“某個 doc 轉(zhuǎn)出來是亂的”排查方向就會清晰很多。4.4 協(xié)同編輯與版本歷史開啟要做什么OnlyOffice 的協(xié)同編輯本身不需要額外配置容器起來就能用但要讓多人編輯實時同步整個鏈路必須滿足三個條件。第一瀏覽器能通過 WebSocket 連接到文檔服務(wù)所以反向代理要處理好 Upgrade第二所有客戶端和回調(diào)請求使用同一個 JWT 密鑰簽名不一致的請求會被拒絕第三文檔的保存回調(diào)要能回到集成方否則只在 OnlyOffice 內(nèi)部改了業(yè)務(wù)系統(tǒng)里的源文件不會更新。版本歷史在 OnlyOffice 編輯器界面的“版本歷史”入口能看到每次保存會生成一個新版本。和“代碼查看歷史修改記錄”一樣你可以比較當(dāng)前版本和之前版本的差異。這個功能依賴于 PostgreSQL 卷因為版本元數(shù)據(jù)存在數(shù)據(jù)庫里。如果你發(fā)現(xiàn)版本歷史里只有一條記錄或者改動記錄無故消失先檢查兩件事數(shù)據(jù)庫卷有沒有正常掛載以及保存回調(diào)有沒有失敗。很多容器重建后用了一個新的匿名卷歷史數(shù)據(jù)就“丟”了其實舊數(shù)據(jù)還在原來的卷里只是沒掛回來。5. 避坑指南與實用建議5.1 鏡像拉取慢或拉不下來怎么辦OnlyOffice 鏡像體積大拉取慢是個很實際的問題。最穩(wěn)的辦法是給 Docker daemon 配置 registry mirror也就是鏡像加速器。修改 /etc/docker/daemon.json加入 registry-mirrors 配置項然后重啟 Docker。{ registry-mirrors: [https://你的鏡像加速地址] }配置完記得 docker info 查看 Registry Mirrors 是否生效。如果你使用的加速地址不可用就換一個或者干脆走離線導(dǎo)入路線。還有一個小技巧不要在高峰期反復(fù)拉同一個鏡像第一次拉失敗產(chǎn)生的殘層會占用磁盤空間定期 docker system prune 清一下避免磁盤被占滿。5.2 備份與升級策略只要容器正常掛著卷備份并不復(fù)雜。最簡單的方式是用一個臨時容器掛載 OnlyOffice 容器的所有卷打包整個數(shù)據(jù)目錄。docker run --rm --volumes-from onlyoffice-documentserver \ -v $(pwd):/backup alpine \ tar czf /backup/onlyoffice-backup.tar.gz \ /var/www/onlyoffice/Data /var/lib/postgresql /var/lib/redis \ /var/lib/rabbitmq /var/lib/onlyoffice /var/log/onlyoffice這個命令會把關(guān)鍵數(shù)據(jù)全部打包到當(dāng)前目錄的 onlyoffice-backup.tar.gz?；謴?fù)的時候先把新容器停掉再用同樣的方式把 tar 解包回對應(yīng)目錄即可。備份頻率取決于你們的業(yè)務(wù)量我的建議是每次升級前必須備份日常每天或每周定時跑一次。升級 OnlyOffice 時不要直接 docker compose pull 然后 up -d 就完事。先看官方發(fā)布說明確認(rèn)新版本是否包含數(shù)據(jù)庫遷移或配置變更再按“備份 - 修改 yaml 里的鏡像 tag - docker compose pull - docker compose up -d”的順序操作。升級失敗就快速把 tag 回滾到舊版本重新 up -d所以固定 tag 的好處在這時候體現(xiàn)得淋漓盡致。5.3 我給新手的幾個操作建議不要一上來就用 latest 跑生產(chǎn)也不要一開始就拆外部數(shù)據(jù)庫更不要圖省事把 JWT 關(guān)掉。關(guān)掉 JWT 會讓整個服務(wù)處于裸奔狀態(tài)任何人只要能訪問到端口就可以調(diào)用轉(zhuǎn)換接口、偽造回調(diào)這個風(fēng)險完全不值得冒。部署時建議把敏感配置抽到 .env 文件里在 docker-compose.yml 里用 ${JWT_SECRET} 引用。這樣 yml 本身可以提交到 Git真正的密鑰留在服務(wù)器本地。我第一次部署就是直接把密鑰寫死在 yml 里結(jié)果同事把倉庫同步到自己的開發(fā)機(jī)密鑰也一起帶走了后來只能重新生成并同步所有集成方教訓(xùn)很深。最后再分享一個小習(xí)慣每次改動 compose 文件或者升級鏡像之前先看一眼當(dāng)前容器是否能正常出健康檢查再備份數(shù)據(jù)?？雌饋硎峭赁k法但我在實際項目里靠這個習(xí)慣避免了至少兩次“升級一時爽回滾火葬場”的場面。Docker Compose 給了我們一鍵部署的能力但真正讓服務(wù)穩(wěn)定跑下去的永遠(yuǎn)是那些不起眼的備份和驗證動作。