關(guān)于攜程Docker的實(shí)踐分析

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