《Docker開發實踐》作者曾金龍：迅雷雲的Docker開發實踐（圖靈訪談）

曾金龍就職於迅雷網路，是國內覆蓋面最廣的“迅雷P2P引擎”核心研發成員。他畢業於中山大學，具有電腦科學碩士學位，他的研究方向是P2P網路、音視訊傳輸和CEP系統。曾金龍對Docker技術有著深入的理解，是國內較早將Docker引入到實際軟體開發、測試和部署中的人。他在2015年出版了《Docker開發實踐》一書。

問：作為迅雷P2P引擎的核心開發成員，能否談一下當時開發的經歷以及克服了哪些困難？

我一開始工作的時候就進入到了一家在P2P領域NO.1的公司，而且還是核心團隊，所以壓力非常大。我發現，現實的P2P依然處在第一代P2P的水平，和研究上的P2P有很大差異。我們在高校裡面研究的是各種結構化的P2P，叫做第二代P2P。這就意味著即便我是以P2P為研究方向來到了迅雷，但一切都是歸零的。這是理想與現實之間的差異，對我個人而言是個困難。

開發上的困難有兩個方面，一是新做的專案往往配置基礎環境會耗費大量的時間，而且開發不會碰到的問題在測試和運營那裡會“莫名其妙”地出現，所以容器是解決程式設計師痛點的好技術。另外就是迅雷雲是全國最大的P2P資料平臺，所以裡面有非常多分工不同的伺服器，有打洞的Punch服務、有索引的Hub服務、跟蹤的Tracker服務以及CDN管理服務等，而且處理的資料量非常大。讓公司各個事業群的專案組合理管理和使用這些叢集確實不容易，而大多數問題都來自不正確的使用，所以我們必須為各個事業群提供更為易用的服務和更加統一的介面。所以我們後面在迅雷雲引入了Docker。

問：能否談一下迅雷雲使用Docker的過程？

其實最初的時候，迅雷團隊對Docker是懷有謹慎的態度的。不能因為別人說好我們就用，需要先試，真的好我們才敢用，嚐到甜頭我們才願意用。一開始我們用Docker來加快團隊之間的協作效率，因為通過它部署的環境可以一次構建到處使用，所以開發、測試和部署都能夠在一個非常一致的環境中進行，這是很初級的用法。隨著對這個模式的認可，迅雷內部越來越多的團隊接納了我們的建議，於是迅雷、迅雷看看、迅雷遊戲都採用了Docker，引入到了開發、測試和部署中。

後面我們的伺服器專案基本就遷移到了Docker之上。當然，一開始大家對Docker的安全性都會有所顧慮，但其實大多數顧慮都是因為對Docker不夠理解而產生的。有了內部產品線的支援，我們後面把迅雷雲部分伺服器資源用Docker重新部署。迅雷雲本身就是一個非常高效的叢集系統，現在引入Docker是為了讓資源使用更加便捷。因為研發人員的流動性比較高，不是所有的開發者對迅雷雲內部資源的使用都熟悉，所以我們現在就是藉助Docker去為各個業務的開發提供一套更普適的介面。

問：迅雷雲在容器方面做了哪些優化和調整？

一是整合現有的叢集，將部分叢集更改為Docker叢集，特別是新增部分。二、由於迅雷雲是一個重資料、輕業務的雲，所以在資料管理方面，像Docker的Data volumes和Data volume containers這種簡單的方式還是不能夠滿足，所以我們主要還是以迅雷雲自己的管理系統為主。為了能夠讓Docker之上的業務更好地使用我們的叢集，我們新增了適配層。三、排程演算法是迅雷雲定製優化的。最後，我們有自建的私有倉庫，提供常用映象，讓我們的開發更加快速。

問：Adrian Cockcroft是雲技術社群中的思想家之一，他將微服務與Docker的結合視為一種顛覆，認為這種開發方式會極大提高開發團隊敏捷性和適應性。請問迅雷雲團隊是否有這方面的實踐？對於這方面的技術融合你有什麼樣的建議？

