004.Docker鏡像管理

一 鏡像基本操作

鏡像是一個包含程序運行必要依賴環境和代碼的只讀文件，其本質是磁盤上一系列文件的集合。它采用分層的文件系統，將每一次改變以讀寫層的形式增加到原來的只讀文件上。鏡像是容器運行的基石。

1.1 搜索鏡像

root@docker:~# docker search centos				#查詢centos共享鏡像

docker命令必須具備root權限，普通用戶可是用那個sudo。

提示：docker默認的Docker Hub 網址為： https://hub.docker.com/，速度很慢，建議添加國內的阿里雲加速器，參考004-4.1。

選項說明：

NAME:鏡像倉庫源的名稱

DESCRIPTION:鏡像的描述

OFFICIAL:是否docker官方發布

AUTOMATED：是否使用了自動構建

1.2 下載（拉取）鏡像

root@docker:~# docker pull centos:7				#使用pull下載鏡像

提示：

Registry：倉庫，Registry包含一個或多個Repository

Repository：系列，Repository包含一個或多個Image

Tag and Image：Image用GUID表示，有一個或多個Tag與之關聯，版本號。

1.3 列出（查看）本地鏡像

root@docker:~# docker images 	<特定標簽>			#查看本地下載的鏡像

選項說明:

• REPOSTITORY：表示鏡像的倉庫源，有以下類型：

• [namespace/centos]：由命名空間和實際的倉庫名稱組成。
• [centos]：只有倉庫名。屬於頂級命名空間，只用於官方鏡像。
• [dl.dockerpool.com:5000\centos:7]：指定URL路徑的方式。

• TAG：鏡像的標簽

• 未指定鏡像tag時，默認為latest，但latest沒有任何特殊含義，人為的將latest作為最新穩定版本的別名；
• 一個repository可以有多個tag,而多個tag也可能對應同一個鏡像。

• IMAGE ID：鏡像ID
• CREATED：鏡像創建時間
• SIZE：鏡像大小

1.4 推送鏡像

root@docker:~# docker push registry.cn-hangzhou.aliyuncs.com/xhy-study-01/xhy-images-01:centos-7-xhy

提示：推送鏡像之前必須配置好倉庫信息。建議推送至個人私有倉庫，同時采用國內阿里雲私有倉庫，配置方法見《附001-docker阿里雲Registry配置》。

1.5 導出鏡像

root@docker:~# docker save -o centos-7.tar centos:7

1.6 導入鏡像

root@docker:~# docker load -i centos-7.tar

1.7 刪除鏡像

root@docker:/study# docker rmi httpd

1.8 設置鏡像標簽

root@docker:~# docker tag 6de222aa7640 xhy/centos7:v3
root@docker:~# docker images

二 docker文件系統

2.1 Linux文件系統簡介

linux文件系統由bootfs和rootfs組成，bootfs主要包含bootloader和kernel，bootloader主要是引導加載kernel，當kernel被加載到內存之后bootfs就被卸載掉了。rootfs包含的就是典型linux系統中/dev,/proc,/bin,/etc等標准目錄。

2.2 docker文件系統

Docker容器是建立在Aufs基礎上的，Aufs支持將不同的目錄掛載到同一個虛擬文件系統下，並實現一種layer的概念。Aufs將掛載到同一虛擬文件系統下的多個目錄分別設置成read-only，read-write以及whiteout-able權限。

read-only目錄只能讀，而寫操作只能在read-write目錄中實現。

寫操作是在read-only之上的一種增量操作，不影響read-only目錄。

docker 鏡像中每一層文件系統都是read-only。

提示：當掛載目錄的時候要嚴格按照各目錄之間的這種增量關系，將被增量操作的目錄優先於在它基礎上增量操作的目錄掛載，待所有目錄掛載結束了，繼續掛載一個read-write目錄，如此便形成了一種層次結構。

2.3 docker鏡像原理

在構建鏡像時，從一個最基本的操作系統開始，每個構建的操作都相當於做一層修改，增加了一層文件系統，一層層往上疊加，上層的修改會覆蓋底層該位置的可見性。當使用時，只會看到一個完全的整體，總共有多少層以及每層所做的修改都是透明的。

