🎯 開發動機與解決痛點
在現代容器化開發流程中，將本地建置的 Docker 映像檔部署到遠端伺服器一直是個麻煩的問題。開發者面臨著多種不理想的選擇：使用公共註冊中心會暴露程式碼或產生費用、自架註冊中心增加維護負擔、傳統的 save/load 方式效率低下。
核心痛點：
- 外部註冊中心依賴： Docker Hub 或 GitHub Container Registry 需要公開程式碼或付費私有儲存庫
- 自架註冊中心成本： 需要額外的服務維護、安全配置和儲存成本
- 全量傳輸效率問題： docker save/load 會傳輸整個映像檔，即使 90% 的層級已存在於目標伺服器
- 遠端建置資源浪費： 在生產環境重新建置映像檔浪費時間和伺服器資源
Unregistry 透過創新的 SSH 隧道技術和 containerd 原生整合，提供了一個優雅的解決方案：docker pussh myapp:latest user@server 一行指令即可完成映像檔的高效傳輸，只傳送缺失的層級，無需中介註冊中心。
🛠️ 技術框架與設計模式
🔧 Go 1.24+
使用最新的 Go 語言特性，包括泛型和改進的錯誤處理，確保高效能和型別安全
📦 containerd v2
直接整合容器運行時的映像檔儲存，消除中間層級，實現零複製的高效能存取
🌐 Docker Distribution v3
基於 Docker 官方註冊中心實作，確保完整的 OCI 規範相容性和企業級穩定性
📊 OpenTelemetry
內建可觀測性支援，提供分散式追蹤、指標收集和日誌整合功能
核心設計模式
🔄 Adapter 模式
透過中介軟體註冊機制，將 containerd 的儲存介面適配到 Docker Distribution 框架，實現無縫整合。
🎯 Strategy 模式
支援多種 manifest 格式（OCI、Docker schema2、manifest lists），透過多型實現統一處理邏輯。
🏗️ Facade 模式
Registry 類別提供簡化的介面，隱藏複雜的 containerd 操作細節，降低使用門檻。
🔧 核心業務邏輯實作
func registryMiddleware(
_ context.Context, _ distribution.Namespace,
_ storagedriver.StorageDriver, options map[string]interface{},
) (distribution.Namespace, error) {
cli, err := client.New(sock, client.WithDefaultNamespace(namespace))
if err != nil {
return nil, fmt.Errorf("create containerd client: %w", err)
}
return ®istry{client: cli}, nil
}
這段程式碼展示了 Adapter 模式的精妙應用：透過中介軟體註冊機制，無縫將 containerd 客戶端整合到 Docker Distribution 框架中。
🎨 設計模式應用
func unmarshalManifest(blob []byte) (distribution.Manifest, error) {
var ociManifest ocischema.DeserializedManifest
if err := ociManifest.UnmarshalJSON(blob); err == nil {
return &ociManifest, nil
}
var schema2Manifest schema2.DeserializedManifest
if err := schema2Manifest.UnmarshalJSON(blob); err == nil {
return &schema2Manifest, nil
}
return nil, distribution.ErrManifestVerification
}
此處使用了 Strategy 模式，透過多種策略處理不同的 manifest 格式，確保最大的相容性和擴展性。
⚡ 效能優化實作
func newBlobWriter(ctx context.Context, client *client.Client) {
opts := []leases.Opt{
leases.WithRandomID(),
leases.WithExpiration(leaseExpiration),
}
lease, err := client.LeasesService().Create(ctx, opts...)
ctx = leases.WithLease(ctx, lease.ID)
writer, err := client.ContentStore().Writer(ctx,
content.WithRef("upload-"+id))
}
這個實作透過 containerd 租約機制實現了高效的記憶體管理，避免垃圾回收過程中的內容遺失。
💡 應用情境
📱 生產環境部署
直接將本地建置的映像檔推送到生產伺服器，無需中介註冊中心。支援多平台映像檔和 SSH 金鑰認證，適合企業級部署流程。
🔄 CI/CD 流水線整合
在 GitHub Actions 或 GitLab CI 中直接推送到目標伺服器，簡化部署流程，減少外部依賴和潛在的單點故障。
🏠 家庭實驗室和離線環境
在無法存取公共註冊中心的隔離網路環境中分發映像檔，特別適合敏感資料處理或法規遵循要求嚴格的環境。
🧪 開發測試工作流程
快速將測試映像檔部署到測試伺服器，支援增量傳輸，大幅提升開發迭代效率，特別適合頻繁測試的開發團隊。
🌐 邊緣運算部署
將容器應用部署到邊緣節點或物聯網設備，透過 SSH 隧道確保安全性，只傳輸必要的映像檔層級以節省頻寬。
🏗️ 軟體架構圖
此架構圖展示了 unregistry 如何透過 SSH 隧道建立安全連線，並直接整合 containerd 儲存後端，實現高效的映像檔傳輸。Distribution 框架提供標準的 OCI 註冊中心介面，而底層的 Blob Store、Manifest 和 Tag Service 直接操作 containerd 的內容和映像檔儲存。
❓ 常見問題 Q&A
🏭 生產伺服器要如何設定？
基本環境需求
Docker 環境：確保目標伺服器已安裝 Docker 並正常運行（使用 docker version 確認）
containerd 支援：建議啟用 containerd 映像檔儲存以獲得最佳效能，檢查路徑 /run/containerd/containerd.sock
權限設定：SSH 使用者必須屬於 docker 群組或擁有 sudo 權限執行 Docker 指令
SSH 連線設定
ssh-keygen -t ed25519 -C "your-email@example.com"
ssh-copy-id -i ~/.ssh/id_ed25519.pub user@production-server
ssh user@production-server "docker version"
ssh user@production-server "sudo ls -la /run/containerd/containerd.sock"
生產環境最佳實務
網路安全：使用防火牆限制 SSH 存取，僅允許特定 IP 連線
監控整合：設定 UNREGISTRY_LOG_LEVEL=info 並整合到現有的日誌監控系統
資源管理：定期清理未使用的映像檔：docker system prune -a
🔧 這個軟體的原理是不是把 docker image 透過 SSH tunnel 推送到遠端伺服器，然後遠端伺服器使用這個 docker image 建立 container？
完整工作流程解析
正確！您的理解完全準確。這正是 Unregistry 的核心工作原理：
詳細步驟流程：
- 建立 SSH 隧道：使用
docker pussh myapp:latest user@server 時，系統首先建立加密的 SSH 連線到目標伺服器
- 啟動臨時註冊中心：在遠端伺服器上自動啟動 unregistry 容器，監聽隨機端口（如 localhost:55123）
- 端口轉發：透過 SSH 隧道將本地端口轉發到遠端的 unregistry 服務
- 智慧型映像檔傳輸：僅推送缺失的映像檔層級，大幅減少傳輸時間和頻寬使用
- 即時可用：遠端 Docker 立即可使用該映像檔建立和運行容器
- 自動清理：傳輸完成後，自動移除臨時的 unregistry 容器和 SSH 隧道
與傳統方式的差異
傳統方式（docker save/load）：
• 傳輸完整映像檔（可能數 GB）
• 需要手動管理檔案傳輸
• 無法利用現有層級，浪費頻寬
Unregistry 方式：
• 僅傳輸差異層級（通常減少 70-90% 傳輸量）
• 一行指令完成整個流程
• 利用 containerd 的層級去重機制
containerd 整合優勢
直接儲存存取：如果遠端 Docker 使用 containerd 映像檔儲存，推送的映像檔立即可用，無需額外的 pull 操作
傳統 Docker 儲存：如果未使用 containerd 儲存，系統會自動從臨時註冊中心 pull 映像檔到本地 Docker 儲存
🔄 可以控制 docker image 的版本？例如恢復到上一版的 docker image
版本控制機制
完全支援版本控制！Unregistry 透過 Docker 標籤系統和 containerd 的原生儲存提供強大的版本管理功能：
版本標籤管理
docker pussh myapp:v1.0.0 user@server
docker pussh myapp:v1.1.0 user@server
docker pussh myapp:latest user@server
ssh user@server "docker images myapp"
版本回退操作
ssh user@server "docker tag myapp:v1.0.0 myapp:latest"
ssh user@server "docker stop my-container"
ssh user@server "docker run -d --name my-container myapp:v1.0.0"
docker tag myapp:v1.0.0 myapp:latest
docker pussh myapp:latest user@server
映像檔持久性與清理
版本持久化：所有推送的映像檔版本都會保存在遠端伺服器的 containerd 儲存中，直到手動刪除
儲存空間管理：定期清理不需要的舊版本以節省磁碟空間：
docker rmi myapp:v1.0.0（刪除特定版本）
docker image prune（清理未使用的映像檔）
智慧型儲存：containerd 的層級去重機制確保相同的映像檔層級不會重複儲存，節省空間
生產環境版本管理建議
語意化版本控制：使用 v1.0.0, v1.1.0 等語意化標籤，便於追蹤和管理
藍綠部署：保留前一版本，新版本部署後測試無誤再移除舊版本
備份策略：重要版本建議同時推送到備用伺服器或容器註冊中心作為備份
🚀 為什麼 unregistry 比傳統方式更高效？
傳輸效率對比
Unregistry：僅傳輸缺失的映像檔層級，利用 containerd 的層級去重機制，傳輸量可減少 70-90%
docker save/load：傳輸完整映像檔，即使大部分層級已存在於目標伺服器
零複製設計：直接操作 containerd 儲存，無需中間層級的資料複製
🔒 SSH 隧道如何確保安全性？
多層安全保護
標準 SSH 認證：支援金鑰認證、密碼認證和 SSH 配置檔案
加密傳輸：所有資料透過 SSH 加密通道傳輸，確保端對端安全
臨時性質：unregistry 容器僅在傳輸過程中存在，傳輸完成後自動清理
⚙️ 如何處理 containerd 映像檔儲存整合？
儲存後端設計
啟用 containerd 映像檔儲存：映像檔立即可用，無重複儲存
傳統 Docker 儲存：需額外 pull 操作，映像檔會儲存兩份
垃圾回收整合：透過租約機制和 GC 標籤管理，確保內容不會被意外刪除
🔮 未來展望
Unregistry 作為容器映像檔分發領域的創新解決方案，展現了簡化複雜工作流程的巨大潛力。未來發展方向將聚焦於擴展應用場景和提升使用者體驗。
🌐 P2P 網路支援
探索點對點映像檔分發機制，實現大規模叢集環境中的高效映像檔同步，減少中心化瓶頸
🔄 增量更新最佳化
進一步優化映像檔層級的差異檢測演算法，實現更精細的增量更新，提升傳輸效率
🎯 Kubernetes 整合
開發 Kubernetes operator，支援叢集內的自動映像檔分發和更新，簡化容器編排工作流程
📊 進階監控儀表板
提供詳細的傳輸指標、效能分析和使用統計，幫助使用者最佳化部署流程和資源使用