OpenShip v0.4.7 伺服器遷移：2026 驗收清單

目標容器已經啟動，但資料庫、資料卷或後台任務還沒有通過驗收。 最快解法是先保留舊節點，按「容器與映像檔 → 資料與恢復 → 密鑰與權限 → 域名與長連線 → 任務與回滾」逐項留證，全部通過後才切流。

這篇適合三類人：正在遷移現有 Docker 應用、需要確認服務可重新部署的開發者；更換生產伺服器、必須控制資料與憑證切換風險的運維人員；以及準備採購持續在線節點、需要訂出明確驗收口徑的技術負責人。

最後更新於 2026 年 8 月 3 日；版本日期與產品能力描述核對自 OpenShip 官方版本發布頁、官方 Changelog、官方工作流程說明 與 官方 README。實際是否可切流，仍須以你的環境測試結果為準。

先定義「遷移完成」的驗收門檻

OpenShip v0.4.7 的官方版本紀錄顯示，該版本於 2026 年 7 月 28 日發布；任務邊界所核對的 Changelog 包含遠端 Docker 遷移可靠性改進。這代表遷移鏈路有所改善，但不代表你的生產服務已經驗收通過。官方網站所描述的容器接管、資料卷、憑證與回滾，屬於產品能力聲明，不能直接替代你在新節點上的實際證據。(github.com)

你至少要保留以下證據：

• 遷移前後的 OpenShip 版本、來源伺服器與目標伺服器。
• 來源端實際容器清單、映像檔摘要、環境變數版本與設定檔位置。
• 目標端容器狀態、重新部署記錄、資料卷掛載結果與資料庫抽樣結果。
• DNS、TLS 憑證、WebSocket、健康檢查與代理標頭的測試結果。
• 舊節點仍可啟動、資料邊界清楚，而且至少完成一次回退演練的記錄。

兩種驗收狀態

如果你只看到「部署成功」或容器正在執行，最多只能判定技術遷移完成，不能判定業務可用。

版本與服務範圍

1. 固定來源、目標與版本

先在來源節點與目標節點各保存一份資訊：

openship --version
docker version
docker compose version
hostname
date -Is

若你的安裝方式不是直接使用這些指令，請改用對應的 OpenShip CLI 或控制台版本資訊，但不要只截取瀏覽器畫面。畫面可能是快取，真正的驗收應以伺服器端輸出、部署日誌或可下載的操作記錄為準。

同時記錄：

• 來源伺服器主機名稱、區域與管理入口。
• 目標伺服器主機名稱、SSH 帳戶與防火牆規則。
• OpenShip 版本、專案識別資料與目前部署版本。
• 目前使用的 Docker Compose 定義、openship.json、反向代理設定與排程設定。
• 目前的回退方式：重新指向舊節點、還原舊容器，或恢復舊版映像檔。

官方說明指出，OpenShip 可透過 SSH 將映像檔傳送至目標伺服器，並以新的容器啟動服務；因此你必須把「平台知道的專案」與「伺服器上實際存在的容器」分開核對。(openship.io)

2. 對照完整服務清單

不要只檢查目前有流量的 Web 容器。將儲存庫中的 Compose 定義、環境設定與來源節點的實際容器清單交叉比對：

docker ps -a --format 'table {{.Names}}\t{{.Image}}\t{{.Status}}\t{{.Ports}}'
docker volume ls
docker network ls

特別留意三種容易被漏掉的服務：

1. 沒有公開連接埠、但負責佇列或排程的工作容器。
2. 目前沒有執行、但切流後必須由 OpenShip 重新建立的相依服務。
3. 使用獨立資料卷、物件儲存或外部資料庫的服務。

OpenShip 遷移 Docker 伺服器會不會丟資料？ 工具完成容器接管，不等於資料已完整複製。資料遺失風險通常來自未列入計畫的資料卷、最後寫入沒有同步、資料庫只搬了容器而沒有搬資料，或新節點實際掛載到空白路徑。只有在資料卷數量、掛載路徑、資料庫抽樣和隔離恢復都通過後，才可以把「沒有丟資料」寫進驗收結論。

容器與重新部署指標

3. 檢查真實狀態而不是控制台快取

在目標節點逐一確認：

docker ps
docker inspect <container_name>
docker image ls
docker logs --since 10m <container_name>

