原文地址：http://www.iteye.com/news/31468? ? ? ? ?請點擊原文閱讀

---------------------以下是原文----------------------

從去年底開始，攜程開始計劃把Docker引入到攜程的云平臺，這是系統研發部一部分的工作任務，攜程系統研發部的架構師李任現在就在協同研發部從事Docker引入的工作。?

攜程的Docker實踐是怎樣的？以下正文給你答案：?

容器對攜程的價值?
為什么要在攜程內部推容器？肯定是想獲得容器帶來的好處。公共的好處大家都會知道，但有一個可能是攜程特有的痛點，因為攜程有大量的應用是部署在Windows上，因此攜程也很希望將來Windows的容器會給它們帶來一些提高和幫助。?

目前攜程為容器在內部的推動制訂了一些路線圖。攜程希望盡量以虛擬機的方式來運行容器，這主要是考慮到它帶來的優點是對現有的應用和體系的影響小，攜程希望盡量以平滑的方式過度到容器中。但是，目前在推廣上會有一個困難，大家會在你推銷它的時候質疑，因為改變很小意味著帶來容器特殊的優勢很少。而這個確實是它的缺點。另外目前在攜程內部主要是通過 OpenStack來管理云架構的基礎設施。?

攜程部署Docker的架構?

圖一是攜程目前第一階段部署容器的架構，它選擇了一個比較簡單的切入點，通過Nova Docker Driver做一些改造來管理容器的生命周期。本身容器的調度、管理和在OpenStack上用管理虛擬機是一樣的。圖一最上面的Remedy是攜程內部的流程管理系統，它會通過一些接口去訪問OpenStack 的整個controller的API。?

因為攜程早期是Windows，所以有很多VMWare的虛擬機，它們有專門針對EXSi的nova compute節點，圖一右邊是KVM的計算節點。引入Docker實際上是在這個架構里面增加了一個新的節點類型，即專門跑容器的Docker的一個節點。?



除了容器本身生命周期之外，網絡的架構復用了現在OpenStack管理網絡的方式。前面是計算資源的架構，同時也用OpenStack對網絡進行管理。基本上容器的網絡使用方式和虛擬機在OpenStack里使用網絡的方式是很一致的。?

圖二是一個容器的網絡圖，可以看到一個Docker容器有一對veth的設備。一個在它自己的namespace里面，一個加入到OVS bridge里面，如果這等同于虛擬機的話，下面就是虛擬機的tap設備，之后就和虛擬機網絡的PaaS是一樣的。通過這個bridge 連到internal 的bridge，右邊是出口的 bridge ，中間會做vlanid轉換，這樣可以接到系統的二層網絡里面去。這個是經典的VLAN模型。?

Docker容器運行 ?
攜程Docker的容器的運行為了盡可能的討好用戶，更容易讓他們接受，現在是以虛擬機的模式進行。在應用部署方面跟現在虛擬機部署一樣，拿到一個容器之后通過現在的發布系統部署進去。因為是高度接近虛擬機的環境，所以對于應用的發布系統，用戶基本上感知不到。?

現在攜程內部虛擬機的發行版，主要以CentOS6.4為主，但是他們也開始遷移到CentOS7.1，所以攜程在Docker容器上支持這兩個發行版。以前的虛擬機的方式會導致運維的人上去可能要做很多運維的工作，所以要考慮到權限問題。但有些權限很危險不能給他們，否則會造成很多問題。比如sys_boot，它在里面可以將宿主機重啟，如果你把sys_boot給出去的話，這個是很可怕的。?

鏡像有很多種方式，而攜程現在選的方式是有一定歷史原因的。因為攜程OPS有一套基礎的環境規范。為了讓ops原有的設施能繼續工作，這個環境要盡可能演示。但悲劇的是，它沒有一個很精確的代碼能去描述環境是怎么樣的，而只能用一個做好的自動安裝的光環去抓取到環境。所以當時攜程選擇直接把自己的虛擬機的鏡像拉過來，然后從虛擬機QCOW2的鏡像去踩點至Docker的鏡像。?

攜程以虛擬機的方式運行，它運行起來不是很正統的只有一個進程的容器的方式。攜程在一個容器里面起了很多進程，而進程像虛擬機一樣需要有個初始的守護進程，所以攜程也需要這樣的守護進程。守護進程很多，而守護進程該如何選擇？如果大家看過相關文章的話，有很多的討論。除了目前已有的守護進程外也涌現著很多新的守護進程。但是比較悲劇的一點，攜程還有一個運用規范，運用規范規定了啟動服務，在CentOS7.1下一下子很難撼動他們的地位，只能向他們靠攏。?

另外，如果容器里面Cgroup這個文件系統是可讀的，這也意味著在容器里面，分到的CPU內存資源可以隨意改變，這個可能在公有云計算是不可接受的事情，但是私有云里面目前只能這樣。?

還有很重要的一點是網絡。前面說到攜程網絡是和OpenStack的那套網絡管理一樣的方案，其實它有很多手段來實現這些。目前因為攜程用novadocker，順便說一下novadocker 常不靠譜，沒法用。攜程以前與京東交流，他們給攜程出的建議第一句話就是不要用novadocker。novadocker采用的方式，其實和pipework是很類似的，也就是它把容器運行起來，然后進去，通過執行一些命令，再配上網絡。但它有一個問題，其實容器在啟動到配上虛擬的網卡，這個過程其實是有一段時間的。?

