建站
咨詢
售后
建站咨詢
新聞中心
云計(jì)算 前端 作為一個(gè)開(kāi)發(fā)，每天總少不了要出N個(gè)測(cè)試版本進(jìn)行調(diào)試，容器化以后每次出版本都需要打成鏡像，老劉發(fā)現(xiàn)每次他做一個(gè)鏡像都要20分鐘，而小王只要10分鐘，對(duì)比來(lái)對(duì)比去只有這個(gè)東西不一樣!
創(chuàng)新互聯(lián)主要為客戶提供服務(wù)項(xiàng)目涵蓋了網(wǎng)頁(yè)視覺(jué)設(shè)計(jì)、VI標(biāo)志設(shè)計(jì)、成都全網(wǎng)營(yíng)銷(xiāo)推廣、網(wǎng)站程序開(kāi)發(fā)、HTML5響應(yīng)式網(wǎng)站建設(shè)公司、成都手機(jī)網(wǎng)站制作、微商城、網(wǎng)站托管及成都網(wǎng)站改版、WEB系統(tǒng)開(kāi)發(fā)、域名注冊(cè)、國(guó)內(nèi)外服務(wù)器租用、視頻、平面設(shè)計(jì)、SEO優(yōu)化排名。設(shè)計(jì)、前端、后端三個(gè)建站步驟的完善服務(wù)體系。一人跟蹤測(cè)試的建站服務(wù)標(biāo)準(zhǔn)。已經(jīng)為成都鑿毛機(jī)行業(yè)客戶提供了網(wǎng)站營(yíng)銷(xiāo)推廣服務(wù)。
隨著全面云時(shí)代到來(lái)，很多公司都走上了容器化道路，老劉所在的公司也不例外。作為一家初創(chuàng)型的互聯(lián)網(wǎng)公司，容器化的確帶來(lái)了很多便捷，也降低了公司成本，不過(guò)老劉卻有一個(gè)苦惱，以前每天和他一起下班的小王自從公司上云以后每天都比他早下班一個(gè)小時(shí)，大家手頭上的活都差不多，講道理不應(yīng)該呀，經(jīng)過(guò)多番試探、跟蹤、調(diào)查，終于讓老劉發(fā)現(xiàn)了秘密的所在。
作為一個(gè)開(kāi)發(fā)，每天總少不了要出N個(gè)測(cè)試版本進(jìn)行調(diào)試，容器化以后每次出版本都需要打成鏡像，老劉發(fā)現(xiàn)每次他做一個(gè)鏡像都要20分鐘，而小王只要10分鐘，對(duì)比來(lái)對(duì)比去只有這個(gè)東西不一樣!
Storage-Dirver到底是何方神圣?為什么能夠?qū)е聵?gòu)建時(shí)間上的差異?現(xiàn)在讓我們來(lái)一窺究竟。
在回答這個(gè)問(wèn)題之前我們需要先回答三個(gè)問(wèn)題——什么是鏡像?什么是鏡像構(gòu)建?什么是storage-driver?
什么是鏡像?
說(shuō)到鏡像就繞不開(kāi)容器，我們先看一張來(lái)自官方對(duì)鏡像和容器解釋的圖片：
看完以后是不是更疑惑了，我們可以這樣簡(jiǎn)單粗暴的去理解，鏡像就是一堆只讀層的堆疊。那只讀層里到底是什么呢，另外一個(gè)簡(jiǎn)單粗暴的解釋?zhuān)豪镞吘褪欠帕艘欢驯桓膭?dòng)的文件。這個(gè)解釋在不同的storage-driver下不一定準(zhǔn)確但是我們可以先這樣簡(jiǎn)單去理解。
那不對(duì)呀，執(zhí)行容器的時(shí)候明明是可以去修改刪除容器里的文件的，都是只讀的話怎么去修改呢?實(shí)際上我們運(yùn)行容器的時(shí)候是在那一堆只讀層的頂上再增加了一個(gè)讀寫(xiě)層，所有的操作都是在這個(gè)讀寫(xiě)層里進(jìn)行的，當(dāng)需要修改一個(gè)文件的時(shí)候我們會(huì)將需要修改的文件從底層拷貝到讀寫(xiě)層再進(jìn)行修改。那如果是刪除呢，我們不是沒(méi)有辦法刪除底層的文件么?沒(méi)錯(cuò)，確實(shí)沒(méi)有辦法刪除，但只需要在上層把這個(gè)文件隱藏起來(lái)，就可以達(dá)到刪除的效果。按照官方說(shuō)法，這就是Docker的寫(xiě)時(shí)復(fù)制策略。
為了加深大家對(duì)鏡像層的理解我們來(lái)舉個(gè)栗子，用下面的Dockerfile構(gòu)建一個(gè)etcd鏡像：
構(gòu)建完成以后生成了如下的層文件：
每次進(jìn)入容器的時(shí)候都感覺(jué)仿佛進(jìn)入了一臺(tái)虛機(jī)，里面包含linux的各個(gè)系統(tǒng)目錄。那是不是有一層目錄里包含了所有的linux系統(tǒng)目錄呢?
bingo答對(duì)!在***層的層目錄的確包含了linux的所有的系統(tǒng)目錄文件。
上述Dockerfile中有這樣一步操作
- ADD . /go/src/github.com/coreos/etcd
將外面目錄的文件拷到了鏡像中，那這一層鏡像里究竟保存了什么呢?
打開(kāi)發(fā)現(xiàn)里面就只有
- /go/src/github.com/coreos/etcd這個(gè)目錄，目錄下存放了拷貝進(jìn)來(lái)的文件。
到這里是不是有種管中窺豹的感覺(jué)，接下來(lái)我們?cè)賮?lái)了解什么是鏡像構(gòu)建，這樣基本上能夠窺其全貌了。
什么是鏡像構(gòu)建?
通過(guò)***節(jié)的內(nèi)容我們知道了鏡像是由一堆層目錄組成的，每個(gè)層目錄里放著這一層修改的文件，鏡像構(gòu)建簡(jiǎn)單的說(shuō)就是制作和生成鏡像層的過(guò)程，那這一過(guò)程是如何實(shí)現(xiàn)的呢?以下圖流程為例：
Docker Daemon首先利用基礎(chǔ)鏡像ubuntu:14.04創(chuàng)建了一個(gè)容器環(huán)境，通過(guò)***節(jié)的內(nèi)容我們知道容器的最上層是一個(gè)讀寫(xiě)層，在這一層我們是可以寫(xiě)入修改的，Docker Daemon首先執(zhí)行了RUN apt-update get命令，執(zhí)行完成以后，通過(guò)Docker的commit操作將這個(gè)讀寫(xiě)層的內(nèi)容保存成一個(gè)只讀的鏡像層文件。接下來(lái)再在這一層的基礎(chǔ)上繼續(xù)執(zhí)行 ADD run.sh命令，執(zhí)行完成后繼續(xù)commit成一個(gè)鏡像層文件，如此反復(fù)直到將所有的Dockerfile都命令都被提交后，鏡像也就做好了。
這里我們就能解釋為什么etcd的某個(gè)層目錄里只有一個(gè)go目錄了，因?yàn)闃?gòu)建的過(guò)程是逐層提交的，每一層里只會(huì)保存這一層操作所涉及改動(dòng)的文件。
這樣看來(lái)鏡像構(gòu)建就是一個(gè)反復(fù)按照Dockerfile啟動(dòng)容器執(zhí)行命令并保存成只讀文件的過(guò)程，那為什么速度會(huì)不一樣呢?接下來(lái)就得說(shuō)到storage-driver了。
什么是storage-driver?
再來(lái)回顧一下這張圖：
之前我們已經(jīng)知道了，鏡像是由一個(gè)個(gè)的層目錄疊加起來(lái)的，容器運(yùn)行時(shí)只是在上面再增加一個(gè)讀寫(xiě)層，同時(shí)還有寫(xiě)時(shí)復(fù)制策略保證在最頂層能夠修改底層的文件內(nèi)容，那這些原理是怎么實(shí)現(xiàn)的呢?就是靠storage-driver!
簡(jiǎn)單介紹三種常用的storage-driver：
AUFS
AUFS通過(guò)聯(lián)合掛載的方式將多個(gè)層文件堆疊起來(lái)，形成一個(gè)統(tǒng)一的整體提供統(tǒng)一視圖，當(dāng)在讀寫(xiě)層進(jìn)行讀寫(xiě)的時(shí)，先在本層查找文件是否存在，如果沒(méi)有則一層一層的往下找。aufs的操作都是基于文件的，需要修改一個(gè)文件時(shí)無(wú)論大小都會(huì)將整個(gè)文件從只讀層拷貝到讀寫(xiě)層，因此如果需要修改的文件過(guò)大，會(huì)導(dǎo)致容器執(zhí)行速度變慢，docker官方給出的建議是通過(guò)掛載的方式將大文件掛載進(jìn)來(lái)而不是放在鏡像層中。
OverlayFS
OverlayFS可以認(rèn)為是AUFS的升級(jí)版本，容器運(yùn)行時(shí)鏡像層的文件是通過(guò)硬鏈接的方式組成一個(gè)下層目錄，而容器層則是工作在上層目錄，上層目錄是可讀寫(xiě)的，下層目錄是只讀的，由于大量的采用了硬鏈接的方式，導(dǎo)致OverlayFS會(huì)可能會(huì)出現(xiàn)inode耗盡的情況，后續(xù)Overlay2對(duì)這一問(wèn)題進(jìn)行了優(yōu)化，且性能上得到了很大的提升，不過(guò)Overlay2也有和AUFS有同樣的弊端——對(duì)大文件的操作速度比較慢。
DeviceMapper
DeviceMapper和前兩種Storage-driver在實(shí)現(xiàn)上存在很大的差異。首先DeviceMapper的每一層保存的是上一層的快照，其次DeviceMapper對(duì)數(shù)據(jù)的操作不再是基于文件的而是基于數(shù)據(jù)塊的。
下圖是devicemapper在容器層讀取文件的過(guò)程：
- 首先在容器層的快照中找到該文件指向下層文件的指針。
- 再?gòu)南聦?xf33位置指針指向的數(shù)據(jù)塊中讀取的數(shù)據(jù)到容器的存儲(chǔ)區(qū)
- ***將數(shù)據(jù)返回app。
在寫(xiě)入數(shù)據(jù)時(shí)還需要根據(jù)數(shù)據(jù)的大小先申請(qǐng)1~N個(gè)64K的容器快照，用于保存拷貝的塊數(shù)據(jù)。
DeviceMapper的塊操作看上去很美，實(shí)際上存在很多問(wèn)題，比如頻繁操作較小文件時(shí)需要不停地從資源池中分配數(shù)據(jù)庫(kù)并映射到容器中，這樣效率會(huì)變得很低，且DeviceMapper每次鏡像運(yùn)行時(shí)都需要拷貝所有的鏡像層信息到內(nèi)存中，當(dāng)啟動(dòng)多個(gè)鏡像時(shí)會(huì)占用很大的內(nèi)存空間。
針對(duì)不同的storage-driver我們用上述etcd的dockerfile進(jìn)行了一組構(gòu)建測(cè)試
注：該數(shù)據(jù)因dockerfile以及操作系統(tǒng)、文件系統(tǒng)、網(wǎng)絡(luò)環(huán)境的不同測(cè)試結(jié)果可能會(huì)存在較大差異
我們發(fā)現(xiàn)在該實(shí)驗(yàn)場(chǎng)景下DevivceMapper在時(shí)間上明顯會(huì)遜于AUFS和Overlay2，而AUFS和Overlay2基本相當(dāng)，當(dāng)然該數(shù)據(jù)僅能作為一個(gè)參考，實(shí)際構(gòu)建還受到具體的Dockerfile內(nèi)容以及操作系統(tǒng)、文件系統(tǒng)、網(wǎng)絡(luò)環(huán)境等多方面的影響，那要怎么樣才能盡量讓構(gòu)建時(shí)間最短提升我們的工作效率呢?
且看下回分解!
網(wǎng)頁(yè)名稱：容器化之路：誰(shuí)偷走了我的構(gòu)建時(shí)間
路徑分享：http://m.5511xx.com/article/cdogdoj.html
