做為容器技術的代表，Docker已經逐漸獲得了企業的認可。之前InfoQ就有報道過，國內的新浪微博、雪球網等互聯網公司都在生產環境中成功使用了Docker。而對于一些傳統公司，他們的IT設施薄弱、應用架構復雜，在擁抱Docker時，可能遇到的問題相對較多。為此，InfoQ采訪了平安健康互聯網技術平臺資深架構師王延炯。另外，王延炯將在6月11日的PWorld 軟件架構&平臺創新大會上分享題為《基于Docker的開發、運維一體化實踐》的主題演講。

　　InfoQ：您認為Docker***的優勢是什么？當時公司為什么決定使用Docker？

　　王延炯：Docker優勢有幾點，首先是輕量級，其次是面向管理透明，***是生態環境正在逐步建立、社區活躍。輕量級的容器這點，是大家都公認的優勢，我不做過多解釋。而面向管理透明主要是指Dockerfile與AUFS的結合，使得軟件的運行環境面向開發、測試、運維團隊變得透明。而Registry是平臺軟件云化的特征之一。另外，Docker的迅速發展，與其生態環境的蓬勃發展是相輔相成的，例如有Jenkins、Ansible等一系列面向CI以及運維友好的工具平臺迅速支撐。

　　我們公司面向技術平臺的選型，還是比較開放的，各個團隊可以選擇適合自己的平臺，可以嘗試新技術，但目的只有一個，提高公司整體的運營效率。選擇Docker，一方面因為是以上提到的幾個優勢點，另外它也是虛擬化（如Xen/KVM）技術、容器技術兩者并行發展過程中，沉淀出一套適合于公司特點本身，需要取長補短、逐步形成一套***實踐的必經之路。

　　Docker技術本身還是在不斷的發展之中，作為一個新技術，它的出現改變了很多原有軟件研發的流程。將其應用到生產環境，***，對大公司而言是需要公司整體進行調整，不僅僅是技術本身，還有配套的組織結構、管理制度與流程相結合；第二，Docker本身的網絡、存儲、監控等技術領域的關鍵問題還需要進一步的驗證和實踐，才能夠將其應用到相應的生產環境。第三，生產環境的安全等級（包括穩定性要求），也是根據不同的業務等級會有不同的要求，一些低等級的生產環境，使用Docker是沒有任何問題的。

　　InfoQ：那在應用Docker后，你們內部在組織結構、管理制度上做了怎么樣的調整？

　　王延炯：在開發測試過程中，相關團隊經常會找運維團隊分配一些開發機、測試機。而分配主機只是***步，相伴而來的還有一些配置工作，例如運行期所需要的域名等等。

　　當然，除了Docker之外，如果用KVM、Xen等虛擬化技術，也可以實現分配。但需要注意的是，使用虛擬化技術所分配出來的主機資源，基本上要比使用Docker技術分配出來的主機資源少一個數量級，甚至更多。最直觀的感受就是，在相同物理宿主機條件下，可以分配更多的“主機”了。這樣給軟件交付所帶來的好處（這也是Docker所倡導的）是一個容器內只運行一個進程。每個應用系統，縱向前后臺分離、橫向多實例負載聚合，運行期的每個實例都可以不受干擾的運行在一個獨立的環境之中。

　　初看這只是一個量變的過程，但到一定程度就變成了質變，相同大小的運維團隊所要維護的“主機”數，可能就多了一個數量級。所以使用Docker之后，在組織結構和管理制度上，運維團隊只要在平臺層面提供Docker資源池，由各個項目的開發，或者測試負責人，自行在資源池內分配主機資源。所有動作都在Web界面完成，并且有簡單的工作流審批，減少資源濫用。

　　InfoQ：你們的Docker應用場景是怎么樣的？能介紹下你們所使用的技術棧嗎？

　　王延炯：關于Docker應用場景，目前各個技術團隊都根據自身的特點進行應用，大體上主要將Docker應用于開發、測試環境，不同的場景使用的技術棧也有區別。

　　在開發測試環境會使用SaltStack等技術對容器進行集中化管理，其主要使用方式較為傳統，主要為開發測試人員提供主機（操作系統）級服務，這與整個團體的軟件研發過程息息相關。

　　在SCM/CI平臺，有相當大一部分開源工具已經由社區實現了Docker化，能夠方便的將代碼與數據分離，使得平臺能夠進行快速升級、二次開發與定制。

　　在細節方面，諸如IP地主與主機名、IP地址（DHCP）與域名都進行了一定程度的二次開發與集成，目前可以實現Docker容器實例、主機名、域名綁定的Web端一鍵式自助分配與注冊。

　　InfoQ：可否詳細聊聊你們基于Docker的workflow嗎？

　　王延炯：關于Docker的workflow，如之前提到的，有基于Web端的一鍵式主機（也就是Docker容器）分配平臺，支持開發、測試環境的主機自動創建、IP分配、域名綁定，并包含與組織結構的審批流程。