攜程用systemd，而它啟動是很快的，這就意味著，有一些服務起來的時候，后面需要配套網絡，如果你的應用對于這個是有依賴的就會問題。另外，這個網絡的配置信息Docker是不可見的，這意味著Docker不知道這段網絡配置。如果Docker daemon把容器重啟的話，它是沒辦法恢復網絡配置的，這個是很嚴重的一個問題。比如到了1.9之后，支持libnetwork做網絡的配置。這樣就不會有前面丟失網絡信息的問題。攜程現在還是用novadocker 的方式，本來打算用libnetwork，但是很悲摧的是，上線之前，攜程一直使用Ubuntu，后來臨上線，到生產的時候，運維說，他們希望統一宿主機版本全部用CentOS。最后沒辦法，只能把Netron agent這些東西全放到容器里面跑，再跑 novadocker等。?

Docker監控 ?
前面部署其實只是解決了實例運行的一些問題。運維的人的支撐對于一個真的能運營的產品很重要，所以對于Docker來說，假如真正要上業務，監控是很重要的一個話題。?

攜程一般在Linux上監控數據，大多數是來自proc文件系統，proc文件系統在Docker容器里面，我們知道Docker容器做隔離其實提供namespace ，對于PID做得很好的namespace ，這個沒有問題，網絡統計也是很準確的。但是很多很關鍵的CPU、內存使用這些在proc系統里是看宿主機。還有一些監控的系統比如sysinfo sysconf這些是沒有任何的秘密空間提供的。所以這些數據來源是很成問題的。?

對于Docker來說，我們監控該怎么辦？其實現在有一些方式，比如說在宿主上監控所跑的容器現在也有方案，比如說Docker很早就提供了stats命令，可以看到每一個容器的讀數，包括跨設備網絡。還有一些比如像cAdvisor方案。為什么會看這個？因為在攜程用的方式是zabbix，每個虛擬機里面都跑zabbix。這種方式是在宿主機上。但是下面每個虛擬機的監控數據對于攜程來說，其實與現有的監控的方案不是非常的匹配，因為他們希望能夠看到每個虛擬機單個作為一個的對象，能看到它的監控數據，而不是在宿主機上看到下面那些掛的。包括監控、告警這些都是有關聯的。所以這些方式其實跟現有的監控的方案是有整合的成本在里面的。?

如果想盡量減少修改，還有一種是容器內部監控它。之前聽蘑菇街的分享，他們直接把監控工具改掉。還有一個是很多人很關心的一個項目，它基本的原理用了files文件系統，實現了對proc文件系統的代理，它幫你代理、修改proc文件系統的訪問，把數字計算一下獲得一個正確的。正確的數據其實都是從cgroup里面讀出來的。?

這個方式解決了這個問題之后。我們可以在容器內部獲得正確的監控數據，包括啟動時間，上線后怎么登進去了，怎么看到這個容器給它分配的資源是多少。一看宿主機48，怎么分了這么多給它？但是還是有一些問題，比如前面改內核者或者改工具，維護這些改動的成本在里面，還有一些部署。所以也有一些問題。?

后來攜程想到另外一種折中的方式。這個方式是說，它們通過用Linux的Id prelod的機制，劫持對proc文件的訪問，真正需要獲得的數據是參考IXCFS的實現，重新計算一下，也是通過從cgroup里面計算你分配了多少內存，使用了多少，CPU是怎樣的，去計算的一個資源。當然CPU load挺麻煩的，需要額外支持。?



圖三中有個例子。可以看到，這個容器里面，用了劫持的方案計算了之后，可以看到大概分了兩個G的內存。把環境變量去掉之后，看這個宿主機，大概一百多個G的內存。它的工作方式，比如說，如果是free，就是命令，它真正在運行的時候，會有Id so init去加載二進制文件的時候，會先加載我們的so 文件，它會把真正的open庫的實現給劫持掉。到這里是一個標準的劫持的過程。?

之后free讀文件的內存信息的時候，它其實讀的是/proc/meminfo文件，劫持過來的時候，真正的邏輯到so文件里面，它讀這個文件知道是干什么。實際上它讀cgroup和lxcfs是一樣的，計算然后把它保存到一個臨時文件里面去。最后返回的是這個臨時文件fd，Free會讀這個臨時文件。原理就是這樣的。?

其實攜程在容器上還有很多事情要做。比如說，不光是為交付給用戶的計算環境提供容器，其實想把自己的一些很多東西都放到容器上去。比如攜程的OpenStack平臺也想跑到Docker里面去，因為OpenStack很復雜，部署起來也是件很頭疼的事情。?

現在攜程是用虛擬機的方式跑容器，其實是很重的。所以也想直接基于鏡像的方式來應用持續交付。這就牽涉到很多東西，包括調度，打包，各種系統，包括進項的版本管理等。?

將來的微軟的windows Container也是對攜程影響很大的一個技術。另外如何進一步獲得更高的的資源調動，如何動態的調度這些資源也是攜程需要關注的地方，所以接下來攜程還會有很多事情要做。?

本文是攜程系統研發部的架構師李任日前在「七牛云主辦的架構師實踐日——容器核心技術與最佳實踐」的演講內容整理。PPT、速記和現場演講視頻等參見“七牛架構師實踐日” 官網 。