從去年底開始，攜程開始計劃把Docker引入到攜程的云平臺，這是系統(tǒng)研發(fā)部一部分的工作任務，攜程系統(tǒng)研發(fā)部的架構(gòu)師李任現(xiàn)在就在協(xié)同研發(fā)部從事Docker引入的工作。
　　攜程的Docker實踐是怎樣的？以下正文給你答案：
　　容器對攜程的價值
　　為什么要在攜程內(nèi)部推容器？肯定是想獲得容器帶來的好處。公共的好處大家都會知道，但有一個可能是攜程特有的痛點，因為攜程有大量的應用是部署在Windows上，因此攜程也很希望將來Windows的容器會給它們帶來一些提高和幫助。
　　目前攜程為容器在內(nèi)部的推動制訂了一些路線圖。攜程希望盡量以虛擬機的方式來運行容器，這主要是考慮到它帶來的優(yōu)點是對現(xiàn)有的應用和體系的影響小，攜程希望盡量以平滑的方式過度到容器中。但是，目前在推廣上會有一個困難，大家會在你推銷它的時候質(zhì)疑，因為改變很小意味著帶來容器特殊的優(yōu)勢很少。而這個確實是它的缺點。另外目前在攜程內(nèi)部主要是通過 OpenStack來管理云架構(gòu)的基礎(chǔ)設施。
　　攜程部署Docker的架構(gòu)
　　
　　圖一
　　圖一是攜程目前第一階段部署容器的架構(gòu)，它選擇了一個比較簡單的切入點，通過Nova Docker Driver做一些改造來管理容器的生命周期。本身容器的調(diào)度、管理和在OpenStack上用管理虛擬機是一樣的。圖一最上面的Remedy是攜程內(nèi)部的流程管理系統(tǒng)，它會通過一些接口去訪問OpenStack 的整個controller的API。
　　因為攜程早期是Windows，所以有很多VMWare的虛擬機，它們有專門針對EXSi的nova compute節(jié)點，圖一右邊是KVM的計算節(jié)點。引入Docker實際上是在這個架構(gòu)里面增加了一個新的節(jié)點類型，即專門跑容器的Docker的一個節(jié)點。
　　
　　圖二
　　除了容器本身生命周期之外，網(wǎng)絡的架構(gòu)復用了現(xiàn)在OpenStack管理網(wǎng)絡的方式。前面是計算資源的架構(gòu)，同時也用OpenStack對網(wǎng)絡進行管理?；旧先萜鞯木W(wǎng)絡使用方式和虛擬機在OpenStack里使用網(wǎng)絡的方式是很一致的。
　　圖二是一個容器的網(wǎng)絡圖，可以看到一個Docker容器有一對veth的設備。一個在它自己的namespace里面，一個加入到OVS bridge里面，如果這等同于虛擬機的話，下面就是虛擬機的tap設備，之后就和虛擬機網(wǎng)絡的PaaS是一樣的。通過這個bridge 連到internal 的bridge，右邊是出口的 bridge ，中間會做vlanid轉(zhuǎn)換，這樣可以接到系統(tǒng)的二層網(wǎng)絡里面去。這個是經(jīng)典的VLAN模型。
　　Docker容器運行
　　攜程Docker的容器的運行為了盡可能的討好用戶，更容易讓他們接受，現(xiàn)在是以虛擬機的模式進行。在應用部署方面跟現(xiàn)在虛擬機部署一樣，拿到一個容器之后通過現(xiàn)在的發(fā)布系統(tǒng)部署進去。因為是高度接近虛擬機的環(huán)境，所以對于應用的發(fā)布系統(tǒng)，用戶基本上感知不到。
　　現(xiàn)在攜程內(nèi)部虛擬機的發(fā)行版，主要以CentOS6.4為主，但是他們也開始遷移到CentOS7.1，所以攜程在Docker容器上支持這兩個發(fā)行版。以前的虛擬機的方式會導致運維的人上去可能要做很多運維的工作，所以要考慮到權(quán)限問題。但有些權(quán)限很危險不能給他們，否則會造成很多問題。比如sys_boot，它在里面可以將宿主機重啟，如果你把sys_boot給出去的話，這個是很可怕的。
　　鏡像有很多種方式，而攜程現(xiàn)在選的方式是有一定歷史原因的。因為攜程OPS有一套基礎(chǔ)的環(huán)境規(guī)范。為了讓ops原有的設施能繼續(xù)工作，這個環(huán)境要盡可能演示。但悲劇的是，它沒有一個很精確的代碼能去描述環(huán)境是怎么樣的，而只能用一個做好的自動安裝的光環(huán)去抓取到環(huán)境。所以當時攜程選擇直接把自己的虛擬機的鏡像拉過來，然后從虛擬機QCOW2的鏡像去踩點至Docker的鏡像。
　　攜程以虛擬機的方式運行，它運行起來不是很正統(tǒng)的只有一個進程的容器的方式。攜程在一個容器里面起了很多進程，而進程像虛擬機一樣需要有個初始的守護進程，所以攜程也需要這樣的守護進程。守護進程很多，而守護進程該如何選擇？如果大家看過相關(guān)文章的話，有很多的討論。除了目前已有的守護進程外也涌現(xiàn)著很多新的守護進程。但是比較悲劇的一點，攜程還有一個運用規(guī)范，運用規(guī)范規(guī)定了啟動服務，在CentOS7.1下一下子很難撼動他們的地位，只能向他們靠攏。
　　另外，如果容器里面Cgroup這個文件系統(tǒng)是可讀的，這也意味著在容器里面，分到的CPU內(nèi)存資源可以隨意改變，這個可能在公有云計算是不可接受的事情，但是私有云里面目前只能這樣。
　　還有很重要的一點是網(wǎng)絡。前面說到攜程網(wǎng)絡是和OpenStack的那套網(wǎng)絡管理一樣的方案，其實它有很多手段來實現(xiàn)這些。目前因為攜程用novadocker，順便說一下novadocker 常不靠譜，沒法用。攜程以前與京東交流，他們給攜程出的建議第一句話就是不要用novadocker。novadocker采用的方式，其實和pipework是很類似的，也就是它把容器運行起來，然后進去，通過執(zhí)行一些命令，再配上網(wǎng)絡。但它有一個問題，其實容器在啟動到配上虛擬的網(wǎng)卡，這個過程其實是有一段時間的。
　　攜程用systemd，而它啟動是很快的，這就意味著，有一些服務起來的時候，后面需要配套網(wǎng)絡，如果你的應用對于這個是有依賴的就會問題。另外，這個網(wǎng)絡的配置信息Docker是不可見的，這意味著Docker不知道這段網(wǎng)絡配置。如果Docker daemon把容器重啟的話，它是沒辦法恢復網(wǎng)絡配置的，這個是很嚴重的一個問題。比如到了1.9之后，支持libnetwork做網(wǎng)絡的配置。這樣就不會有前面丟失網(wǎng)絡信息的問題。攜程現(xiàn)在還是用novadocker 的方式，本來打算用libnetwork，但是很悲摧的是，上線之前，攜程一直使用Ubuntu，后來臨上線，到生產(chǎn)的時候，運維說，他們希望統(tǒng)一宿主機版本全部用CentOS。最后沒辦法，只能把Netron agent這些東西全放到容器里面跑，再跑 novadocker等。
　　Docker監(jiān)控
　　前面部署其實只是解決了實例運行的一些問題。運維的人的支撐對于一個真的能運營的產(chǎn)品很重要，所以對于Docker來說，假如真正要上業(yè)務，監(jiān)控是很重要的一個話題。
　　攜程一般在Linux上監(jiān)控數(shù)據(jù)，大多數(shù)是來自proc文件系統(tǒng)，proc文件系統(tǒng)在Docker容器里面，我們知道Docker容器做隔離其實提供namespace ，對于PID做得很好的namespace ，這個沒有問題，網(wǎng)絡統(tǒng)計也是很準確的。但是很多很關(guān)鍵的CPU、內(nèi)存使用這些在proc系統(tǒng)里是看宿主機。還有一些監(jiān)控的系統(tǒng)比如sysinfo sysconf這些是沒有任何的秘密空間提供的。所以這些數(shù)據(jù)來源是很成問題的。
　　對于Docker來說，我們監(jiān)控該怎么辦？其實現(xiàn)在有一些方式，比如說在宿主上監(jiān)控所跑的容器現(xiàn)在也有方案，比如說Docker很早就提供了stats命令，可以看到每一個容器的讀數(shù)，包括跨設備網(wǎng)絡。還有一些比如像cAdvisor方案。為什么會看這個？因為在攜程用的方式是zabbix，每個虛擬機里面都跑zabbix。這種方式是在宿主機上。但是下面每個虛擬機的監(jiān)控數(shù)據(jù)對于攜程來說，其實與現(xiàn)有的監(jiān)控的方案不是非常的匹配，因為他們希望能夠看到每個虛擬機單個作為一個的對象，能看到它的監(jiān)控數(shù)據(jù)，而不是在宿主機上看到下面那些掛的。包括監(jiān)控、告警這些都是有關(guān)聯(lián)的。所以這些方式其實跟現(xiàn)有的監(jiān)控的方案是有整合的成本在里面的。
　　如果想盡量減少修改，還有一種是容器內(nèi)部監(jiān)控它。之前聽蘑菇街的分享，他們直接把監(jiān)控工具改掉。還有一個是很多人很關(guān)心的一個項目，它基本的原理用了files文件系統(tǒng)，實現(xiàn)了對proc文件系統(tǒng)的代理，它幫你代理、修改proc文件系統(tǒng)的訪問，把數(shù)字計算一下獲得一個正確的。正確的數(shù)據(jù)其實都是從cgroup里面讀出來的。
　　這個方式解決了這個問題之后。我們可以在容器內(nèi)部獲得正確的監(jiān)控數(shù)據(jù)，包括啟動時間，上線后怎么登進去了，怎么看到這個容器給它分配的資源是多少。一看宿主機48，怎么分了這么多給它？但是還是有一些問題，比如前面改內(nèi)核者或者改工具，維護這些改動的成本在里面，還有一些部署。所以也有一些問題。
　　后來攜程想到另外一種折中的方式。這個方式是說，它們通過用Linux的Id prelod的機制，劫持對proc文件的訪問，真正需要獲得的數(shù)據(jù)是參考IXCFS的實現(xiàn)，重新計算一下，也是通過從cgroup里面計算你分配了多少內(nèi)存，使用了多少，CPU是怎樣的，去計算的一個資源。當然CPU load挺麻煩的，需要額外支持。