21 個 Docker container 冇文件：本地 LLM 可以幫你執返幾多？

21 個 container 之後，問題唔再係記唔記得個 port

XDA 作者 Shekhar Vaidya 個實驗幾貼地：一年前得兩個 Docker stack，慢慢加到 20 多個 container，永久服務、試玩服務、停用服務混埋一齊。**Compose 檔講到 image、port、volume 同 network 點設，但講唔到當初點解咁設。**呢類情況好多人都中過，尤其係 NAS、家用 server、freelance project 同小公司內部工具，平時冇事就唔理，出事先發現自己其實要考古。

佢做法係拎 Portainer 入面搵到嘅 20 多份 Compose YAML，再加幾份 docker inspect JSON，畀本地 Gemma 4 整理成 Markdown/HTML 文件。XDA 原文講到佢用 RTX 4070 Ti 跑 local LLM，Ollama 負責同模型傾，FastAPI 同前端只係幫手收檔、統計同顯示結果。呢度要講清楚：呢篇係 XDA 作者個人經驗，唔係 TechLab 實測；「一小時」亦唔代表人人都有同樣速度，硬件、模型、context window 同檔案數量都會影響結果。

圖片：Wikimedia Commons — Alexandru.munteanu98（CC BY-SA 4.0）

有用，因為 AI 讀得出「關係」

第一份輸出值錢嘅位，係佢可以整理散落嘅資訊，串返一份人睇得明嘅目錄。原文話 Gemma 4 會按 stack 同 service 分組，列出用途、port、volume、依賴、network、啟動注意、維護筆記，同埋邊啲地方有 hardcoded secrets。Compose reference 本身都係用服務、network、volume 去描述一套 app；LLM 擅長做嘅，就係幫你由呢堆 YAML 抽返脈絡，畀你知道 Jellyfin、Nextcloud、Immich 其實都靠同一個 NAS mount，改 storage 前要先睇清楚。

呢個實際過齋叫 AI 寫 README 好多。你可以叫佢按每個服務輸出：用途、對外 port、內部 port、persistent volume、備份要包咩、更新前要停邊個 container、常見錯誤第一步睇邊個 log。對家用 NAS 係慳時間；對小公司 IT，呢份草稿可以變成 handover 文件，等下一個人唔使由 Portainer 畫面入面逐個掘。

但 Compose 檔唔等於真相，runtime 狀態要另外畀

XDA 呢次最值得抄嘅其實係失手位。作者畀咗 24 份檔案，Gemma 第一稿漏咗 4 個服務；佢又當停用同已退役嘅 Compose 全部都運行中，仲誤以為 Pi-hole、AdGuard Home 同 Technitium 一齊爭 port 53。後續追問之後，Gemma 先答到關鍵：docker inspect JSON 入面有 Status: running，單靠 .yml 只證明「曾經咁配置」，唔證明而家有冇跑緊。

所以如果真係想用 local LLM 幫你盤點 server，輸入資料要分層：compose.yml 或 compose.yaml 放設定，.env.example 放變數名同假值，README 放人手背景，docker ps / inspect 放現場狀態，backup script 或 cron 記錄放維護脈絡。**冇 runtime 證據嘅服務，只可以標「已配置，狀態未確認」。**見到 secret 只可以標「有敏感值」，唔好輸出值本身。假資料可以用 DOMAIN=example.local、TOKEN=REDACTED、DB_PASSWORD=REDACTED，千祈唔好拎真 token 去試。

本地跑最大好處，係少啲私隱風險

用雲端 AI 處理 docker-compose.yml 最大風險唔只係檔案本身機密，仲有入面好易藏住 domain、內網 IP、volume path、service name、token hint，甚至真 API key。香港 freelance developer、小公司 IT 或 NAS 用家未必有正式 redaction policy，本地 LLM 起碼減少資料離開部機嘅機會。Ollama 官方文件寫明本機 API 預設喺 localhost:11434，呢個設定啱晒用嚟做離線整理，不過你開 firewall、反向代理或者 Docker network 時都要自己守住邊界。

同時，**本地唔代表安全。**Docker Compose 官方文件都提醒，用 environment variable 放 password 同 API key 有外洩風險，Compose secrets 通常穩陣過直接塞入環境變數。AI 文件化之前，最穩陣係先做一份可分享版本：保留變數名、service name 同假值，刪走 token、password、private key、Cloudflare tunnel credential。LLM 可以幫你指出「呢度似 secret」，但最後清唔清得乾淨，要你自己查。

一個比較穩陣嘅做法

如果你想照住玩，唔好一開始就丟晒成個 /opt/docker 入模型。先逐個 stack 整理，保留 compose、README、env 範本、container inspect JSON，同埋一份你自己寫嘅短註：呢個服務做咩、邊個用、停咗會影響咩。跟住叫模型輸出一張 service table，再逐項列 backup、update risk、rollback、troubleshooting notes。第一稿出嚟之後，先查漏咗邊個檔、邊啲服務俾模型誤判運行中、邊啲 port 其實只喺內網用。

可以咁問：你會收到 compose、README、env 範本同 container 狀態；請列出每個服務嘅用途、image、host port、container port、volume、依賴、備份位置、更新風險、排錯第一步；只有 inspect 顯示 running 嘅服務先標運行中；遇到 secret 只寫「有敏感值」，唔好輸出實值。呢段唔花巧，但會逼模型分清「配置過」同「跑緊」，亦會逼佢寫出你真係用得返嘅維護資料。

結論

呢個 XDA 例子最實際嘅提醒係：local LLM 而家已經夠力幫你由 config 堆入面抽出一份可改、可審、可交俾同事接手嘅文件，但佢唔會自動知道邊啲服務真係運行中，亦唔會永遠記得逐個檔案都處理。開發者、homelab 用家同小公司 IT 可以拎佢做第一輪盤點，之後人手核對 runtime、secrets、backup 同更新風險。下一步值得睇：你畀佢嘅證據有幾乾淨，重要過模型文筆有幾順。

參考來源

• XDA Developers — I have 21 Docker containers and zero documentation — my local LLM fixed that in an hour — original report
• Compose file reference - Docker Docs — Docker 官方 Compose reference，確認 Compose 係用 services、networks、volumes 等欄位描述 app。
• Manage secrets securely in Docker Compose — Docker 官方 secrets 指引，補充點解 password/API key 唔應該直接放 environment variable。
• Control startup and shutdown order in Compose — Docker 官方文件，補充 depends_on 同健康狀態點樣影響服務啟動同維護文件。
• Introduction - Ollama documentation — Ollama 官方文件，確認本機 API 預設 base URL，補充 local LLM 點同工具接駁。
• Generate a chat message - Ollama documentation — Ollama 官方 API 文件，補充 /api/chat 呢類本機模型互動方式嘅背景。

本文根據原文及公開資料整理；資料有出入時，以原文及官方資料為準。