通過標準應包括：

• 每個計畫內服務都有對應容器，容器名稱與服務映射沒有錯位。
• 容器的健康狀態、啟動命令、環境變數來源與掛載路徑符合來源端。
• 映像檔不是意外拉取的 latest，而是你在遷移記錄中指定的版本或摘要。
• 公開連接埠只出現在原本需要對外提供服務的容器。
• 日誌沒有反覆重啟、資料庫連線失敗、密鑰缺失或權限拒絕。

OpenShip 官方工作流程強調，建置產生的是不可變、具版本的映像檔，再傳送到目標伺服器；這對驗收的實際意義是：不要用「容器有跑」取代「容器跑的是正確映像檔」。(openship.io)

4. 做一次受控重新部署

不要在正式切流後才第一次測試重建。先選擇一個可控的服務，執行重新部署並保存：

• 部署開始與完成時間。
• 使用的分支、提交識別值或映像檔摘要。
• build 類型服務是否能重新建置。
• image 類型服務是否能重新拉取。
• 部署後是否出現重複容器、錯誤服務名稱或錯誤連接埠映射。
• 重啟後資料卷是否仍掛載到正確路徑。

遷移後舊容器顯示停止，但服務仍然正常，應如何處理？ 先不要立即刪除舊容器。服務可能已經切到目標節點，舊容器停止只是預期結果；也可能是 DNS 尚未完全切換、代理仍指向舊節點，或外部負載平衡器仍保留舊後端。你應從實際請求來源、代理日誌、DNS 解析結果與兩端容器日誌確認流量位置，再決定是否清理舊環境。

若新舊節點同時顯示可用，先暫停清理，因為這可能代表切流沒有完成，也可能造成排程或佇列任務重複執行。

資料庫與資料卷驗證

5. 先核對數量，再做業務抽樣

資料卷驗收不能只看 Docker 是否列出名稱。請把來源與目標的以下項目逐一對照：

執行最少三類測試：

1. 寫入測試：建立一筆可識別的測試資料，記下識別值與時間。
2. 讀取測試：從新節點讀回該資料，確認應用程式不是只回傳快取內容。
3. 重啟測試：重啟應用程式與相依服務，再次讀取測試資料。

資料庫和資料卷遷移完成後如何驗證？ 不要以檔案數量或備份任務顯示成功作為唯一依據。你需要確認資料庫可以實際查詢、資料卷可由應用程式讀寫、重啟後資料仍存在，並在隔離環境完成一次備份恢復。備份成功只是「備份檔已產生」，恢復成功才是「備份可以用」。

如果資料庫正在持續寫入，先協調寫入停機窗口，或明確記錄最後同步時間與切流後新增資料的處理方式。沒有這個邊界，回滾時很容易出現新舊節點各自擁有一部分資料的情況。

密鑰、權限與外部連線

6. 核對環境變數與最小權限

將來源與目標的環境變數分成三組，不要把所有內容直接複製：

• 執行必要：資料庫連線、物件儲存、郵件、第三方 API。
• 部署必要：映像檔倉庫、Git 憑據、SSH 金鑰。
• 管理專用：根帳戶、備份恢復權限、伺服器管理金鑰。

通過標準是：

• 應用程式能連到必要的外部服務。
• 部署帳戶只能完成所需的部署與恢復測試。
• 管理端口沒有因遷移而綁定到公開介面。
• 測試完成後，臨時金鑰、測試 Token 與一次性帳戶已撤銷。
• 新節點的環境變數沒有誤用測試環境或舊節點專用憑據。

官方資料提到，OpenShip 的密鑰可按環境管理，且服務之間可在隔離網路中通訊；驗收時仍要從你的防火牆、SSH 與實際應用連線結果確認，不能只把介面上的設定狀態當成安全證據。(openship.io)

7. 域名、憑證與 WebSocket

切流前先使用測試域名、暫時本地解析或受控的 hosts 設定，驗證：

curl -I https://test.example.com
curl -i -N \
  -H "Connection: Upgrade" \
  -H "Upgrade: websocket" \
  https://test.example.com/socket

驗收要點包括：

