這裏除了安全，什麽都不會發生！Docker鏡像P2P加速之路
在使用Docker運行容器化應用時，宿主機通常先要從Registry服務（如Docker Hub）下載相應的鏡像(image)。這種鏡像機制在開發環境中使用還是很有效的，團隊成員之間可以很方便地共享同樣的鏡像。然而在實際的生產環境中，當大量主機需要同時從Registry下載鏡像運行容器應用時（比如發布新版本，打補釘等情形），Registry 服務往往會成為鏡像分發的瓶頸，應用鏡像需要較長時間才能傳送到所有主機上，使得應用發布的周期大大延長。
不少企業提出了P2P加速鏡像下載的解決方案，但都是私有雲及內部環境的使用場景，在公有雲為得到使用。其中很大一部分原因是共有雲使用P2P的安全性問題，如何確保用戶數據在P2P傳輸中是安全的成為了其中的難點。我們就該問題設計實現了確保用戶數據安全的P2P鏡像分發系統。本文就其安全性展開闡述。
架構：
菊廠P2P容器鏡像分發系統示例圖
菊廠P2P容器鏡像分發系統包含3個組件：客戶端代理（Proxy）、BT客戶端和BT Tracker。
客戶端代理（Proxy）
客戶端代理部署在集群的每個節點中，配置為Docker的Http Proxy，截獲Docker Daemon的鏡像下載請求，通知Client下載，並最終將鏡像導入到Docker daemon中。
BT客戶端
部署在集群節點的BT客戶端和Tracker共同組成了一個完整的P2P文件傳輸系統。在整個鏡像的分發過程中，它們利用BT協議完成鏡像下載。
BT Tracker
Tracker是BT系統的一部分，它存儲了BT客戶端下載過程中所需要的元數據信息和種子信息，並協助各個BT客戶端完成整個通信過程。
安全：
首先，我們限制了跨集群的P2P下載，最大限度的租戶間的數據泄露。
之後，在鏈路層面的安全性和業務層面的安全性做了增強。
鏈路層面的安全性：
Docker Daemon<------->Proxy
首先是Docker Daemon到Proxy這條鏈路。我們讓客戶端代理只監聽localhost端口，杜絕外部使用該代理的可能性。同時，客戶端代理綁定一套簽發給registry域名的自簽名證書，用戶劫持Docker Daemon的請求。各個代理綁定的服務端證書和CA證書都是Proxy在啟動的過程中臨時生成的，並將CA證書添加到機器的信任證書當中。
代理綁定的證書只保存在內存中，即使通過特定方式獲取到當前節點的CA證書和服務端證書，也無法截取其他節點數據。
BT Client通信安全和一致性：
在P2P下載過程中，種子包含以下信息：? length:文件長度，單位字節(整數)
? md5sum(可選):長32個字符的文件的md5校驗和，bt不使用這個值，只是為了兼容一些程序所 保留!(字符串)
? name:文件名(字符串)
? piece length:每個塊的大小，單位字節(整數)
? pieces:每個塊的20個字節的sha1hash的值(二進制格式)
常用的BT Client未做Client之間的數據加密，只在每塊數據下載完成後校驗數據的sha1hash值是否與pieces中的值一致。
我們在BT Client之間增加了SSL雙向認證及加密通信，為每個layer生成了CA證書，並為每個下載該layer的Client生成服務端證書。當Client間握手時，需確保對方的服務端證書為layer的CA證書簽發的，並且對方的服務端證書必須是簽發給當前layer的。
這種增強，確保了在傳輸過程中，用戶的layer數據時加密的，即使劫持了鏈路也無法獲得數據。業務層的安全性 ：
在確保鏈路安全後，我們還做了一層業務安全加固。在Client間SSL握手成功後，還需要完成用戶JWT Token的校驗。
JWT Token中包含Token解密證書、用戶的基本信息和對鏡像的操作權限，解密證書讓用戶可本地解析Token的信息。
根據JWT Token的這個特性， 我們增加了Token校驗的邏輯。
? 采用本地Token的解密證書校驗連接發起者的Token，可以確保連接發起者的Token不是自簽發的Token。
? 校驗Token中的操作權限，確保連接發起者的對該鏡像層有下載權限。
上述鏈路層和業務層安全性的增強，使得P2P鏡像下載適用於公有雲場景，確保用戶數據的安全。目前，菊廠容器鏡像新上線特性P2P，據說實力超群可以超越蜻蜓，有興趣的朋友可以前來一試~
https://www.huaweicloud.com/product/swr.html
這裏除了安全，什麽都不會發生！Docker鏡像P2P加速之路