　　另外，在我團隊所使用的Docker環境中，會將Docker與Jenkins/GitLab等平臺工具相結合，一方面將代碼固化至Docker鏡像中，一方面將配置文件作為數據分離到鏡像之外。這樣做的好處是，在一些無狀態的業務邏輯服務中，往往只需要『代碼+環境配置』，就可以部署到不同的運行環境中。例如同一份代碼，與不同的開發、功能測試、性能測試環境配置相結合（docker -v參數），就能夠快速部署相應的服務實例，并且可以與Docker自帶的restful接口做集成，甚至是使用IntelliJ 14.1的Docker插件，能夠做到從IDE到目標環境的一鍵式快速發布與部署。需要注意的是，這樣做需要把程序的所有配置做盡可能地集中化處理，并且以Key-Value格式，降低錯誤幾率。

　　InfoQ：Docker有很多的坑，你們的應用過程中是不是也遇到了？可以和大家分享下你印象深刻的幾個坑嗎？

　　王延炯：Docker的坑，在實際最多的還是集中于網絡。大多數的使用場景，還是需要解決容器在不同的宿主機之間的可達性，這是決定Docker應用范圍的***步。簡單的使用端口映射，往往不能夠解決運行期的端口動態監聽和容器間互聯。

　　另外，Docker的性能監控，也是決定Docker應用于什么樣等級的業務系統的關鍵因素，這也是近期除了網絡之外主要深耕的一個領域。目前還沒有對Docker進行代碼級的優化和hack，側重點還是在團隊的整體運行效率、軟件過程效率、業務持續交付中。

　　InfoQ：Docker最適合微服務架構的應用，像傳統非互聯網公司的IT系統，應該很多應用都不是這樣的架構。你們是如何過渡和應用的？有什么好的經驗分享嗎？

　　王延炯：首先，我們要回想一下到底什么是微服務或者叫微應用。我個人認為所謂微服務或者微應用，尤其在傳統重業務的非互聯網領域，其定位應當是一些非核心系統，或者是一些業務創新驅動的服務或應用，或者是一些架構于核心系統之上的組合、集成性質的輕應用。在技術層面，他們的特征是代碼量小，隨著業務快速變化可以迅速升級。而相對的，大平臺不僅僅是指一個技術平臺，廣義上應當是一個以各種技術標準進行兼容和統一為基礎，并提供多類型的業務平臺，需要有效、高效支撐上層的微應用和微服務的繁衍。隨著時間的推移和業務的發展，一些微服務、微應用，可以被吸收、沉淀至大平臺中，發揮更大的作用。

　　其次，對于傳統公司而言，我并不建議為了追求新鮮的技術而一定要向Docker之類的『時鮮平臺』進行遷移，保障復雜業務的穩定性才是重中之重。像Docker之類的新技術，可以采取『農村包圍城市』的策略，先在外部非核心系統試點，根據企業自身的開發、測試、運維的特點，積累和沉淀出一套適合自己的平臺的方法經驗論，當然其指導原則就是高效可靠。需要注意的是這個過程可能是漫長的，需要技術主導，也需要組織保障。

　　第三，我們可以發現，就Docker技術本身而言，它提供的是一個輕量級的容器，并沒有集成每個企業所確立的容器基礎設施基線。而企業的基礎鏡像一般只是一個操作系統級的容器（公有社區的Registry，不在此討論范圍之內），在此基礎之上，我們可以在Dockerfile里面，透明的定義具體應用或者服務所需要的本地運行環境（例如JDK、Node.js、Python等等），加之以具體的服務、應用，在運行期形成一個服務或應用的實例。。

　　第四，從企業架構而言，一個服務或者應用往往需要其它中間件的支持（如數據庫、緩存、分布式文件系統），也需要集群高可用的部署。這就牽扯到集群拓撲（有靜態也有動態的），包括縱向的從上層應用到底層的硬件物理設施，橫向的多實例負載均衡與備份。一個完備的企業級容器平臺，還需要有實時的監控和管理手段來輔助。Docker本身，并不提供這些企業級運維工具或者來支撐，都需要基于開源工具進行集成和定制開發。

　　可以看到，把以上所有問題都解決了，對于傳統企業，尤其是傳統非互聯網大型企業，Docker的大范圍推廣才具備可行性。Docker是否在企業里能夠推廣，用短板模型來衡量的話，這個短板應該是在運維團隊，并不是在開發團隊。

　　受訪嘉賓介紹

　　王延炯博士，畢業于北京郵電大學網絡與交換技術國家重點實驗室。現任平安健康互聯網技術平臺資深架構師，關注企業互聯網化過程中的軟件平臺技術路線。曾先后于西門子中國研究院、普元信息擔任資深架構師，期間專注于內存計算、大數據實時分析平臺的產品架構設計工作；參與并主持了十余項三大電信運營商、中國銀聯、中國登記上海公司等行業領軍企業的平臺軟件架構設計。