跳轉到

D-20260705-06｜D1 部署模型：一 repo＝一部署單元＝一條 CI

背景與驅動力

STUN／TURN／ 基礎設施節點 ／repo 關係多輪釐清後（STUN 是 NAT 鏡子、幾封包即退場；TURN 是打洞失敗時的計費中繼），需要一個 repo 切分原則來安放 TURN 設定與 bootstrap 清單。使用者定原則：一 repo＝ 一部署單元 ＝ 一條 CI。

考慮過的選項

  • TURN config 掛 signaling repo：部署目標不同（Cloudflare 對 k8s），提案作廢。
  • open-4wd-bootstrap-list 獨立 repo：清單非部署單元，取消、搬主 repo。
  • signaling 與 pinning 合併：技術棧（Worker 免費全球邊緣對有硬碟真機器）、自架者畫像、必要性曲線（signaling 有 GossipSub 純 P2P 替代、pinning 角色無替代）三理由否決。

決定

  • TURN 升獨立 repo open-4wd-turn（coturn 設定 ＋k8s manifests＋CI，當時定部署官方 k8s）；client STUN 預設官方 coturn、stun.l.google.com 公網保底；TURN token 由 signaling 發放、coturn 以 shared secret（REST API auth）驗證。
  • bootstrap 清單搬主 repo bootstrap/list.txt：社群 PR 加節點、維持執行期 GitHub raw 抓取語意（不進 bundle、不隨版——bootstrap 過期須能不發版即更新）。
  • repo 總表四 repo：主 repo（含 bootstrap 清單）＋ open-4wd-pinning（Go、k8s、兼 bootstrap 節點與 DMCA 後端）＋ open-4wd-signaling（Cloudflare Worker）＋ open-4wd-turn。

後果與影響

repo 邊界自此定型為四 repo；但「一 repo＝ 一部署單元」的部署語意隔日即被 D-20260706-02 的公版 Template 模型取代（TURN 部署時程另由 D-20260706-03 延後）。pinning 的 Go 技術棧其後由 D-20260720-01 翻案；signaling 的 Cloudflare 定位由 D-20260722-01 與 D-20260724-01 兩度演變。