微服務是把一個原本很複雜的服務解耦拆解為一些相對功能單一的服務，這在迅雷雲內部是一直都非常提倡的。我們認為一個服務專心做好一件事是最好的，這對解耦、易用、升級都非常有好處。迅雷內部把Hub服務和Tracker服務都進行了分解和抽象，提供給各個專案組。Hub本身是很複雜的，但我們的服務介面卻是個位數，包括對CDN資源服務的使用方面我們也是重構了一套更加簡單易用的服務。

有一點很遺憾的是我覺得迅雷雲裡面做得最好的微服務並沒有使用到Docker，也就是我們的“水晶計劃”。這主要是因為我們的節點是各種客戶端裝置，但我們的設計宗旨依然是遵循微服務的。水晶計劃的節點是各種各樣的裝置，差異性非常大。但沒有關係，在使用者那裡，它就是可靠的CDN。我個人覺得微服務加上Docker是非常合適的，因為微服務很重要的一點就是解耦，而採用容器技術來解耦隔離是非常恰當的。再進一步考慮到服務的擴容和遷移的話，微服務設計加上Docker作為載體也是非常合適的。我的建議就是，一個服務一個容器，或者說一種服務，一類容器，這樣一一對應地去部署。

問：Docker的image和安全問題一直都受到關注，特別在去年的出現的ShellShock和Heartbleed問題之後，請問在Docker的安全方面你是否有哪些經驗可以分享？

其實，越多人使用的技術越安全，但一旦不安全造成的損失也非常大。迅雷在使用Docker這方面一直沒有把資料層面交給迅雷雲之外的系統。即便是Docker使用迅雷雲的資料，也是通過我們的適配層，而通過適配層接進來的操作是要經過授權的，對使用能力也要進行限制，同時操作都是可跟蹤和統計的。另外就是對使用者的授權管理，嚴格規範的管理在安全方面很有必要。還有就是做好隔離工作，不僅僅是通過核心的Namespace/cgroup，同時也可以在不同層面隔離，比如VM和容器的隔離等。

問：在ClusterHQ最近的一項調查中顯示，只有38%的IT專業人士在生產環境中使用容器，人們對於容器技術使用的顧慮包括安全、資料管理、IT人員技能、永久儲存與可靠性等問題。你認為以Docker為代表的容器技術面臨的最大阻礙是什麼？是否在不遠的未來有望跨越技術應用的鴻溝？

我覺得當前容器技術面臨的最大阻力是安全問題和管理工具。安全性一直是企業使用容器所擔心的問題，而另一個問題就是管理工具，特別是對叢集的管理。現有的叢集管理工具，比如Kubernetes，並不是很好上手，對於很多運維人員而言，特別是對一些小企業來說，運維人員可能並沒有深入地去學習這些工具怎麼使用。所以如果這些工具的部署配置和使用能夠非常簡單，那麼容器在實際生產中可能會越來越廣泛。

這種情況有些類似於ISO/OSI的參考模型和TCP/IP協議模型，前者從設計上而言是很優秀的，但後者卻成了事實標準，為什麼？因為簡單。所以一門好技術，不但要技術本身好，而且要做到讓別人更好地接納也很重要。Docker相對於以前的諸如lxc的系統是一個進步，我希望Docker能繼續做好整個工具鏈，讓Docker叢集更加平易近人。

問：Docker, CoreOS, 以及其他業界成員一起創立了“開放容器計劃（OCP)”，你認為OCP的成立對於軟體開發行業會造成什麼影響？

Docker和CoreOS這對競爭對手握手言和，一起成立OCP，對於整個容器生態圈而言是一個非常重大的利好。因為OCP可以讓容器技術更加統一化，如果所有的容器都遵循一套標準，那麼使用容器的開發者就省了很多麻煩。而且有了統一的標準，就意味著在不同平臺上的容器也可以相互遷移，Docker的映象可以遷移到CoreOS上，反之亦然。破除各自為陣，容器技術會變得更加易用，同時也會加快其在產業上的應用。

