COMPOSE_PROJECT_NAME · 獨立資料卷與連接埠表 · env_file 與容器內 env 對齊核對
在同一台VPS上並行跑兩套OpenClaw時，最常見事故是連接埠佔用、預設網路與卷名撞車，以及宿主有 API Key 但容器內 env 為空。本文以單實例基線 vs 多實例最小差異集對照表梳理 COMPOSE_PROJECT_NAME、資料目錄與連接埠表，說明 env_file 與 environment 的注入路徑，並給出六步核對清單與回滾單實例條件。可與Docker Compose 生產基線、Exit 137 與起步排障交叉閱讀。
複製一份 docker-compose.yml 改幾個連接埠並不等於隔離：預設工程名會讓網路與匿名卷繼續撞名；宿主 export 不會自動進容器；反代 upstream 仍可能指向舊容器 IP。下列訊號出現時，應回到對照表逐項打勾而不是繼續加容器。
只改連接埠不改 COMPOSE_PROJECT_NAME：預設 bridge 網路與內部 DNS 仍可能解析到另一棧的容器名。
資料目錄軟連結或掛載重疊：兩套 ~/.openclaw 或 workspace 實際落在同一塊磁碟前綴，升級指令碼互相改寫。
API Key 只在 shell profile：docker compose up 子行程讀不到 compose 期望的 env_file 路徑。
健康檢查過短：第二實例冷啟動更慢，被 orchestrator 誤判重啟並與第一實例搶鎖。
反代仍指向 127.0.0.1 舊連接埠：兩套 Gateway 輪換時，邊緣層仍把流量打到已停止的實例。對齊方式見反代與 TLS 長文。
下列欄位是同一宿主機雙棧最常見的「最小差異集」。若你只準備開短期試驗實例，至少完成工程名、資料目錄、宿主機連接埠、env_file 路徑四件事再談自動化。資源上限與日誌輪替仍須遵守生產基線長文。
| 欄位 | 單實例基線 | 多實例必須拆分 | 常見踩坑 |
|---|---|---|---|
COMPOSE_PROJECT_NAME | 預設目錄名 | 每棧唯一短名（如 oc_a / oc_b） | 只改資料夾不改工程名導致匿名卷複用 |
| 資料卷路徑 | 單宿主綁定路徑 | /srv/openclaw-a 與 /srv/openclaw-b 完全分離 | 子路徑軟連結指向同一上層目錄 |
| 宿主機連接埠 | 單組 3000:3000 | 對應到不同宿主連接埠並寫入連接埠表文件 | 第二棧啟動失敗仍被 systemd 拉起抖動 |
| 環境注入 | 單一 .env | 每棧 .env.oc-a 並在 compose 明確 env_file | 宿主 export 未寫入 compose 解析範圍 |
| 健康檢查 | 單份 start_period | 冷啟動更慢時上調 start_period 與 retries | 雙棧同時重啟造成 CPU 尖峰 |
工程名與資料目錄先於連接埠宣傳；順序反了會在第一次升級指令碼時把兩套狀態寫進同一前綴。
以下步驟假設你已能單機跑通官方或團隊的 Compose 片段；目標是讓第二棧的設定渲染結果與執行時 env可對照稽核。
寫入工程名與目錄：匯出 COMPOSE_PROJECT_NAME，建立獨立資料目錄並確認無巢狀軟連結。
固定連接埠表：為 Gateway、Control UI、附加通道連接埠分配未佔用宿主連接埠，寫入維運表。
拆分 env_file：每棧一份金鑰檔路徑，避免共用 .env；以 docker compose --project-directory 明確工作目錄。
渲染檢查：執行 docker compose -f ... config 比對兩棧的 networks、volumes 與 ports 是否仍出現同名掛載。
執行時驗證：docker compose exec 進入容器列印目標變數，確認與宿主 grep -v 脫敏結果一致。
健康與日誌：依基線長文設定 start_period 與 json-file 上限，避免雙棧同時打滿磁碟。
export COMPOSE_PROJECT_NAME=oc_b docker compose --env-file ./.env.oc-b -f docker-compose.yml config > /tmp/oc-b.rendered.yml docker compose --env-file ./.env.oc-b -f docker-compose.yml up -d docker compose --env-file ./.env.oc-b exec -T openclaw-gateway sh -lc 'env | grep -E "ANTHROPIC|OPENAI" | sed "s/=.*/=***MASK***/"'
提示：config 子命令只解析合成結果，不啟動容器；先儲存渲染 diff 再 up，便於與第一棧對照。
下列條目為值班與覆盤起點，請以你們真實 compose 片段與宿主監控替換具體門檻；不得直接宣稱為對外 SLA。出現「偶發連錯實例」時，至少同時儲存兩棧的渲染設定、容器 inspect 網路段與反代 upstream 快照。
ss -lntp 或等價命令，輸出儲存到工單附件。json-file 寫入時，inode 與頻寬先於 CPU 成為瓶頸；見基線長文中的巡檢節奏。| 症狀 | 優先懷疑欄位 | 建議命令或證據 |
|---|---|---|
| 容器內無 API Key | env_file 路徑、compose 工作目錄 | docker compose config 與 exec env 對照 |
| 健康檢查抖動重啟 | start_period、CPU steal | 宿主 dmesg / cgroup 統計與容器日誌時間線 |
| 請求打到錯誤實例 | 反代 upstream、舊容器殘留 | 反代 reload 前後 docker ps -a 與 upstream 檔案 diff |
注意：在未停止第一棧前以同一路徑覆蓋 .env，會把兩棧金鑰輪換順序打亂；永遠先複製新檔再切換引用。
在同一台小記憶體 VPS 上硬塞兩套生產級 OpenClaw，往往先輸在磁碟與日誌而不是算力；若缺少獨立資料目錄與連接埠表，排障會退化成「猜連到哪一個 Gateway」。純手動改 compose 而不保留渲染 diff，也會讓後續升級無法回答「是誰改了哪條環境變數」。
相較之下，需要穩定宿主機、可預期頻寬與可隔離工作目錄的團隊，把 OpenClaw 跑在可訂購的雲 Mac 或專用 VPS 套餐上更利於執行上述清單；對要把多實例試驗與生產隔離放在同一維運故事裡的情境，VpsMesh 的 Mac mini 雲端租賃通常是更優解：節點角色可拆分、鏈路可稽核，讓 compose 差異集與佇列策略同樣可驗收。
請依正文對照表核對匿名卷、預設網路名、宿主連接埠與 env_file是否仍與第一棧重疊；僅改目錄名不改工程名時最常見。更多 healthcheck 與 restart 細節見Compose 生產基線長文。
多半是 compose 未載入正確的 env_file、工作目錄不一致，或變數只在 build 段宣告；依正文六步以 docker compose config 與 exec 對齊。起步階段可對照Exit 137 與起步排障長文的環境變數段落。