關于攜程Docker的實踐分析
大小：0.4 MB 人氣： 2017-10-11 需要積分：1
攜程的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挺麻煩的，需要額外支持。
非常好我支持^.^
(0) 0%
不好我反對
(0) 0%