問：Docker和CoreOS各自都具有哪些優勢？它們的結合會帶來哪些好處？

Docker更想去做一個以容器為中心的服務平臺，所以它給使用者提供了很多便利的操作，還包括一些叢集管理工具鏈。CoreOS則更加側重容器本身的標準化，CoreOS的開放標準更能夠促進容器的開放，這也是OCP的宗旨，此外，CoreOS在安全性和可組合性上也做得更好。它們的結合可以取二者優勢，彌補各自不足。

問：Docker最新發布的“Docker試驗性發布”是一次有趣的嘗試，請問你是否使用過上面的實驗性功能？你覺得這個系統的釋出對於Docker來說有哪些好處？

如果你指的是out-of-process volume plugins，我有了解但沒有使用過。在對資料方面採用外掛的形式，讓使用者自己去適配不同的儲存系統是非常有必要的，所以我覺得這個功能非常有用。我在上面也提到了，我們迅雷雲就寫了一套適配層去操作我們自己的資料系統。所以後面我們團隊會去深入地理解這個功能，然後跟進。

問：學習Docker的進階過程有哪幾個階段？你希望程式設計師們以怎樣的方式使用《Docker開發實踐》這本書？

我覺得學習Docker有三個階段。第一個階段是對Docker本身功能的使用，也就是入門層，你要理解什麼是映象、容器、Registry、Dockerfile等，瞭解這些物件的基本操作，能夠構建出自己的應用環境來。第二個階段是能夠駕馭Docker叢集。這個階段你需要學習和使用Docker相關的工具，比如Kubernetes、Shipyard、Machine+Swarm+Compose等，根據不同的需求，需要使用不同的工具。第三個階段就是發現和解決這些工具裡面的問題，為自己的場景深度定製。

我覺得程式設計師可以從兩個方面來使用好《Docker開發實踐》這本書，一方面可以把它當做開發手冊，因為這本書的內容幾乎涵蓋了Docker所有的知識點，我們對其內容進行了很系統地梳理。所以當你對Docker有什麼疑問的時候，把《Docker開發實踐》放在電腦前面，隨手翻一翻基本就可以解決。另一方面，可以作為案例引導。這本書後面兩篇甄選了當前經典的應用場景，一步步帶領讀者把服務搭建起來，並且把可能遇到的問題都標出來，教讀者如何解決。所以，讀者也可以參照本書的案例去更好更快地在實際生產中使用Docker，提升效率、少走彎路。

問：《Docker開發實踐》的高階篇對Docker生態圈做了非常翔實的介紹和實踐，為什麼要對Docker生態圈著墨如此之多？對於這部分內容的遴選你有什麼樣的標準和原則？

Docker本身的操作其實很簡單，如果複雜的話，Docker就不會像今天這樣成功。然而我所知道的市面上之前所有關於Docker的書籍，都是把基礎操作寫了一大篇，然後堆砌一些案例，就成了一本書，我認為這是在浪費讀者的錢和時間。基礎的東西寫成幾章是合理的，寫成一本書就是打腫臉充胖子了。我們在《Docker開發實踐》中把這些內容進行了壓縮，不想去濫竽充數，也不會去浪費筆墨。

上面我提到的Docker面臨的阻礙很大一點就是它的工具鏈不完善和不易用。你會發現在網路上程式設計師求助最多的也是Docker生態圈的實踐，因為Docker做得還不夠好，稍微不小心就犯錯。所以，既然基礎篇不該講那麼多，而且生態圈又是使用Docker的開發者心中的痛點，那麼我就著重筆墨去寫這部分，讓大家少走彎路。這部分內容看上去有些散，每一章都是講一個工具或者是一組工具，但是書中選的Kubernetes、Shipyard等都是我們最需要的和最熱點的工具，而且它們的構建又相對複雜。所以，我遴選的原則就是，重要又是難點的，我就選。所以這就成了《Docker開發實踐》中的高階篇。

---

更多精彩，加入圖靈訪談微信！