docker image 中最基礎的兩層結構：

不同的 linux 發行版（如 ubuntu 和 CentOS ) 在 rootfs 這一層會有所區別，體現發行版本的差異性：

傳統的 Linux 加載 bootfs 時會將 rootfs 設為 read-only，然后在系統自檢后將 rootfs 從 read-only改為 read-write，然后可在 rootfs 上進行讀寫操作。

Docker相比在 bootfs 自檢完畢之后不會將 rootfs 的 read-only 改為 read-write，而是利用 union mount（UnionFS 的一種掛載機制）將 image 中其他的 layer 加載到之前的 read-only 的 rootfs 層之上，每一層 layer 都是 rootfs 的結構，並且是read-only 的。因此，無法修改一個已有鏡像里面的 layer層數據，只有當創建一個容器，即將 Docker 鏡像進行實例化后，系統會分配一層空的 read-write 的 rootfs ，用於提供數據修改。

三 鏡像結構

3.1 image結構

docker image的layer組織方式通常由 json、layer.tar、VERSION組成。

root@docker:/study# tar -xf centos-7.tar

root@docker:/study# tree

root@docker:/study# cat repositories
{"centos":{"7":"d1ed0d8ec4ec460641430566e9a8cece698e60d4ad4afcf48759ad157d340064"}}

解釋：repositories 文件，里面是一個 JSON 定義，保存了三個信息：鏡像名字、tag、tag 對應的 layer。

root@docker:/study# cat d1ed0d8ec4ec460641430566e9a8cece698e60d4ad4afcf48759ad157d340064/json | jq .

解釋：主要關於鏡像的配置信息，簡要部分信息如上。

root@docker:/study# tar -tf d1ed0d8ec4ec460641430566e9a8cece698e60d4ad4afcf48759ad157d340064/layer.tar

解釋：包括一個類 Linux 文件目錄的結構，保存着這個 layer 所做的修改。

四 Dockerfile、Docker鏡像和Docker容器

4.1 關系

Dockerfile 是軟件的原材料，Docker 鏡像是軟件的交付品，而 Docker 容器則可以認為是軟件的運行態。從應用軟件的角度來看，Dockerfile、Docker 鏡像與 Docker 容器分別代表軟件的三個不同階段，Dockerfile 面向開發，Docker 鏡像成為交付標准，Docker 容器則涉及部署與運維。

Dockerfile構建出Docker鏡像，通過Docker鏡像運行Docker容器。

參考鏈接：http://dockone.io/article/783

https://blog.csdn.net/xuguokun1986/article/details/79295947

五 docker存儲驅動

Docker最開始采用AUFS作為文件系統，也得益於AUFS分層的概念，實現了多個Container可以共享同一個image。但由於AUFS未並入Linux內核，且只支持Ubuntu，考慮到兼容性問題，在Docker 0.7版本中引入了存儲驅動， 目前，Docker支持AUFS、Btrfs、Device mapper、OverlayFS、ZFS五種存儲驅動。

5.1 底層技術

• 寫時復制（CoW）

所有驅動都需要用到寫時復制（CoW），CoW就是copy-on-write，表示只在需要寫時才去復制，這個是針對已有文件的修改場景。比如基於一個image啟動多個Container，如果為每個Container都去分配一個image一樣的文件系統，那么將會占用大量的磁盤空間。而CoW技術可以讓所有的容器共享image的文件系統，所有數據都從image中讀取，只有當要對文件進行寫操作時，才從image里把要寫的文件復制到自己的文件系統進行修改。

所以無論有多少個容器共享同一個image，所做的寫操作都是對從image中復制到自己的文件系統中的復本上進行，並不會修改image的源文件，且多個容器操作同一個文件，會在每個容器的文件系統里生成一個復本，每個容器修改的都是自己的復本，相互隔離，相互不影響。使用CoW可以有效的提高磁盤的利用率。

• 用時分配（allocate-on-demand）

