隨著全面云時代到來，很多公司都走上了容器化道路，老劉所在的公司也不例外。作為一家初創(chuàng)型的互聯(lián)網(wǎng)公司，容器化的確帶來了很多便捷，也降低了公司成本，不過老劉卻有一個苦惱，以前每天和他一起下班的小王自從公司上云以后每天都比他早下班一個小時，大家手頭上的活都差不多，講道理不應(yīng)該呀，經(jīng)過多番試探、跟蹤、調(diào)查，終于讓老劉發(fā)現(xiàn)了秘密的所在。

[[262139]]

作為一個開發(fā)，每天總少不了要出N個測試版本進(jìn)行調(diào)試，容器化以后每次出版本都需要打成鏡像，老劉發(fā)現(xiàn)每次他做一個鏡像都要20分鐘，而小王只要10分鐘，對比來對比去只有這個東西不一樣! 

Storage-Dirver到底是何方神圣?為什么能夠?qū)е聵?gòu)建時間上的差異?現(xiàn)在讓我們來一窺究竟。

在回答這個問題之前我們需要先回答三個問題——什么是鏡像?什么是鏡像構(gòu)建?什么是storage-driver?

什么是鏡像?

說到鏡像就繞不開容器，我們先看一張來自官方對鏡像和容器解釋的圖片： 

看完以后是不是更疑惑了，我們可以這樣簡單粗暴的去理解，鏡像就是一堆只讀層的堆疊。那只讀層里到底是什么呢，另外一個簡單粗暴的解釋：里邊就是放了一堆被改動的文件。這個解釋在不同的storage-driver下不一定準(zhǔn)確但是我們可以先這樣簡單去理解。

那不對呀，執(zhí)行容器的時候明明是可以去修改刪除容器里的文件的，都是只讀的話怎么去修改呢?實際上我們運行容器的時候是在那一堆只讀層的頂上再增加了一個讀寫層，所有的操作都是在這個讀寫層里進(jìn)行的，當(dāng)需要修改一個文件的時候我們會將需要修改的文件從底層拷貝到讀寫層再進(jìn)行修改。那如果是刪除呢，我們不是沒有辦法刪除底層的文件么?沒錯，確實沒有辦法刪除，但只需要在上層把這個文件隱藏起來，就可以達(dá)到刪除的效果。按照官方說法，這就是Docker的寫時復(fù)制策略。

為了加深大家對鏡像層的理解我們來舉個栗子，用下面的Dockerfile構(gòu)建一個etcd鏡像： 

構(gòu)建完成以后生成了如下的層文件： 

每次進(jìn)入容器的時候都感覺仿佛進(jìn)入了一臺虛機(jī)，里面包含linux的各個系統(tǒng)目錄。那是不是有一層目錄里包含了所有的linux系統(tǒng)目錄呢?

bingo答對!在***層的層目錄的確包含了linux的所有的系統(tǒng)目錄文件。 

上述Dockerfile中有這樣一步操作

ADD . /go/src/github.com/coreos/etcd 

將外面目錄的文件拷到了鏡像中，那這一層鏡像里究竟保存了什么呢? 

打開發(fā)現(xiàn)里面就只有

/go/src/github.com/coreos/etcd這個目錄，目錄下存放了拷貝進(jìn)來的文件。 

到這里是不是有種管中窺豹的感覺，接下來我們再來了解什么是鏡像構(gòu)建，這樣基本上能夠窺其全貌了。

什么是鏡像構(gòu)建?

通過***節(jié)的內(nèi)容我們知道了鏡像是由一堆層目錄組成的，每個層目錄里放著這一層修改的文件，鏡像構(gòu)建簡單的說就是制作和生成鏡像層的過程，那這一過程是如何實現(xiàn)的呢?以下圖流程為例： 

Docker Daemon首先利用基礎(chǔ)鏡像ubuntu:14.04創(chuàng)建了一個容器環(huán)境，通過***節(jié)的內(nèi)容我們知道容器的最上層是一個讀寫層，在這一層我們是可以寫入修改的，Docker Daemon首先執(zhí)行了RUN apt-update get命令，執(zhí)行完成以后，通過Docker的commit操作將這個讀寫層的內(nèi)容保存成一個只讀的鏡像層文件。接下來再在這一層的基礎(chǔ)上繼續(xù)執(zhí)行 ADD run.sh命令，執(zhí)行完成后繼續(xù)commit成一個鏡像層文件，如此反復(fù)直到將所有的Dockerfile都命令都被提交后，鏡像也就做好了。