• HTTP 是否正確導向 HTTPS。
• TLS 憑證的域名、到期資訊與完整鏈是否正確。
• 自動續期所需的 DNS、連接埠與檔案權限條件是否仍存在。
• 反向代理是否傳遞正確的 Host、X-Forwarded-Proto 與用戶端 IP 標頭。
• WebSocket 或其他長連線在代理後是否能建立、維持並正常關閉。
• 健康檢查是否檢查真正的應用程式狀態，而不是只確認連接埠有回應。

OpenShip 換伺服器時域名和憑證怎麼切換？ 先在目標節點完成憑證簽發前提與測試域名驗證，再安排 DNS 切換。記錄 DNS 修改時間、預計保留舊節點的時間邊界，以及誰有權限撤回變更。OpenShip 官方網站描述了自動 TLS、域名路由與切換能力，但是否能在你的 DNS、代理與憑證環境中正常運作，仍須由實際 HTTPS 和長連線測試確認。(openship.io)

後台任務、切流與回退

8. 避免新舊節點重複執行

AI SaaS 常見的風險不是首頁打不開，而是後台任務悄悄執行兩次。切流前列出：

• Cron 或排程任務。
• 佇列消費者與重試工作。
• 郵件、Webhook、付款或通知處理器。
• 影像處理、索引建立與資料同步程式。
• 監控告警與健康檢查。

切流期間應採取其中一種明確策略：

• 暫停舊節點的排程與消費者，讓目標節點接管。
• 保留舊節點服務請求，但只讓其中一端執行寫入型任務。
• 透過任務鎖、租約或唯一識別機制，避免兩端同時消費。

切流後測試一條完整使用者路徑，例如登入、建立資料、觸發任務、等待任務完成，再檢查日誌、佇列、資料庫與告警是否一致。只測首頁或健康檢查，無法證明 AI SaaS 的非同步流程正常。

9. 回滾證據與關閉舊節點條件

OpenShip 伺服器遷移失敗，還能切回舊節點嗎？ 能否切回，不是看控制台是否有「Rollback」按鈕，而是看舊節點是否仍可啟動、域名是否能重新指向、資料寫入邊界是否清楚，以及新節點產生的資料如何處理。OpenShip 官方說明保留先前版本並提供回滾能力；對伺服器更換而言，你仍須另外驗證節點級回退，而不是只驗證版本級回退。(openship.io)

在關閉來源伺服器前，至少完成：

• 從目標節點切回舊節點的演練。
• 確認舊節點能重新啟動容器與相依服務。
• 記錄切流後新增資料的時間範圍。
• 確認佇列、排程與 Webhook 不會在回退時重複處理。
• 確認 DNS、憑證與反向代理仍能服務舊節點。
• 保存回退操作者、時間、命令、結果與監控截圖。

10. 最終切流判斷表

你可以把這張表附在變更申請或維運紀錄中；任何一列沒有證據，就把狀態標為「待驗收」，而不是用「看起來正常」代替。

目前伺服器與臨時獨立節點的取捨

如果你直接在目前伺服器上覆蓋部署，優點是不用重新安排節點與連線，但缺點也很明確：舊環境無法並行保留、回滾時資料邊界較難判定，且新的容器、代理設定與舊服務可能互相搶占連接埠。對正在遷移生產 AI SaaS 的團隊而言，這些風險往往比單純的部署時間更值得計算。

若你需要雙軌驗證，臨時獨立節點可以讓來源環境維持服務，目標環境則完成 Docker 遷移、資料恢復、憑證測試與切流演練。這種方案會增加短期租賃成本，也需要你自行安排資料同步與權限管理；但它換來的是更清楚的回退入口，以及在發現資料卷或後台任務問題時不必立即破壞舊環境。

如果目前伺服器沒有足夠容量保留舊節點，或你無法在同一台機器上隔離測試，建議先評估 kvmboot 的獨立伺服器方案，把它作為暫時驗收節點，而不是直接把未驗證的環境推上正式流量。需要確認交付方式、權限配置或遷移限制時，可先查看 kvmboot 幫助中心；若你的資料同步方式較特殊，再透過 kvmboot 聯絡頁面確認可行的操作邊界。

最後的判斷很簡單：OpenShip v0.4.7 伺服器遷移只有在新節點能重新部署、資料能讀寫與恢復、域名憑證能正常服務、後台任務不重複，而且舊節點確實能回退時，才算達到切流條件。若你只是看到目標容器正在執行，請先停在驗收階段，不要急著關閉來源伺服器。