1. 程式人生 > >深刻理解Docker鏡像大小

深刻理解Docker鏡像大小

apt-get centos 基本 部分 for i++ 新的 split asc

都說容器大法好,可是假設沒有Docker鏡像,Docker該是多無趣啊。

是否還記得第一個接觸Docker的時候,你從Docker Hub下拉的那個鏡像呢?在那個處女鏡像的基礎上。你執行了容器生涯的處女容器。鏡像的基石作用已經非常明顯。在Docker的世界裏,能夠說是:No Image,No Container。

再進一步思考Docker鏡像,大家可能非常快就會聯想到下面幾類鏡像:

1.系統級鏡像:如Ubuntu鏡像。CentOS鏡像以及Debian容器等;

2.工具棧鏡像:如Golang鏡像。Flask鏡像,Tomcat鏡像等;

3.服務級鏡像:如MySQL鏡像,MongoDB鏡像。RabbitMQ鏡像等;

4.應用級鏡像:如WordPress鏡像,DockerRegistry鏡像等。

鏡像林林總總。想要執行Docker容器。必須要有Docker鏡像;想要有Docker鏡像,必須要先下載Docker鏡像。既然涉及到下載Docker鏡像,自然會存在Docker鏡像存儲。談到Docker鏡像存儲,那我們首先來聊聊Docker鏡像大小方面的知識。

下面將從三個角度來分析Docker鏡像的大小問題:Dockerfile與鏡像聯合文件系統以及鏡像共享關系

Dockerfile與鏡像

Dockerfile由多條指令構成,隨著深入研究Dockerfile與鏡像的關系,非常快大家就會發現。Dockerfile中的每一條指令都會相應於Docker鏡像中的一層。

繼續以例如以下Dockerfile為例:

FROM ubuntu:14.04
ADD run.sh /
VOLUME /data
CMD ["./run.sh"]

通過docker build以上Dockerfile的時候。會在Ubuntu:14.04鏡像基礎上,加入三層獨立的鏡像,依次相應於三條不同的命令。

鏡像示意圖例如以下:

技術分享

有了Dockerfile與鏡像關系的初步認識之後,我們再進一步聯系到每一層鏡像的大小。

不得不說,在層級化管理的Docker鏡像中。有不少層大小都為0。

那些鏡像層大小不為0的情況,歸根結底的原因是:構建Docker鏡像時,對當前的文件系統造成了改動更新。

而改動更新的情況主要有兩種:

1.ADD或COPY命令:ADD或者COPY的作用是在docker build構建鏡像時向容器中加入內容。僅僅要內容加入成功,當前構建的那層鏡像就是加入內容的大小,如以上命令ADD run.sh /。新構建的那層鏡像大小為文件run.sh的大小。

2.RUN命令:RUN命令的作用是在當前空的鏡像層內執行一條命令,倘若執行的命令須要更新磁盤文件。那麽全部的更新內容都在存儲在當前鏡像層中。

舉例說明:RUN echo DaoCloud命令不涉及文件系統內容的改動,故命令執行完之後當前鏡像層的大小為0;RUN wget http://abc.com/def.tar命令會將壓縮包下載至當前文件夾下,因此當前這一層鏡像的大小為:對文件系統內容的增量改動部分,即def.tar文件的大小。

聯合文件系統

Dockerfile中命令與鏡像層一一相應。那麽是否意味著docker build完成之後。鏡像的總大小=每一層鏡像的大小總和呢?答案是肯定的。

依舊以上圖為例:假設ubuntu:14.04鏡像的大小為200MB,而run.sh的大小為5MB,那麽以上三層鏡像從上到下,每層大小依次為0、0以及5MB,那麽終於構建出的鏡像大小的確為0+0+5+200=205MB。

盡管終於鏡像的大小是每層鏡像的累加,可是須要額外註意的是:Docker鏡像的大小並不等於容器中文件系統內容的大小(不包含掛載文件,/proc、/sys等虛擬文件)。個中緣由,就和聯合文件系統有非常大的關系了。