用時分配是用在原本沒有這個文件的場景，只有在要新寫入一個文件時才分配空間，這樣可以提高存儲資源的利用率。比如啟動一個容器，並不會為這個容器預分配一些磁盤空間，而是當有新文件寫入時，才按需分配新空間。

5.2 AUFS

AUFS（AnotherUnionFS）是一種Union FS，是文件級的存儲驅動。AUFS能透明覆蓋一個或多個現有文件系統的層狀文件系統，把多層合並成文件系統的單層表示。即支持將不同目錄掛載到同一個虛擬文件系統下的文件系統。

這種文件系統可以一層一層地疊加修改文件。無論底下有多少層都是只讀的，只有最上層的文件系統是可寫的。當需要修改一個文件時，AUFS創建該文件的一個副本，使用CoW將文件從只讀層復制到可寫層進行修改，結果也保存在可寫層。

在Docker中，底下的只讀層就是image，可寫層就是Container。結構如下圖所示：

5.3 OverlayFS

Overlay是Linux內核3.18后支持的，也是一種Union FS，和AUFS的多層不同的是Overlay只有兩層：一個upper文件系統和一個lower文件系統，分別代表Docker的鏡像層和容器層。當需要修改一個文件時，使用CoW將文件從只讀的lower復制到可寫的upper進行修改，結果也保存在upper層。在Docker中，底下的只讀層就是image，可寫層就是Container。

5.4 Device mapper

Device mapper是Linux內核2.6.9后支持的，提供的一種從邏輯設備到物理設備的映射框架機制，在該機制下，用戶可根據需要制定實現存儲資源的管理策略。

不同於AUFS和OverlayFS的文件級存儲，Device mapper是塊級存儲，所有的操作都是直接對塊進行操作，而不是文件。

Device mapper驅動會先在塊設備上創建一個資源池，然后在資源池上創建一個帶有文件系統的基本設備，所有鏡像都是這個基本設備的快照，而容器則是鏡像的快照。

所以在容器里看到文件系統是資源池上基本設備的文件系統的快照，並不有為容器分配空間。當要寫入一個新文件時，在容器的鏡像內為其分配新的塊並寫入數據，即用時分配。當要修改已有文件時，再使用CoW為容器快照分配塊空間，將要修改的數據復制到在容器快照中新的塊里再進行修改。

Device mapper 驅動默認會創建一個100G的文件包含鏡像和容器。每一個容器被限制在10G大小的卷內，大小可配置調整。

5.5 Btrfs

Btrfs被稱為下一代寫時復制文件系統，並入Linux內核，也是文件級級存儲，但可以像Device mapper直接操作底層設備。

Btrfs把文件系統的一部分配置為一個完整的子文件系統，稱之為subvolume 。那么采用 subvolume，一個大的文件系統可以被划分為多個子文件系統，這些子文件系統共享底層的設備空間，在需要磁盤空間時便從底層設備中分配。

為了靈活利用設備空間，Btrfs 將磁盤空間划分為多個chunk 。每個chunk可以使用不同的磁盤空間分配策略。比如某些chunk只存放metadata，某些chunk只存放數據。這種模型有很多優點，比如Btrfs支持動態添加設備。

用戶在系統中增加新的磁盤之后，可以使用Btrfs的命令將該設備添加到文件系統中。

Btrfs把一個大的文件系統當成一個資源池，配置成多個完整的子文件系統，還可以往資源池里加新的子文件系統，而基礎鏡像則是子文件系統的快照，每個子鏡像和容器都有自己的快照，這些快照則都是subvolume的快照。

當寫入一個新文件時，為在容器的快照里為其分配一個新的數據塊，文件寫在這個空間里，這個叫用時分配。而當要修改已有文件時，使用CoW復制分配一個新的原始數據和快照，在這個新分配的空間變更數據，變結束再更新相關的數據結構指向新子文件系統和快照，原來的原始數據和快照沒有指針指向，被覆蓋。

5.6 ZFS

