曾金龍：迅雷雲的Docker開發實踐

非商業轉載請註明做譯者、出處，並保留本文的原始連接：http://www.ituring.com.cn/article/201256

曾金龍就任於迅雷網絡，是國內覆蓋面最廣的「迅雷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集羣，特別是新增部分。2、因爲迅雷雲是一個重數據、輕業務的雲，因此在數據管理方面，像Docker的Data volumes和Data volume containers這種簡單的方式仍是不可以知足，因此咱們主要仍是以迅雷雲本身的管理系統爲主。爲了可以讓Docker之上的業務更好地使用咱們的集羣，咱們添加了適配層。3、調度算法是迅雷雲定製優化的。最後，咱們有自建的私有倉庫，提供經常使用鏡像，讓咱們的開發更加快速。

問：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開發實踐》中的高級篇。

---

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