首先來看一下這個簡單的Dockerfile樣例(假如在Dockerfile當前文件夾下有一個100MB的壓縮文件compressed.tar):

FROM ubuntu:14.04
ADD compressed.tar /
RUN rm /compressed.tar
ADD compressed.tar /

1.FROM ubuntu:鏡像ubuntu:14.04的大小為200MB;

2.ADD compressed.tar /: compressed.tar文件為100MB,因此當前鏡像層的大小為100MB,鏡像總大小為300MB。

3.RUN rm /compressed.tar:刪除文件compressed.tar,此時的刪除並不會刪除下一層的compressed.tar文件。僅僅會在當前層產生一個compressed.tar的刪除標記,確保通過該層將看不到compressed.tar,因此當前鏡像層的大小也為0。鏡像總大小為300MB。

4.ADD compressed.tar /:compressed.tar文件為100MB,因此當前鏡像層的大小為300MB+100MB。鏡像總大小為400MB。

分析完成之後,我們發現鏡像的總大小為400MB。可是假設執行該鏡像的話,我們非常快能夠發如今容器根文件夾下執行du -sh之後。顯示的數值並不是400MB,而是300MB左右。基本的原因還是:聯合文件系統的性質保證了兩個擁有compressed.tar文件的鏡像層,僅僅會容器看到一個。同一時候這也說明了一個現狀,當用戶基於一個非常大,甚至好幾個GB的鏡像執行容器時。在容器內部查看根文件夾大小,發現居然僅僅有500MB不到,設置更小。

分析至此,有一點大家須要非常註意:鏡像大小和容器大小有著本質的差別。

鏡像共享關系

Docker鏡像說大不大,說小不小。可是一旦鏡像的總數上來之後,豈不是對本地磁盤造成非常大的存儲壓力?平均每一個鏡像500MB,豈不是100個鏡像就須要準備50GB的存儲空間?

結果往往不是我們想象的那樣,Docker在鏡像復用方面設計得非常出色,大大節省鏡像占用的磁盤空間。

Docker鏡像的復用主要體如今:多個不同的Docker鏡像能夠共享同樣的鏡像層。

假設本地鏡像存儲中僅僅有一個ubuntu:14.04的鏡像。我們以兩個Dockerfile來說明鏡像復用:

FROM ubuntu:14.04
RUN apt-get update
FROM ubuntu:14.04
ADD compressed.tar /

假設終於docker build構建出來的鏡像名分別為image1和image2。因為兩個Dockerfile均基於ubuntu:14.04。因此。image1和image2這兩個鏡像均復用了鏡像ubuntu:14.04。

假設RUN apt-get update改動的文件系統內容為20MB,終於本地三個鏡像的大小關系應該例如以下:

ubuntu:14.04: 200MB

image1:200MB(ubuntu:14.04)+20MB=220MB

image2:200MB(ubuntu:14.04)+100MB=300MB

假設僅僅是單純的累加三個鏡像的大小,那結果應該是:200+220+300=720MB,可是因為鏡像復用的存在,實際占用的磁盤空間大小是:200+20+100=320MB,足足節省了400MB的磁盤空間。在此,足以證明鏡像復用的巨大優點。

總結

學習Docker的同一時候,往往有三部分內容是分不開的,那就是Dockerfile。Docker鏡像與Docker容器,分析Docker鏡像大小也是如此。Docker鏡像的大小,貌似平淡無奇,卻是優化鏡像,容器磁盤限額必須要涉及的內容。

本系列將通過下面多篇文章來分析Docker鏡像:

1.深刻理解 Docker 鏡像大小

2.事實上 docker commit 非常easy

3.不得不說的 docker save 與 docker export 差別

4.為什麽有些容器文件動不得

5.打破 MNT Namespace 的容器 VOLUME

技術分享

歡迎關註[Docker源代碼分析]微信公眾號。很多其它精彩即將呈現。

深刻理解Docker鏡像大小