ZFS 文件系統是一個革命性的全新的文件系統，它從根本上改變了文件系統的管理方式，ZFS 完全拋棄了“卷管理”，不再創建虛擬的卷，而是把所有設備集中到一個存儲池中來進行管理，用“存儲池”的概念來管理物理存儲空間。過去，文件系統都是構建在物理設備之上的。為了管理這些物理設備，並為數據提供冗余，“卷管理”的概念提供了一個單設備的映像。而ZFS創建在虛擬的，被稱為“zpools”的存儲池之上。每個存儲池由若干虛擬設備（virtual devices，vdevs）組成。這些虛擬設備可以是原始磁盤，也可能是一個RAID1鏡像設備，或是非標准RAID等級的多磁盤組。於是zpool上的文件系統可以使用這些虛擬設備的總存儲容量。

Docker里ZFS的使用。首先從zpool里分配一個ZFS文件系統給鏡像的基礎層，而其他鏡像層則是這個ZFS文件系統快照的克隆，快照是只讀的，而克隆是可寫的，當容器啟動時則在鏡像的最頂層生成一個可寫層。如下圖所示：

當要寫一個新文件時，使用按需分配，一個新的數據快從zpool里生成，新的數據寫入這個塊，而這個新空間存於容器（ZFS的克隆）里。

當要修改一個已存在的文件時，使用寫時復制，分配一個新空間並把原始數據復制到新空間完成修改。

5.7 存儲驅動的對比及適應場景

	特點	優點	缺點	使用場景
AUFS	聯合文件系統 未並入內核主線 文件級存儲	作為docker的第一個存儲驅動，相對穩定，且在大量的生產中實踐，有較強的社區支持。	有多層，在做寫時復制操作時，如果文件較大且存在比較低的層，可能會慢一些。	大並發但少IO的場景。
OverlayFS	聯合文件系統 並入內核主線 文件級存儲	只有兩層	不管修改的內容大小都會復制整個文件，對大文件進行修改顯示要比小文件消耗更多的時間。	大並發但少IO的場景。
Device mapper	並入內核主線 塊級存儲	塊級無論是大文件還是小文件都只復制需要修改的塊，並不是整個文件。	不支持共享存儲，即有多個容器讀同一個文件時，需要生產多個副本，在多容器啟停的情況下可能會導致磁盤溢出。	適合IO密集的場景。
Btrfs	並入內核主線 文件級存儲	可如Device mapper直接操作底層設備，支持動態添加設備。	不支持共享存儲，即有多個容器讀同一個文件時，需要生產多個副本，在多容器啟停的情況下可能會導致磁盤溢出。	不適合在高密度容器的PaaS平台上使用。
ZFS	把所有設備密集到一個存儲池進行管理。	支持多個容器共享一個緩存塊，適合內存大的環境。	COW使碎片化問題更加嚴重，文件在硬盤上的物理地址會變得不再連續，順序讀會變得性能比較差。	適合PaaS和高密度的場景。

參考鏈接：http://dockone.io/article/1513

5.8 修改docker存儲驅動類型

root@docker:~# vi /etc/docker/daemon.json
{
"storage-driver": "overlay2"
}

六 創建鏡像

從鏡像倉庫中下載的鏡像若不能滿足需求，可通過以下兩種方式對鏡像進行更改。

• 從已經創建的容器中更新鏡像，並且提交這個鏡像
• 使用 Dockerfile 指令來創建一個新的鏡像

6.1 更新鏡像並提交

1. 運行容器
2. 修改容器
3. 將容器保存為新的鏡像

root@docker:~# docker run --name centos-7-01 -it centos:7 /bin/bash	#創建容器
[root@01b2b251e216 /]# yum -y install net-tools vim openssh-clients wget ntp bash-completion    #安裝軟件
[root@01b2b251e216 /]# exit
root@docker:~# docker commit -m="has modify" -a="xhy" 01b2b251e216 centos-7-01
root@docker:~# docker images

參數說明：

• -m:提交的描述信息
• -a:指定鏡像作者
• 01b2b251e216 ：容器ID
• centos-7-01:指定要創建的目標鏡像名

root@docker:~# docker images						#查看鏡像

更新現有鏡像缺陷

