Remove unnessary files
This commit is contained in:
ChenKaiLiuG
5
.gitignore
vendored
5
.gitignore
vendored
@@ -1 +1,4 @@
|
||||
karylab-minecraft/example-server/
|
||||
karylab-complex/example-server/
|
||||
karylab-complex/others/
|
||||
vs-code-server/
|
||||
karylab-vps/
|
||||
@@ -4,7 +4,7 @@
|
||||
# 對接目標：PVE VM 上的 frps（具備固定 IP）
|
||||
# =====================================================
|
||||
|
||||
serverAddr = "45.64.97.4" # PVE VM 固定 IP
|
||||
serverAddr = "your.vps.fixed.ip" # TODO: 填入 PVE VM 的固定 IP
|
||||
serverPort = 7000 # 與 frps 的 bindPort 對應
|
||||
|
||||
# TLS 加密控制通道（與 frps 的 transport.tls.force = true 對應）
|
||||
|
||||
@@ -1,122 +0,0 @@
|
||||
# 工程師交接
|
||||
|
||||
## 1. cloudflared -> vps tunnel（已完成）
|
||||
|
||||
### 實作結果：採用方案一（FRP）
|
||||
|
||||
#### 檔案清單
|
||||
|
||||
| 檔案 | 位置 | 說明 |
|
||||
|---|---|---|
|
||||
| `vpstunnel+npm.yml` | `karylab-entrance/` | 內網 compose stack（frpc + npm + filebrowser） |
|
||||
| `frpc.toml` | `karylab-entrance/config/` | frpc 設定，掛載至 frpc container |
|
||||
| `vps-tunnel.yml` | `karylab-vps/` | VPS compose stack（frps） |
|
||||
| `frps.toml` | `karylab-vps/config/` | frps 設定，掛載至 frps container |
|
||||
|
||||
#### 架構說明
|
||||
|
||||
```
|
||||
[外部訪客]
|
||||
│ TCP 80/443
|
||||
▼
|
||||
[PVE VM（固定 IP）]
|
||||
└─ frps container
|
||||
│ TLS 加密隧道（Port 7000）
|
||||
▼
|
||||
[UCG 內網]
|
||||
└─ frpc container ─→ npm container（Port 80/443）
|
||||
│
|
||||
▼
|
||||
NAS / 其他內網服務
|
||||
```
|
||||
|
||||
#### 安全設計
|
||||
|
||||
- **控制通道 TLS**：frps 強制 `transport.tls.force = true`，frpc 開啟 `tls.enable = true`，控制通道全程加密
|
||||
- **Token 驗證**：frpc 與 frps 使用 HMAC-SHA256 簽名的 token 驗證身份
|
||||
- **NPM 管理後台（Port 81）不對外 tunnel**：只能從內網直接存取 `http://內網機器IP:81`
|
||||
- **建議**：在 VPS 防火牆（UFW / iptables）限制 Port 7000 只允許內網出口 IP 連入
|
||||
|
||||
#### 部署注意事項
|
||||
|
||||
1. **VPS 防火牆**必須開放 inbound TCP Port **80、443、7000**，否則 frpc 會出現 `i/o timeout`
|
||||
2. `frpc.toml` 的 `serverAddr` 填入 VPS 固定 IP 或可解析的網域皆可
|
||||
3. `frpc.toml` 與 `frps.toml` 的 `token` 必須設定為**同一組強密碼**
|
||||
4. 設定檔路徑：
|
||||
- VPS：`/opt/frp/frps.toml`
|
||||
- 內網：`/opt/cloudflare/frp/frpc.toml`
|
||||
|
||||
---
|
||||
|
||||
|
||||
|
||||
### 目標：
|
||||
|
||||
原來是cloudflare tunnel對接npm 再讓npm去找相關的設備
|
||||
直接把tunnel換成其他容器 然後對接vps(pve上的vm)
|
||||
|
||||
### 方案說明：
|
||||
|
||||
部署在 PVE 上的那台「固定 IP VM」當作私有的 Cloudflare 節點（也就是您的自建 VPS），然後用特定的「隧道容器」來取代 cloudflared+npm.yml 中的 cloudflared，打通兩個隔離的網段。新的版本更新到 vpstunnel+npm.yml。
|
||||
|
||||
要達成這個目的，有兩種主流的開源工具/容器可以完美取代 Cloudflare Tunnel，以下為您分析兩種作法：
|
||||
|
||||
**方案一：使用 FRP (Fast Reverse Proxy) —— 最直接的 1:1 替換**
|
||||
FRP 的運作邏輯與 Cloudflare Tunnel 幾乎一模一樣，只是伺服器從 Cloudflare 變成了您的 PVE VM。
|
||||
|
||||
架構配置：
|
||||
```
|
||||
前端 (您的 PVE VM - 具備固定 IP)：安裝並運行 frps (FRP Server) 容器。它負責監聽來自網際網路的請求（如 Port 80, 443, 25565）。
|
||||
|
||||
後端 (您的 UCG 網段內)：部署一個 frpc (FRP Client) 容器。這個容器會主動向 frps 發起連線，建立一條加密隧道。
|
||||
|
||||
路由分發：frpc 收到流量後，將 HTTP/HTTPS 流量轉交給同在 UCG 網段內的 NPM (Nginx Proxy Manager)，再由 NPM 去找 UCG 底下的 NAS 或其他設備。
|
||||
```
|
||||
優點：架構與 Cloudflare Tunnel 概念完全一致，完全不用開 Port，因為是 frpc 由內向外主動連線的。
|
||||
|
||||
缺點：設定檔是基於 ini/yaml，需要稍微學習一下語法。
|
||||
|
||||
參考資源：FRP 官方 GitHub 專案庫與文件
|
||||
|
||||
**方案二：使用 WireGuard 或 Tailscale —— 網路層的虛擬區網 (推薦)**
|
||||
與其只代理特定 Port，不如在 PVE VM 和 UCG 網段之間建立一個專屬的「虛擬私有區域網路 (VPN)」。
|
||||
|
||||
架構配置：
|
||||
```
|
||||
前端 (您的 PVE VM)：安裝 NPM 以及 Tailscale (或 WireGuard) 容器。將 Zyxel 的 80/443 Port Forwarding 到這個 VM。
|
||||
|
||||
後端 (您的 UCG 網段內)：只需要在負責提供服務的機器（或 NPM）上安裝 Tailscale，讓它們加入同一個虛擬網路。
|
||||
|
||||
路由分發：當外部訪客連線到您的固定 IP (PVE VM) 時，VM 上的 NPM 會解析網域，並透過 Tailscale 給的虛擬 IP（例如 100.x.x.x）將流量安全地轉發到 UCG 底下的設備。
|
||||
```
|
||||
優點：
|
||||
|
||||
極致的隔離：Tailscale / WireGuard 使用點對點加密，流量穿梭在 Zyxel 網段與 UCG 網段之間時是完全加密的。
|
||||
|
||||
管理方便：所有伺服器都在同一個虛擬網段內，互相溝通就像在同一個 Switch 下一樣簡單。
|
||||
|
||||
參考資源：Tailscale 官方網站、WireGuard 官方網站
|
||||
|
||||
**流量動線解析 (以方案二為例)**
|
||||
假設訪客要訪問您在 UCG 網段下的 Nextcloud：
|
||||
|
||||
外部訪客輸入 cloud.example.com。
|
||||
|
||||
DNS (Cloudflare 灰雲) 將網域解析到您的 中華電信固定 IP。
|
||||
|
||||
流量抵達 vps 側路由器，透過 Port Forwarding 送入 PVE VM (自建 VPS) 的 Port 443。
|
||||
|
||||
PVE VM 上的 NPM 接收到請求，查看設定規則，發現要把流量送給 Nextcloud。
|
||||
|
||||
流量進入 隧道容器 (WireGuard/Tailscale)，被加密打包。
|
||||
|
||||
加密封包穿越實體網路，抵達 UCG 網段下的目標機器。
|
||||
|
||||
目標機器解密封包，交由 Nextcloud 容器 處理。
|
||||
|
||||
這樣做的好處？
|
||||
擺脫限制：完全沒有 Cloudflare 的 100MB 檔案大小限制，也沒有任何協議的限制（您可以傳輸 TCP, UDP, 甚至跑自訂協議）。
|
||||
|
||||
完美隔離：您的 UCG 路由器不需要開放任何對外 Port (Inbound 規則維持全擋)，所有的外部威脅第一時間都是由 Zyxel 底下的 PVE VM 承受。就算 VM 被攻破，攻擊者也無法直接看見 UCG 底下的設備（除非他們破解了加密隧道）。
|
||||
|
||||
掌控權：資料不再經過第三方的邊緣節點解密（Cloudflare 橘雲會解密 HTTPS 流量），真正的端到端都在您自己的掌控之下。
|
||||
@@ -1,5 +0,0 @@
|
||||
version: '3.8'
|
||||
|
||||
services:
|
||||
# 1. 核心郵件伺服器（DMS v14+）
|
||||
mailserver:
|
||||
68
karylab-entrance/others/exchange.md
Normal file
68
karylab-entrance/others/exchange.md
Normal file
@@ -0,0 +1,68 @@
|
||||
# 工程師交接
|
||||
|
||||
## 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 路由
|
||||
|
||||
**部署選項：**
|
||||
|
||||
1. **直接掛載 Socket 模式**（當前配置）
|
||||
- 優點：簡單穩定，性能最好
|
||||
- 缺點：安全風險高，給予容器完整 Docker 權限
|
||||
|
||||
2. **DinD (Docker-in-Docker) 模式**
|
||||
- 原理：Coolify 內部運行自己的 Docker daemon
|
||||
- 問題：性能開銷大、存儲驅動衝突、Cgroups 限制無效、鏡像存儲浪費、網路配置複雜、穩定性差
|
||||
- 適用：輕量級用途（如 CI/CD），不適合生產環境
|
||||
|
||||
3. **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`）。完全符合你的資料夾隔離需求。
|
||||
Reference in New Issue
Block a user