---------------------以下是原文----------------------
從去年底開始，攜程開始計畫把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的映象。
另外，如果容器裡面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也是對攜程影響很大的乙個技術。另外如何進一步獲得更高的的資源調動，如何動態的排程這些資源也是攜程需要關注的地方，所以接下來攜程還會有很多事情要做。 官網。
使用docker映象搭建攜程apollo系統
apollo的作用及原理不在陳述,直接進入正題乾貨搭建部分 或者從 提取碼 xbkp 第二步 執行sql sql目錄 存放位置 apollo master scripts docker quick start sql 第三步 編譯原始碼 找到路徑 存放位置 apollo master scripts...
攜程App的網路效能優化實踐
native模組是攜程的核心業務模組 酒店 機票 火車票 攻略等 native模組的網路服務主要通過tcp連線實現，而非常見的restful http api那種http連線，只有少數輕量級服務使用http介面作為補充。tcp連線網路服務模組使用了長連線 短連線機制，即有乙個長連線池保持一定數目長連...
攜程App的網路效能優化實踐
摘要 native模組是攜程的核心業務模組 酒店 機票 火車票 攻略等 native模組的網路服務主要通過tcp連線實現，而非常見的restful http api那種http連線，只有少數輕量級服務使用http介面作為補充。tcp連線網路服務模組使用了長連線 短連線機制，即有乙個長連線池保持一定數...