• 手動創建，容易出錯，效率低及可重復性弱
• 使用者並不知道鏡像是如何創建出來的，里面是否有惡意程序，可能存在案例隱患

6.2 Dockerfile構建鏡像舉例

root@docker:~# mkdir /dockerfiles
root@docker:~# cd /dockerfiles/
root@docker:/dockerfiles# vi Dockerfile
FROM            centos:7
MAINTAINER  Fisher "[e-mail]"

RUN         /bin/echo 'root:x123456' |chpasswd
RUN         useradd xhy
RUN         /bin/echo 'xhy:x123456' |chpasswd
RUN         /bin/echo -e "LANG=\"en_US.UTF-8\"" >/etc/default/local
EXPOSE      22
EXPOSE      80
CMD         /usr/sbin/sshd -D

語句說明：

第一條FROM，指定所采用的鏡像源，每一個指令的前綴都必須是大寫的；

RUN 指令表示docker在鏡像內執行的命令，更多詳見七Dockerfile詳解。

root@docker:/dockerfiles# docker build -t xhy/centos7 /dockerfiles/

參數說明：

• -t ：指定要創建的目標鏡像名
• /dockerfiles/：Dockerfile 文件所在目錄

root@docker:~# docker images						#查看鏡像

root@docker:/dockerfiles# docker run -t -i xhy/centos7  /bin/bash	#創建容器

七 Dockerfile詳解

7.1 Dockerfile典型結構

From ubutu						#第一行必須指令基於的基礎鏡像
MAINTAINER docker_user  [e-mail]        #維護者信息
apt/sourcelist.list					#鏡像的操作指令
RUN apt-get update && apt-get install -y ngnix 	#鏡像的操作指令
RUN echo "\ndaemon off;">>/etc/ngnix/nignix.conf	#鏡像的操作指令
CMD /usr/sbin/ngnix					#容器啟動時執行指令

7.2 Dockerfile相關指令

• 指令：From

語法：

FROM <image>
FROM <image>:<tag>
FROM <image>:<digest>

含義：FROM命令定義構建鏡像的基礎鏡像，該條必須是dockerfile的首個命令。若同一個DockerFile創建多個鏡像時，可使用多個From指令（每個鏡像一次），FROM 是必備且必須是第一條指令。在FROM指定構建鏡像的基礎源鏡像時，若本地沒有指定的該鏡像，則會自動從 Docker 的公共庫 pull 鏡像下來。

提示：

• FROM必須是 Dockerfile 中非注釋行的第一個指令，即一個 Dockerfile 從FROM語句開始。
• 如果有需求在一個 Dockerfile 中創建多個鏡像，則FROM可以在一個 Dockerfile 中出現多次。
• 如果FROM語句沒有指定鏡像標簽，則默認使用latest標簽。

舉例：FROM ubuntu

• 指令：MAINTAINER

語法：

MAINTAINER <name>

含義：聲明作者信息，可以放在文件任何位置，建議放在FROM后面。

舉例：

MAINTAINER  xhy

• 指令：RUN

語法：

RUN <commands>
RUN "executable", "param1", "param2"

含義：RUN 指令是用來執行命令行命令的,每條RUN指令將在當前鏡像基礎上執行指定命令，並提交為新的鏡像，后續RUN都在之前RUN提交后的鏡像為基礎.

exec 方式會被解析為一個 JSON 數組，所以必須使用雙引號而不是單引號。exec 方式不會調用一個命令 shell，所以也就不會繼承相應的變量,RUN產生的緩存在下一次構建的時依舊有效，且會被重用，可以使用--no-cache選項，即docker build --no-cache，如此便不會緩存。

舉例：

RUN echo 'Hello, Docker!'
RUN ["/bin/bash", "-c","echo hello"]

提示：對於處理同一事件的多個命令，建議采用&&連接為一個命令，即構建一層即可。命令過長可使用\的換行方式。

• 指令：CMD

語法：

CMD "executable","param1","param2"
CMD "param1","param2"
CMD command param1 param2 (shell form)

含義：CMD配置在啟動容器時提供一個默認的命令執行選項，如果用戶啟動容器時指定了運行的命令，則會覆蓋掉CMD指定的命令。