這里我們就能解釋為什么etcd的某個層目錄里只有一個go目錄了，因為構(gòu)建的過程是逐層提交的，每一層里只會保存這一層操作所涉及改動的文件。

這樣看來鏡像構(gòu)建就是一個反復(fù)按照Dockerfile啟動容器執(zhí)行命令并保存成只讀文件的過程，那為什么速度會不一樣呢?接下來就得說到storage-driver了。

什么是storage-driver?

再來回顧一下這張圖： 

之前我們已經(jīng)知道了，鏡像是由一個個的層目錄疊加起來的，容器運行時只是在上面再增加一個讀寫層，同時還有寫時復(fù)制策略保證在最頂層能夠修改底層的文件內(nèi)容，那這些原理是怎么實現(xiàn)的呢?就是靠storage-driver!

簡單介紹三種常用的storage-driver：

AUFS

AUFS通過聯(lián)合掛載的方式將多個層文件堆疊起來，形成一個統(tǒng)一的整體提供統(tǒng)一視圖，當(dāng)在讀寫層進(jìn)行讀寫的時，先在本層查找文件是否存在，如果沒有則一層一層的往下找。aufs的操作都是基于文件的，需要修改一個文件時無論大小都會將整個文件從只讀層拷貝到讀寫層，因此如果需要修改的文件過大，會導(dǎo)致容器執(zhí)行速度變慢，docker官方給出的建議是通過掛載的方式將大文件掛載進(jìn)來而不是放在鏡像層中。 

OverlayFS

OverlayFS可以認(rèn)為是AUFS的升級版本，容器運行時鏡像層的文件是通過硬鏈接的方式組成一個下層目錄，而容器層則是工作在上層目錄，上層目錄是可讀寫的，下層目錄是只讀的，由于大量的采用了硬鏈接的方式，導(dǎo)致OverlayFS會可能會出現(xiàn)inode耗盡的情況，后續(xù)Overlay2對這一問題進(jìn)行了優(yōu)化，且性能上得到了很大的提升，不過Overlay2也有和AUFS有同樣的弊端——對大文件的操作速度比較慢。 

DeviceMapper

DeviceMapper和前兩種Storage-driver在實現(xiàn)上存在很大的差異。首先DeviceMapper的每一層保存的是上一層的快照，其次DeviceMapper對數(shù)據(jù)的操作不再是基于文件的而是基于數(shù)據(jù)塊的。

下圖是devicemapper在容器層讀取文件的過程： 

1. 首先在容器層的快照中找到該文件指向下層文件的指針。
2. 再從下層0xf33位置指針指向的數(shù)據(jù)塊中讀取的數(shù)據(jù)到容器的存儲區(qū)
3. ***將數(shù)據(jù)返回app。

在寫入數(shù)據(jù)時還需要根據(jù)數(shù)據(jù)的大小先申請1~N個64K的容器快照，用于保存拷貝的塊數(shù)據(jù)。

DeviceMapper的塊操作看上去很美，實際上存在很多問題，比如頻繁操作較小文件時需要不停地從資源池中分配數(shù)據(jù)庫并映射到容器中，這樣效率會變得很低，且DeviceMapper每次鏡像運行時都需要拷貝所有的鏡像層信息到內(nèi)存中，當(dāng)啟動多個鏡像時會占用很大的內(nèi)存空間。

針對不同的storage-driver我們用上述etcd的dockerfile進(jìn)行了一組構(gòu)建測試 

注：該數(shù)據(jù)因dockerfile以及操作系統(tǒng)、文件系統(tǒng)、網(wǎng)絡(luò)環(huán)境的不同測試結(jié)果可能會存在較大差異

我們發(fā)現(xiàn)在該實驗場景下DevivceMapper在時間上明顯會遜于AUFS和Overlay2，而AUFS和Overlay2基本相當(dāng)，當(dāng)然該數(shù)據(jù)僅能作為一個參考，實際構(gòu)建還受到具體的Dockerfile內(nèi)容以及操作系統(tǒng)、文件系統(tǒng)、網(wǎng)絡(luò)環(huán)境等多方面的影響，那要怎么樣才能盡量讓構(gòu)建時間最短提升我們的工作效率呢?

且看下回分解!