為了獲得更高效率的云服務，容器技術自誕生以來便受到了業界的廣泛支持。通過優秀的隔離技術，容器可以借由掛載不同的運行時從而對不同的應用提供支持。但在實際應用中，隨著不同模板數量的增多，容器環境下的鏡像分發逐漸成為了一個令云服務管理者頭疼的問題。而更加頭疼的是，目前業界還沒有形成完整統一的鏡像分發標準;各個容器的使用者只能自行解決這一難題。

　　在日前舉辦的由51CTO主辦的WOT全球軟件與運維技術峰會上，各方技術大咖齊聚一堂，在開源與容器技術分論壇中各抒己見，探討了與容器相關的各種技術應用與實踐。而在這些討論中，資深容器技術專家肖德時便就容器環境下的分布式鏡像倉庫技術闡述了自己的觀點。

　　Docker在鏡像分發上留下的空白

　　在此次WOT峰會的開源與容器技術分論壇中，肖德時表示：雖然目前創建和啟動容器的標準工具以及容器的運行時和鏡像標準都已經頒布，但OCI仍舊沒有發布針對容器環境下的鏡像分發標準。而我們所能知道的就是容器鏡像分發標準的1.0版本將圍繞Docker Registry HTTP API V2來展開。

　　目前能夠確定下來的容器鏡像分發標準包括：

　　Namespace-oriented URI Layout

　　PUSH/PULL registry server for V2 image manifest format

　　Resumable layer PUSH support

　　V2 Client library implementation

　　而包括不可變鏡像參考、多架構支持、V2版兼容性下的遷移等標準在內的眾多重要標準則仍舊在討論中，沒有形成共識。

　　從目前的實際使用情況來看，肖德時表示：官方發布的Docker registry所缺少的特性還很多，企業還無法進行實際的商用部署。針對這一領域，Docker有自己的Docker Hub服務來解決容器的打包、存儲和分發問題。但這一服務訪問起來很慢，而且他是一個閉源的服務，外界無法知道他是如何實現的。此外，Docker還發布了DTR工具;但這一工具是基于單機環境而設計，本質上無法實現HA擴展，因此也無法滿足企業的高可用需求。

　　Docker發布的registry 2.0雖然是目前用戶***可用的開源版本，但從架構上來看，這個工具并不適合一般的企業來用。首先，他本身并沒有對應的授權機制，這一點就需要外部的組件來控制;其次，他的訪問控制是放在工具內部的，但真正的企業在這方面確實需要其他系統來統一控制的;第三，registry 2.0架構內部缺乏可用的handlers，這使得企業還需要編寫額外的組件來實現相應的監控功能;第四，也是最重要的，在存儲結構方面，registry 2.0仍然是基于單機來設計的，企業需要具備很高的技術實力才能在這一基礎上構建完整的高可用特性。而以上這些正是registry 2.0在商用中所遇到的主要問題。

　　業界實踐

　　面對這些痛點，一種業界大廠都開始了在鏡像分發方面的探索和實踐：

　　騰訊在這方面開發了FID系統：A Faster Image Distribution System for Docker，效果比原生的分發功能好很多，向200個節點分發500M鏡像文件的速度是Docker原生的10倍;部署起來也比較方便。

　　阿里發布了蜻蜓系統，這是一套基于P2P的文件分發系統，吞吐量是原生應用的57倍，帶寬占用僅為原來的不到1%。

　　VMware則面向市場發布了自己的Harbor系統來解決鏡像分發問題，同時，他也將registry 2.0本身所固有的一些問題進行了完善。

　　IBM也在展開相關方面的研究，并發布了Wharf架構。

　　容器鏡像分發，任重道遠

　　在分析了眾多業界在容器鏡像分發領域的實踐之后肖德時表示：目前各家研究的方向和實際的效果來看，P2P技術的確可以有效提高鏡像分發的效率，而且文件體積越大、效率就越高。

　　另外，共享層模式將可以有效降低容器鏡像存儲的冗余度。

　　而在最重要的高可用方面，目前的所有解決方案和研究成果也還都需要更多的實踐來驗證。

　　經歷多年發展，容器技術已經取得了良好的應用效果，并獲得了商業用戶的廣泛認同。但我們也不得不承認，包括容器鏡像的打包、存儲和分發等領域，目前的容器技術仍顯得相當稚嫩。而這些領域也是未來IT廠商和云服務提供商將會重點攻克的領域。

　　在經歷了物理機、虛擬機、云服務等一系列進化之后，容器化必將成為未來的主流發展趨勢。而容器技術本身的發展更會因為業界的廣泛參與和研究而變得越來越快、越來越好。