舉例：

提示：在容器運行時可指定新的命令來替代鏡像設置的默認命令，如ubuntu鏡像默認的CMD是/bin/bash，直接docker run -it ubuntu則會進入bash。若在運行時指定其他的命令，如docker run -it ubuntu cat /etc/os-release 。則使用cat /etc/os-release命令替換默認/bin/bash命令。

注意：CMD會在啟動容器的時候執行，build 時不執行，而RUN只是在構建鏡像的時候執行。

• 指令：ENTRYPOINT

語法：

ENTRYPOINT "executable", "param1", "param2"
ENTRYPOINT command param1 param2 (shell form)

含義：ENTRYPOINT配置容器啟動后執行的命令，並且不可被 docker run 提供的參數覆蓋，區別於CMD是可以被覆蓋的。若需要ENTRYPOINT被覆蓋，則可以使用docker run --entrypoint選項。

舉例：

ENTRYPOINT ["nginx"]
CMD ["-g","daemon off;"]

注意：每個 Dockerfile 中只能有一個ENTRYPOINT，當指定多個時，只有最后一個生效；

當指定了 ENTRYPOINT 后， CMD 不再是直接的運行其命令，而是將CMD 的內容作為參數傳給 ENTRYPOINT 指令，即：<ENTRYPOINT> "<CMD>"

• 指令：ADD

語法：

ADD <src>... <dest>

含義：復制本地主機、url或啟動配置上下文中的文件到容器指定路徑中 。

舉例：

ADD http://mirrors.163.com/.help/CentOS7-Base-163.repo /etc/yum.repos.d/CentOS-Base.repo

提示：若 <src> 是一個 URL ，構建鏡像時會下載這個鏈接的文件放至 <dest> ，下載后權限為 600；

若傳入dest的是個tar壓縮包，壓縮格式為 gzip、bzip2 以及 xz 的情況下， ADD 指令將會自動解壓縮這個壓縮文件至 <dest> 。因此若只是復制個壓縮文件進去，而不解壓縮，建議使用copy；

ADD 指令會令鏡像構建緩存失效，從而可能會令鏡像構建變得比較緩慢。

• 指令：COPY

語法：

COPY <src>... <dest>

含義：復制新文件或者目錄從 並且添加到容器指定路徑中 ，用法參考ADD，但COPY不能指定遠程文件 URLS。

舉例：

COPY package.json /usr/src/app/

建議：在 COPY 和 ADD 指令中選擇的時候，可以遵循這樣的原則，所有的文件復制均使用 COPY 指令，僅在需要自動解壓縮的場合使用 ADD 。

• 指令：EXPOSE

語法：

EXPOSE <port> [<port>...]

含義：聲明Docker服務端容器對外監聽的端口，需要同時在docker run 的時候使用-p或者-P選項生效，默認為TCP。

舉例：

EXPOSE 22 80 8443

• 指令：ENV

語法：

ENV <key> <value>       # 只能設置一個變量
ENV <key>=<value> ...   # 允許一次設置多個變量

含義：指定一個環節變量，會被后續RUN指令使用，並在容器運行時保留。

舉例：

ENV myName="John Doe" myDog=Rex myCat=fluffy
ENV PG_MAJOR 9.3
ENV PG_VERSION 9.3.4

• 指令：VOLUME

語法：

VOLUME ["<路徑1>", "<路徑2>"...]
VOLUME <路徑>

含義：卷分為宿主目錄、數據卷、容器卷。VOLUME命令會設置掛載點，在啟動容器的時候Docker會在/var/lib/docker/的下一級目錄下創建一個卷，一般用來存放動態數據和需要保持的數據等。

舉例：

VOLUME ["/data","/opt"]

• 指令：WORKDIR

語法：

WORKDIR <path>

含義：使用 WORKDIR 指令可以來指定工作目錄（或者稱為當前目錄），之后各層的當前目錄就被改為指定的目錄，如該目錄不存在， WORKDIR 會幫你建立目錄，在使用 docker run 命令啟動容器時，默認會進入的目錄是 WORKDIR 指定的目錄。

