工程師交接

1. 批量網頁容器

coolify 方案說明：

Coolify 是什麼：

開源的容器部署和應用管理平台，類似 Heroku、Vercel
功能：自動化部署、容器管理、多應用支持、環境變數管理、監控日誌、自動備份、SSL/TLS 證書管理
應用場景：自建 PaaS，小型團隊部署多個項目，在自己服務器上管理應用

Coolify 核心架構：

coolify 主服務：Web UI 管理後台，連接到 PostgreSQL 和 Redis
coolify-proxy：Traefik 反向代理，處理容器路由轉發
coolify-db：PostgreSQL 數據庫存儲配置
coolify-redis：Redis 緩存服務
雙網絡：coolify-infra 內部通信，webproxy 跨 Stack 路由

部署選項：

直接掛載 Socket 模式（當前配置）
- 優點：簡單穩定，性能最好
- 缺點：安全風險高，給予容器完整 Docker 權限
DinD (Docker-in-Docker) 模式
- 原理：Coolify 內部運行自己的 Docker daemon
- 問題：性能開銷大、存儲驅動衝突、Cgroups 限制無效、鏡像存儲浪費、網路配置複雜、穩定性差
- 適用：輕量級用途（如 CI/CD），不適合生產環境
Agent 模式（推薦）
- 架構：中央 Coolify 服務器 → 遠程機器上的 Coolify Agent → 該機器的 Docker
- 優點：解決權限問題、分布式部署、隔離性好、避免 DinD 問題、穩定性高
- 缺點：需要額外機器、Agent 與 Coolify 需要網絡連通
- 適用場景：有多台服務器、無法給容器開放 socket、生產環境

目前問題：

核心問題：環境安全策略不允許開放 /var/run/docker.sock 權限

Coolify 需要此權限來創建和管理容器、拉取鏡像、控制容器生命週期、查看日誌和狀態
當前三種方案都無法在同一台主機實施：
- 直接掛載 socket：權限不開放 ❌
- DinD 模式：Agent 容器仍需要 socket，問題未解決 ❌
- 單機 Agent：Agent 容器仍需要 socket，權限問題依然存在 ❌

解決方案：

建議方案：在另一台機器上部署 Coolify Agent，避免在受限主機上運行需要 socket 的容器
需要確認是否有空閒機器或可開啟虛擬機

2. 單一多應用管理容器架構 (Multi-App Container 方案)

既然需求是「由一個容器統一管理眾多網頁」，但「不需要去生出新的子容器」，且「必須支援動態網頁並隔離資料夾」，這相當於把 「虛擬主機 (Shared Hosting)」 的概念封裝進單一個 Docker 容器裡。不用掛載 docker.sock，所有隔離都透過容器內的 Linux 作業系統層級來達成：

方案一：新一代多語言伺服器 NGINX Unit 容器化 (最推薦、最現代的解法)

運作原理： 部署一個官方的 NGINX Unit Docker 容器。只掛載一個根目錄 (例如 /var/www/apps)，裡面再分 app1/, app2/。透過 REST API 告訴 NGINX Unit 新增站點，它會在容器內原生地啟動獨立的隔離行程。 如何滿足條件與優點：

免生子容器：它不是 Docker，而是一個能直接執行 PHP, Python, Node.js, Go 的萬能 App 伺服器，全在一個容器內搞定。
動態語言支援：完美支援動態網頁。
嚴格隔離：透過設定檔，你可以讓 app1 由容器內的 user1 執行、app2 由 user2 執行，彼此完全看不到對方的資料夾，連記憶體行程也徹底分開。

方案二：全能 Web 面板容器 (PaaS in a Box，如 aaPanel / CyberPanel 容器版)

運作原理： 找一個將知名 Web 面板（例如 aaPanel 寶塔面板國際版、或 CyberPanel）打包好的單一 Docker 容器。進入該容器的 Web 介面後，你就像在使用早期的 cPanel 虛擬主機一樣。 如何滿足條件與優點：

自帶管理介面：跟 Coolify 一樣有好看的按鈕可以按，但它是用「新增網站、安裝 Node.js 環境」的方式，而不是跑出新的 Docker 容器。
權限與資料夾隔離：這類面板的標準作法就是為每一個新增的網站建立獨立的 Linux 使用者，並利用 open_basedir 或是 chroot 將行程鎖死在該網站自己的目錄裡（如 /www/wwwroot/site1）。完全符合你的資料夾隔離需求。

4.2 KiB Raw Permalink Blame History Unescape Escape