舉例：

WORKDIR /app

• 指令：USER

語法：

USER <user>[:<group>]
USER <UID>[:<GID>]

含義：指定運行容器時的用戶名或UID，后續的 RUN 也會使用指定用戶。當服務不需要管理員權限時，可以通過該命令指定運行用戶。

舉例：

RUN groupadd -r redis && useradd -r -g redis redis
USER redis
RUN [ "redis-server" ]

提示：WORKDIR 是改變工作目錄， USER 則是改變之后層的執行 RUN , CMD 以及 ENTRYPOINT 這類命令的身份。

• 指令：ONBUILD

語法：

ONBUILD [INSTRUCTION]

含義：ONBUILD 是一個特殊的指令，ONBUILD 后是其它指令，比如 RUN , COPY 等，而此類指令，在當前鏡像構建時並不會被執行。只有當以當前鏡像為基礎鏡像，去構建下一個鏡像的時候才會被執行。即配置當該鏡像作為其它新創建鏡像的基礎鏡像時，所執行的操作指令。

舉例：Dockerfile-01使用如下的內容創建了鏡像image-A：

[...]
ONBUILD ADD . /app/src
ONBUILD RUN /usr/local/bin/python-build --dir /app/src
[...]

Dockerfile-02使用基於image-A的基礎鏡像創建image-B：

FROM image-A

Dockerfile-02的內容等同於：

ADD . /app/src
RUN /usr/local/bin/python-build --dir /app/src

• 指令：HEALTHCHECK

語法：

HEALTHCHECK [選項] CMD <命令> ：設置檢查容器健康狀況的命令
HEALTHCHECK NONE ：如果基礎鏡像有健康檢查指令，使用這行可以屏蔽掉其健康檢查指令

含義：HEALTHCHECK 指令用於判斷Docker容器的狀態是否正常。

選項：

HEALTHCHECK 支持下列選項：

• interval=<間隔> ：兩次健康檢查的間隔，默認為 30 秒；
• timeout=<時長> ：健康檢查命令運行超時時間，如果超過這個時間，本次健康檢查就被視為失敗，默認 30 秒；
• retries=<次數> ：當連續失敗指定次數后，則將容器狀態視為 unhealthy ，默認 3 次。

舉例：

FROM nginx
RUN apt-get update && apt-get install -y curl && rm -rf /var/lib/apt/lists/*
HEALTHCHECK --interval=5s --timeout=3s \
CMD curl -fs http://localhost/ || exit 1

設置了每 5 秒檢查一次，如果健康檢查命令超過 3 秒沒響應就視為失敗，並且使用 curl -fs http://localhost/ || exit 1 作為健康檢查命令。

提示：類似CMD , ENTRYPOINT 一樣， HEALTHCHECK 也只可以出現一次，若存在多個HEALTHCHECK，只有最后一個生效。

參考鏈接：https://blog.csdn.net/wo18237095579/article/details/80540571

7.3 dockerfile最佳實踐

• 使用.dockerignore文件

為在docker build過程中更快上傳和更加高效，可使用一個.dockerignore文件用來排除構建鏡像時不需要的文件或目錄。

• 避免安裝不必要的軟件包

為了降低復雜性、依賴性、文件大小以及構建時間，應該避免安裝額外的或不必要的包。

• 每個容器都跑一個進程

在大多數情況下，一個容器應該只單獨跑一個程序。解耦應用到多個容器使其更容易橫向擴展和重用。

• 最小化層

每執行一個指令，都會有一次鏡像的提交，鏡像是分層的結構，對於Dockerfile，應該找到可讀性和最小化層之間的平衡。

• 多行參數排序

如果可能，通過字母順序來排序，這樣可以避免安裝包的重復並且更容易更新列表，另外可讀性也會更強，添加一個空行使用\換行:

RUN apt-get update && apt-get install -y \
  bzr \
  cvs \
  git \
  mercurial \
  subversion

• 盡可能清理不必要的文件

使構建后的鏡像盡可能的小。

參考鏈接：http://dockone.io/article/783