2020-04-06

第一個 Dockerfile

cd
mkdir static_web
cd static_web
touch Dockerfile

我們創(chuàng)建了一個名為 static_web 的目錄用來保存 Dockerfile ，這個目錄就是我們的構建環(huán)境（build environment），Docker 則稱此環(huán)境為上下午（context）或者構建上下文（build context）。Docker 會在構建鏡像時將構建上下文和該上下文中的文件和目錄上傳到 Docker 守護進程。這樣 Docker 守護進程就能直接訪問用戶想在鏡像中存儲的任何代碼、文件或者其他數(shù)據(jù)。

慎用 docker commit

使用 docker commit 命令雖然可以比較直觀的幫助理解鏡像分層存儲的概念，但是實際環(huán)境中并不會這樣使用。

首先，如果仔細觀察之前的 docker diff webserver 的結果，你會發(fā)現(xiàn)除了真正想要修改的/usr/share/nginx/html/index.html 文件外，由于命令的執(zhí)行，還有很多文件被改動或添加了。這還僅僅是最簡單的操作，如果是安裝軟件包、編譯構建，那會有大量的無關內(nèi)容被添加進來，如果不小心清理，將會導致鏡像極為臃腫。

此外，使用 docker commit 意味著所有對鏡像的操作都是黑箱操作，生成的鏡像也被稱為黑箱鏡像，換句話說，就是除了制作鏡像的人知道執(zhí)行過什么命令、怎么生成的鏡像，別人根本無從得知。而且，即使是這個制作鏡像的人，過一段時間后也無法記清具體在操作的。雖然 docker diff 或許可以告訴得到一些線索，但是遠遠不到可以確保生成一致鏡像的地步。這種黑箱鏡像的維護工作是非常痛苦的。

而且，回顧之前提及的鏡像所使用的分層存儲的概念，除當前層外，之前的每一層都是不會發(fā)生改變的，換句話說，任何修改的結果僅僅是在當前層進行標記、添加、修改，而不會改動上一層。如果使用 docker commit 制作鏡像，以及后期修改的話，每一次修改都會讓鏡像更加臃腫一次，所刪除的上一層的東西并不會丟失，會一直如影隨形的跟著這個鏡像，即使根本無法訪問到。這會讓鏡像更加臃腫。

使用 Dockerfile 定制鏡像

鏡像的定制實際上就是定制每一層所添加的配置、文件。如果我們可以把每一層修改、安裝、構建、操作的命令都寫入一個腳本，用這個腳本來構建、定制鏡像，那么之前提及的無法重復的問題、鏡像構建透明性的問題、體積的問題就都會解決。這個腳本就是 Dockerfile。

Dockerfile 是一個文本文件，由一系列指令和參數(shù)組成，其內(nèi)包含了一條條的指令(Instruction)，每一條指令構建一層，因此每一條指令的內(nèi)容，就是描述該層應當如何構建。每條指令，如 FROM，都必須為大寫字母，且后面要跟隨一個參數(shù)，如: FROM ubuntu。Dockerfile 中的指令會按照順序從上到下執(zhí)行，所以應該根據(jù)需要合理安排指令的順序，每條指令都會創(chuàng)建一個新的鏡像層并對鏡像進行提交。

FROM-指定基礎鏡像

所謂定制鏡像，那一定是以一個鏡像為基礎，在其上進行定制。基礎鏡像是必須指定的。

1. FROM 是一個構建指令，用于指定基礎 image
2. FROM 指令必須指定且需要在 Dockerfile 其它指令的前面
3. 后續(xù)的指令都依賴于該指令指定的 image
4. FROM 指令指定的基礎 image 可以是官方遠程倉庫中的，也可以位于本地倉庫

FROM <image> # 指定基礎 image 為該 image 的最后修改的版本
FROM <image>:<tag> # 指定基礎 image 為該 image 的一個 tag 版本

# 例如
FROM python:3.6.5

除了選擇現(xiàn)有鏡像為基礎鏡像外，Docker 還存在一個特殊的鏡像，名為 scratch 。這個鏡像是虛擬的概念，并不實際存在，它表示一個空白的鏡像。如果你以 scratch 為基礎鏡像的話，意味著你不以任何鏡像為基礎，接下來所寫的指令將作為鏡像第一層開始存在。

MAINTAINER

1. MAINTAINER 是一個構建指令，用來指定創(chuàng)建者信息
2. MAINTAINER 會將 image 的制作者相關的信息寫入到 image 中
3. 當對該 image 執(zhí)行 docker inspect 命令時，輸出中有相應的字段記錄該信息

MAINTAINER <name>  

# 例如
FROM python:3.6.5
MAINTAINER ycbbs  
MAINTAINER lemon "lemon@example.com"

RUN-執(zhí)行命令

1. RUN 指令是構建指令，是用來執(zhí)行命令行命令的。
2. RUN 可以運行任何被基礎 image 支持的命令

1. 如果基礎 image 選擇了 ubuntu，那么軟件管理部分只能使用 ubuntu 的命令
2. 如果基礎 image 選擇了 centos，那么軟件管理部分只能使用 centos 的命令

# 兩種方式
# 1. shell格式： 就像直接在命令行中輸入的命令一樣。
RUN <command>
# 2. exec 格式：更像是函數(shù)調用中的格式。
RUN ["executable", "param1", "param2" ... ]  

# 例如
RUN echo '<h1>Hello, Docker!</h1>' > /usr/share/nginx/html/index.html

FROM debian:jessie
RUN apt-get update
RUN apt-get install -y gcc libc6-dev make
RUN wget -O redis.tar.gz "http://download.redis.io/releases/redis-3.2.5.tar.gz"
RUN mkdir -p /usr/src/redis
RUN tar -xzf redis.tar.gz -C /usr/src/redis --strip-components=1
RUN make -C /usr/src/redis
RUN make -C /usr/src/redis install

Dockerfile 中每一個指令都會建立一層， RUN 也不例外。每一個 RUN 的行為，就和我們手工建立鏡像（commit）的過程一樣：新建立一層，在其上執(zhí)行這些命令，執(zhí)行結束后， commit 這一層的修改，構成新的鏡像。

而上面的這種寫法，創(chuàng)建了 7 層鏡像。這是完全沒有意義的，而且很多運行時不需要的東西，都被裝進了鏡像里，比如編譯環(huán)境、更新的軟件包等等。結果就是產(chǎn)生非常臃腫、非常多層的鏡像，不僅僅增加了構建部署的時間，也很容易出錯。

Union FS 是有最大層數(shù)限制的，比如 AUFS，曾經(jīng)是最大不得超過 42 層，現(xiàn)在是不得超過127 層。

上面的 Dockerfile 正確的寫法應該是這樣：

FROM debian:jessie
RUN buildDeps='gcc libc6-dev make' \
&& apt-get update \
&& apt-get install -y $buildDeps \
&& wget -O redis.tar.gz "http://download.redis.io/releases/redis-3.2.5.tar.gz" \
&& mkdir -p /usr/src/redis \
&& tar -xzf redis.tar.gz -C /usr/src/redis --strip-components=1 \
&& make -C /usr/src/redis \
&& make -C /usr/src/redis install \
&& rm -rf /var/lib/apt/lists/* \
&& rm redis.tar.gz \
&& rm -r /usr/src/redis \
&& apt-get purge -y --auto-remove $buildDeps

首先，之前所有的命令只有一個目的，就是編譯、安裝 redis 可執(zhí)行文件。因此沒有必要建立很多層，這只是一層的事情。因此，這里沒有使用很多個 RUN 對一一對應不同的命令，而是僅僅使用一個 RUN 指令，并使用 && 將各個所需命令串聯(lián)起來。將之前的 7 層，簡化為了1 層。在撰寫 Dockerfile 的時候，要經(jīng)常提醒自己，這并不是在寫 Shell 腳本，而是在定義每一層該如何構建。并且，這里為了格式化還進行了換行。

Dockerfile 支持 Shell 類的行尾添加 \ 的命令換行方式，以及行首 # 進行注釋的格式。良好的格式，比如換行、縮進、注釋等，會讓維護、排障更為容易，這是一個比較好的習慣。

此外，還可以看到這一組命令的最后添加了清理工作的命令，刪除了為了編譯構建所需要的軟件，清理了所有下載、展開的文件，并且還清理了 apt 緩存文件。這是很重要的一步，我們之前說過，鏡像是多層存儲，每一層的東西并不會在下一層被刪除，會一直跟隨著鏡像。因此鏡像構建時，一定要確保每一層只添加真正需要添加的東西，任何無關的東西都應該清理掉。

CMD-容器啟動命令

Docker 不是虛擬機，容器就是進程。既然是進程，那么在啟動容器的時候，需要指定所運行的程序及參數(shù)。 CMD 指令就是用于指定默認的容器主進程的啟動命令的。

在運行時可以指定新的命令來替代鏡像設置中的這個默認命令，比如， ubuntu 鏡像默認的CMD 是 /bin/bash ，如果我們直接 docker run -it ubuntu 的話，會直接進入 bash 。我們也可以在運行時指定運行別的命令，如 docker run -it ubuntu cat /etc/os-release 。這就是用 cat /etc/os-release 命令替換了默認的 /bin/bash 命令了，輸出了系統(tǒng)版本信息。

在指令格式上，一般推薦使用 exec 格式，這類格式在解析時會被解析為 JSON 數(shù)組，因此一定要使用雙引號 " ，而不要使用單引號。

如果使用 shell 格式的話，實際的命令會被包裝為 sh -c 的參數(shù)的形式進行執(zhí)行。比如：

CMD echo $HOME

在實際執(zhí)行中，會將其變更為：

CMD [ "sh", "-c", "echo $HOME" ]

這就是為什么我們可以使用環(huán)境變量的原因，因為這些環(huán)境變量會被 shell 進行解析處理。

Docker 不是虛擬機，容器中的應用都應該以前臺執(zhí)行，而不是像虛擬機、物理機里面那樣，用 upstart/systemd 去啟動后臺服務，容器內(nèi)沒有后臺服務的概念。

一些初學者將 CMD 寫為：

CMD service nginx start

然后發(fā)現(xiàn)容器執(zhí)行后就立即退出了。甚至在容器內(nèi)去使用 systemctl 命令結果卻發(fā)現(xiàn)根本執(zhí)行不了。這就是因為沒有搞明白前臺、后臺的概念，沒有區(qū)分容器和虛擬機的差異，依舊在以傳統(tǒng)虛擬機的角度去理解容器。

對于容器而言，其啟動程序就是容器應用進程，容器就是為了主進程而存在的，主進程退出，容器就失去了存在的意義，從而退出，其它輔助進程不是它需要關心的東西。

而使用 service nginx start 命令，則是希望 upstart 來以后臺守護進程形式啟動 nginx 服務。而剛才說了 CMD service nginx start 會被理解為 CMD [ "sh", "-c", "service nginx start"] ，因此主進程實際上是 sh 。那么當 service nginx start 命令結束后， sh 也就結束了， sh 作為主進程退出了，自然就會令容器退出。

正確的做法是直接執(zhí)行 nginx 可執(zhí)行文件，并且要求以前臺形式運行。比如：

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

1. CMD 指令是設置指令，用于設置容器 ( container ) 啟動時執(zhí)行的操作
2. CMD 指令用于 container 啟動時指定的操作。該操作可以是執(zhí)行自定義腳本，也可以是執(zhí)行系統(tǒng)命令
3. 該指令只能在文件中存在一次，如果有多個，則只執(zhí)行最后一條
4. 如果用戶啟動容器時（docker run command）指定了運行的命令，則會覆蓋掉 CMD 指定的命令

# 三種方式
# exec 格式
CMD ["executable","param1","param2"]
# shell 格式
CMD command param1 param2
CMD ["param1","param2"]

# 例如
FROM python:3.6.5
MAINTAINER ycbbs
RUN pip install flask
CMD ["python","/www/app/app.py"]

當 Dockerfile 指定了 ENTRYPOINT ，那么只能使用第三種格式

ENTRYPOINT 指定的是一個可執(zhí)行的腳本或者程序的路徑，該指定的腳本或者程序將會以 param1 和 param2 作為參數(shù)執(zhí)行

所以如果 CMD 指令使用第三種格式，那么 Dockerfile 中必須要有配套的 ENTRYPOINT

ENTRYPOINT-入口點

ENTRYPOINT 的格式和 RUN 指令格式一樣，分為 exec 格式和 shell 格式。

# 兩種方式
ENTRYPOINT ["executable", "param1", "param2"]
ENTRYPOINT command param1 param2

ENTRYPOINT 的目的和 CMD 一樣，都是在指定容器啟動程序及參數(shù)。 ENTRYPOINT 在運行時也可以替代，不過比 CMD 要略顯繁瑣，需要通過 docker run 的參數(shù) --entrypoint 來指定。

當指定了 ENTRYPOINT 后， CMD 的含義就發(fā)生了改變，不再是直接的運行其命令，而是將CMD 的內(nèi)容作為參數(shù)傳給 ENTRYPOINT 指令，換句話說實際執(zhí)行時，將變?yōu)椋?/p>

<ENTRYPOINT> "<CMD>"

那么有了 CMD 后，為什么還要有 ENTRYPOINT 呢？這種<ENTRYPOINT> "<CMD>" 有什么好處么？讓我們來看幾個場景。

場景一：讓鏡像變成像命令一樣使用

假設我們需要一個得知自己當前公網(wǎng) IP 的鏡像，那么可以先用 CMD 來實現(xiàn)：

FROM ubuntu:16.04
RUN apt-get update \
    && apt-get install -y curl \
    && rm -rf /var/lib/apt/lists/*
CMD [ "curl", "-s", "http://ip.cn" ]

假如我們使用 docker build -t myip . 來構建鏡像的話，如果我們需要查詢當前公網(wǎng) IP，只需要執(zhí)行：

$ docker run myip
當前 IP：61.148.226.66 來自：北京市 聯(lián)通

嗯，這么看起來好像可以直接把鏡像當做命令使用了，不過命令總有參數(shù)，如果我們希望加參數(shù)呢？比如從上面的 CMD 中可以看到實質的命令是 curl ，那么如果我們希望顯示 HTTP 頭信息，就需要加上 -i 參數(shù)。那么我們可以直接加 -i 參數(shù)給 docker run myip 么？

$ docker run myip -i
docker: Error response from daemon: invalid header field value "oci runtime error: con
tainer_linux.go:247: starting container process caused \"exec: \\\"-i\\\": executable
file not found in $PATH\"\n".

我們可以看到可執(zhí)行文件找不到的報錯， executable file not found 。之前我們說過，跟在鏡像名后面的是 command ，運行時會替換 CMD 的默認值。因此這里的 -i 替換了原來的 CMD ，而不是添加在原來的 curl -s http://ip.cn 后面。而 -i 根本不是命令，所以自然找不到。

那么如果我們希望加入 -i 這參數(shù)，我們就必須重新完整的輸入這個命令：

docker run myip curl -s http://ip.cn -i

這顯然不是很好的解決方案，而使用 ENTRYPOINT 就可以解決這個問題。現(xiàn)在我們重新用 ENTRYPOINT 來實現(xiàn)這個鏡像：

FROM ubuntu:16.04
RUN apt-get update \
  && apt-get install -y curl \
  && rm -rf /var/lib/apt/lists/*
ENTRYPOINT [ "curl", "-s", "http://ip.cn" ]

這次我們再來嘗試直接使用 docker run myip -i ：

$ docker run myip
當前 IP：61.148.226.66 來自：北京市 聯(lián)通
$ docker run myip -i
HTTP/1.1 200 OK
Server: nginx/1.8.0
Date: Tue, 22 Nov 2016 05:12:40 GMT
Content-Type: text/html; charset=UTF-8
Vary: Accept-Encoding
X-Powered-By: PHP/5.6.24-1~dotdeb+7.1
X-Cache: MISS from cache-2
X-Cache-Lookup: MISS from cache-2:80
X-Cache: MISS from proxy-2_6
Transfer-Encoding: chunked
Via: 1.1 cache-2:80, 1.1 proxy-2_6:8006
Connection: keep-alive
當前 IP：61.148.226.66 來自：北京市 聯(lián)通

可以看到，這次成功了。這是因為當存在 ENTRYPOINT 后， CMD 的內(nèi)容將會作為參數(shù)傳給 ENTRYPOINT ，而這里 -i 就是新的 CMD ，因此會作為參數(shù)傳給 curl ，從而達到了我們預期的效果。

場景二：應用運行前的準備工作

啟動容器就是啟動主進程，但有些時候，啟動主進程前，需要一些準備工作。

比如 mysql 類的數(shù)據(jù)庫，可能需要一些數(shù)據(jù)庫配置、初始化的工作，這些工作要在最終的 mysql 服務器運行之前解決。

此外，可能希望避免使用 root 用戶去啟動服務，從而提高安全性，而在啟動服務前還需要以 root 身份執(zhí)行一些必要的準備工作，最后切換到服務用戶身份啟動服務?；蛘叱朔胀猓渌钜琅f可以使用 root 身份執(zhí)行，方便調試等。

這些準備工作是和容器 CMD 無關的，無論 CMD 是什么，都需要事先進行一個預處理的工作。這種情況下，可以寫一個腳本，然后放入ENTRYPOINT 中去執(zhí)行，而這個腳本會將接到的參數(shù)（也就是 <CMD>）作為命令，在腳本最后執(zhí)行。比如官方鏡像 redis 中就是這么做的：

FROM alpine:3.4
...
RUN addgroup -S redis && adduser -S -G redis redis
...
ENTRYPOINT ["docker-entrypoint.sh"]
EXPOSE 6379
CMD [ "redis-server" ]

可以看到其中為了 redis 服務創(chuàng)建了 redis 用戶，并在最后指定了 ENTRYPOINT 為 docker-entrypoint.sh 腳本。

#!/bin/sh
...
# allow the container to be started with `--user`
if [ "$1" = 'redis-server' -a "$(id -u)" = '0' ]; then
chown -R redis .
exec su-exec redis "$0" "$@"
fi
exec "$@"

該腳本的內(nèi)容就是根據(jù) CMD 的內(nèi)容來判斷，如果是 redis-server 的話，則切換到 redis 用戶身份啟動服務器，否則依舊使用 root 身份執(zhí)行。比如：

$ docker run -it redis id
uid=0(root) gid=0(root) groups=0(root)

USER-指定當前用戶

USER 是設置指令，用于設置運行容器 ( container ) 的用戶，默認是 root

格式： USER <用戶名>

USER 指令和 WORKDIR 相似，都是改變環(huán)境狀態(tài)并影響以后的層。 WORKDIR 是改變工作目錄， USER 則是改變之后層的執(zhí)行， RUN ，CMD 以及 ENTRYPOINT 這類命令的身份。

當然，和 WORKDIR 一樣， USER 只是幫助你切換到指定用戶而已，這個用戶必須是事先建立好的，否則無法切換。

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

可以指定用戶名或 UID 以及組或 GID，甚至是兩者的組合:

USER user
USER user:group
USER uid
USER uid:gid
USER user:gid
USER uid:group

如果以 root 執(zhí)行的腳本，在執(zhí)行期間希望改變身份，比如希望以某個已經(jīng)建立好的用戶來運行某個服務進程，不要使用 su 或者 sudo ，這些都需要比較麻煩的配置，而且在 TTY 缺失的環(huán)境下經(jīng)常出錯。建議使用 gosu 。

# 建立 redis 用戶，并使用 gosu 換另一個用戶執(zhí)行命令
RUN groupadd -r redis && useradd -r -g redis redis
# 下載 gosu
RUN wget -O /usr/local/bin/gosu "https://github.com/tianon/gosu/releases/download/1.7/
gosu-amd64" \
&& chmod +x /usr/local/bin/gosu \
&& gosu nobody true
# 設置 CMD，并以另外的用戶執(zhí)行
CMD [ "exec", "gosu", "redis", "redis-server" ]

EXPOSE-聲明端口

格式為 EXPOSE <端口1> [<端口2>...]

EXPOSE 指令是聲明運行時容器提供服務端口，這只是一個聲明，在運行時并不會因為這個聲明應用就會開啟這個端口的服務。在 Dockerfile 中寫入這樣的聲明有兩個好處，一個是幫助鏡像使用者理解這個鏡像服務的守護端口，以方便配置映射；另一個用處則是在運行時使用隨機端口映射時，也就是 docker run -P 時，會自動隨機映射 EXPOSE 的端口，即 -P 參數(shù)會對外公開在 Dockerfile 中通過 EXPOSE 指令公開的所有端口，。

此外，在早期 Docker 版本中還有一個特殊的用處。以前所有容器都運行于默認橋接網(wǎng)絡中，因此所有容器互相之間都可以直接訪問，這樣存在一定的安全性問題。于是有了一個 Docker 引擎參數(shù) --icc=false ，當指定該參數(shù)后，容器間將默認無法互訪，除非互相間使用了 --links 參數(shù)的容器才可以互通，并且只有鏡像中 EXPOSE 所聲明的端口才可以被訪問。這個 --icc=false 的用法，在引入了 docker network 后已經(jīng)基本不用了，通過自定義網(wǎng)絡可以很輕松的實現(xiàn)容器間的互聯(lián)與隔離。

要將 EXPOSE 和在運行時使用 -p <宿主端口>:<容器端口> 區(qū)分開來。 -p ，是映射宿主端口和容器端口，換句話說，就是將容器的對應端口服務公開給外界訪問，而 EXPOSE 僅僅是聲明容器打算使用什么端口而已，并不會自動在宿主進行端口映射。

也可以將端口綁定限制在特定的網(wǎng)絡接口（即IP地址）上，-p 127.0.0.1:80:80 將容器內(nèi)的80端口綁定到了本地宿主機的 127.0.0.1 這個 IP 的 80 端口上。也可以使用類似的方式將容器內(nèi)的 80 端口綁定到一個宿主機的隨機端口上 -p 127.0.0.1::80，這里，我們并沒有指定具體要綁定的宿主機上的端口號，只指定了一
個IP地址 127.0.0.1 ，這時我們可以使用 docker inspect 或者 docker port 命令來查看容器內(nèi)的 80 端口具體被綁定到了宿主機的哪個端口上。

使用 docker ps 命令可以看到容器的端口分配情況，或者使用 docker port 來查看容器的端口映射情況。

docker port <容器名或容器ID> <容器端口號>

ENV-設置環(huán)境變量

# 格式有兩種：
ENV <key> <value>  
ENV <key1>=<value1> <key2>=<value2>...

這個指令很簡單，就是設置環(huán)境變量而已，無論是后面的其它指令，如 RUN ，還是運行時的應用，都可以直接使用這里定義的環(huán)境變量。

容器啟動后，可以通過 docker inspect 查看這個環(huán)境變量。

也可以通過在 docker run --env key=value 時設置或修改環(huán)境變量。

假如我們安裝了 JAVA 程序，需要設置 JAVA_HOME 那么可以在 Dockerfile 中這樣寫

ENV JAVA_HOME /path/to/java/dirent

ARG-構建參數(shù)

格式： ARG <參數(shù)名>[=<默認值>]

ARG 指令用來定義可以在 docker build 命令運行時傳遞給構建運行時的變量，我們只需要在構建時使用 --build-arg 標志即可。用戶只能在構建時指定在Dockerfile 文件中定義過的參數(shù)。

構建參數(shù)和 ENV 的效果一樣，都是設置環(huán)境變量。所不同的是， ARG 所設置的是構建環(huán)境的環(huán)境變量，在將來容器運行時是不會存在這些環(huán)境變量的。但是不要因此就使用 ARG 保存密碼之類的信息，因為 docker history 還是可以看到所有值的。

Dockerfile 中的 ARG 指令是定義參數(shù)名稱，以及定義其默認值。該默認值可以在構建命令 docker build 中用 --build-arg <參數(shù)名>=<值> 來覆蓋。

ARG build
ARG webapp_user=user

上面例子中第二條 ARG 指令設置了一個默認值，如果構建時沒有為該參數(shù)指定值，就會使用這個默認值。下面我們就來看看如何在 docker build 中使用這些參數(shù)。

docker build --build-arg build=1234 -t jamtur01/webapp .

這里構建 jamtur01/webapp 鏡像時，build 變量將會設置為 1234，而 webapp_user 變量則會繼承設置的默認值 user。

Docker 預定義了一組 ARG 變量，可以在構建時直接使用，而不必再到 Dockerfile 中自行定義。

HTTP_PROXY
http_proxy
HTTPS_PROXY
https_proxy
FTP_PROXY
ftp_proxy
NO_PROXY
no_proxy

要想使用這些預定義的變量，只需要給 docker build 命令傳遞 --build-arg <variable>=<value> 標志就可以了。

LABEL

LABEL 指令用于為 Docker 鏡像添加元數(shù)據(jù)。元數(shù)據(jù)以鍵值對的形式展現(xiàn)。

LABEL version="1.0"
LABEL location="New York" type="Data Center" role="Web Server"

LABEL 指令以 label="value" 的形式出現(xiàn)?？梢栽诿恳粭l指令中指定一個元數(shù)據(jù)，或者指定多個元數(shù)據(jù)，不同的元數(shù)據(jù)之間用空格分隔。推薦將所有的元數(shù)據(jù)都放到一條 LABEL 指令中，以防止不同的元數(shù)據(jù)指令創(chuàng)建過多鏡像層?？梢酝ㄟ^ docker inspect 命令來查看 Docker 鏡像中的標簽信息。

STOPSIGNAL

STOPSIGNAL 指令用來設置停止容器時發(fā)送什么系統(tǒng)調用信號給容器。這個信號必須是內(nèi)核系統(tǒng)調用表中合法的數(shù)，如 9，或者 SIGNAME 格式中的信號名稱，如SIGKILL。

COPY-復制文件

COPY <源路徑>... <目標路徑>
COPY ["<源路徑1>",... "<目標路徑>"]

COPY 指令將從構建上下文目錄中 <源路徑> 的文件或目錄復制到新的一層的鏡像內(nèi)的 <目標路徑> 位置。<源路徑> 可以是多個，甚至可以是通配符。<目標路徑> 可以是容器內(nèi)的絕對路徑，也可以是相對于工作目錄的相對路徑（工作目錄可以用 WORKDIR 指令來指定）。目標路徑不需要事先創(chuàng)建，如果目錄不存在會在復制文件前先行創(chuàng)建缺失目錄。

文件源路徑必須是一個與當前構建環(huán)境相對的文件或者目錄，本地文件都放到和Dockerfile 同一個目錄下。不能復制該目錄之外的任何文件，因為構建環(huán)境將會上傳到 Docker 守護進程，而復制是在Docker守護進程中進行的。任何位于構建環(huán)境之外的東西都是不可用的。

任何由該指令創(chuàng)建的文件或者目錄的 UID 和 GID 都會設置為0。

此外，還需要注意一點，使用 COPY 指令，源文件的各種元數(shù)據(jù)都會保留。比如讀、寫、執(zhí)行權限、文件變更時間等。這個特性對于鏡像定制很有用。特別是構建相關文件都在使用 Git 進行管理的時候。

ADD-更高級的復制文件

ADD 指令和 COPY 的格式和性質基本一致。但是在 COPY 基礎上增加了一些功能。

比如 <源路徑> 可以是一個 URL ，這種情況下，Docker 引擎會試圖去下載這個鏈接的文件放到 <目標路徑> 去。下載后的文件權限自動設置為 600 ，如果這并不是想要的權限，那么還需要增加額外的一層 RUN 進行權限調整，另外，如果下載的是個壓縮包，需要解壓縮，也一樣還需要額外的一層 RUN 指令進行解壓縮。所以不如直接使用 RUN 指令，然后使用 wget 或者 curl 工具下載，處理權限、解壓縮、然后清理無用文件更合理。因此，這個功能其實并不實用，而且不推薦使用。

如果 <源路徑> 為一個 tar 壓縮文件的話，壓縮格式為 gzip , bzip2 以及 xz 的情況下， ADD 指令將會自動解壓縮這個壓縮文件到 <目標路徑> 去。

在某些情況下，這個自動解壓縮的功能非常有用，但在某些情況下，如果我們真的是希望復制個壓縮文件進去，而不解壓縮，這時就不可以使用 ADD 命令了。

在 Docker 官方的 Dockerfile 最佳實踐文檔 中要求，盡可能的使用 COPY ，因為 COPY 的語義很明確，就是復制文件而已，而 ADD 則包含了更復雜的功能，其行為也不一定很清晰。最適合使用 ADD 的場合，就是所提及的需要自動解壓縮的場合。另外需要注意的是， ADD 指令會令鏡像構建緩存失效，從而可能會令鏡像構建變得比較緩慢。如果通過 ADD 指令向鏡像添加一個文件或者目錄，那么這將使 Dockerfile 中的后續(xù)指令都不能繼續(xù)使用之前的構建緩存。

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

如果目的位置不存在的話，Docker將會為我們創(chuàng)建這個全路徑，包括路徑中的任何目錄。所有拷貝到 container 中的文件和文件夾權限為 0755，uid 和 gid 為 0

ADD <src> <dest>  

1、 如果 src 是一個目錄，那么會將該目錄下的所有文件添加到 container 中，不包括目錄;
2、 如果文件是可識別的壓縮格式，則 docker 會幫忙解壓縮 ( 注意壓縮格式 );
3、 如果 src 是文件且 dest 中不使用斜杠結束，則會將 dest 視為文件，src 的內(nèi)容會寫入 dest;
4、 如果 src 是文件且 dest 中使用斜杠結束，則會 src 文件拷貝到 dest 目錄下;
5、 如果目的位置的目錄下已經(jīng)存在了和歸檔文件同名的文件或者目錄，那么目的位置中的文件或者目錄不會被覆蓋。

VOLUME-定義匿名卷

之前我們說過，容器運行時應該盡量保持容器存儲層不發(fā)生寫操作，對于數(shù)據(jù)庫類需要保存動態(tài)數(shù)據(jù)的應用，其數(shù)據(jù)庫文件應該保存于卷(volume)中。為了防止運行時用戶忘記將動態(tài)文件所保存目錄掛載為卷，在 Dockerfile 中，我們可以事先指定某些目錄掛載為匿名卷，這樣在運行時如果用戶不指定掛載，其應用也可以正常運行，不會向容器存儲層寫入大量數(shù)據(jù)。

VOLUME 指令用來向基于鏡像創(chuàng)建的容器添加卷。一個卷是可以存在于一個或者多個容器內(nèi)的特定的目錄，這個目錄可以繞過聯(lián)合文件系統(tǒng)，并提供如下共享數(shù)據(jù)或者對數(shù)據(jù)進行持久化的功能。

定義匿名卷后可以用 docker inspect 命令查找卷的存儲位置。

VOLUME [ "/var/lib/tomcat7/webapps/" ]

lemon@lemon-virtual-machine:~$ docker inspect sample(容器名)
"Mounts": [
            {
                "Type": "volume",
                "Name": "8196a0fd7c6ff72be08635a09f263a3be9d3496fb18fc660b2682b6b233ebbf8",
                "Source": "/var/lib/docker/volumes/8196a0fd7c6ff72be08635a09f263a3be9d3496fb18fc660b2682b6b233ebbf8/_data",
                "Destination": "/var/lib/tomcat7/webapps",
                "Driver": "local",
                "Mode": "",
                "RW": true,
                "Propagation": ""
            }
        ]

Source 后面的路徑就是容器掛在到宿主機的路徑，Destination 后面的路徑即容器中的目錄，也可以通過以下命令直接獲?。?/p>

lemon@lemon-virtual-machine:~$ docker inspect -f "{{ range .Mounts }}{{.}}{{end}}" sample
{volume 8196a0fd7c6ff72be08635a09f263a3be9d3496fb18fc660b2682b6b233ebbf8             /var/lib/docker/volumes/8196a0fd7c6ff72be08635a09f263a3be9d3496fb18fc660b2682b6b233ebbf8/_data 
    /var/lib/tomcat7/webapps 
    local  
    true }

卷功能可以將數(shù)據(jù)（如源代碼）、數(shù)據(jù)庫或者其他內(nèi)容添加到鏡像中而不是將這些內(nèi)容提交到鏡像中，并且允許我們在多個容器間共享這些內(nèi)容?？梢岳么斯δ軄頊y試容器和內(nèi)部的應用程序代碼，管理日志，或者處理容器內(nèi)部的數(shù)據(jù)庫。

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

# 例如
VOLUME /data

這里的 /data 目錄就會在運行時自動掛載為匿名卷，任何向 /data 中寫入的信息都不會記錄進容器存儲層，從而保證了容器存儲層的無狀態(tài)化。當然，運行時可以覆蓋這個掛載設置。比如：

docker run -d -v mydata:/data xxxx

在這行命令中，就使用了 mydata 這個命名卷掛載到了 /data 這個位置，替代了 Dockerfile 中定義的匿名卷的掛載配置。

WORKDIR-指定工作目錄

WORKDIR 指令是設置指令，可用于多次切換 ( 相當于 cd 命令 )

格式為 WORKDIR <工作目錄路徑>

WORKDIR 指令用來在從鏡像創(chuàng)建一個新容器時，在容器內(nèi)部設置一個工作目錄，ENTRYPOINT 和(或) CMD 指定的程序會在這個目錄下執(zhí)行?？梢允褂迷撝噶顬镈ockerfile 中后續(xù)的一系列指令設置工作目錄，也可以為最終的容器設置工作目錄。

使用 WORKDIR 指令可以來指定工作目錄（或者稱為當前目錄），以后各層的當前目錄就被改為指定的目錄，如該目錄不存在， WORKDIR 會幫你建立目錄。

之前提到一些初學者常犯的錯誤是把 Dockerfile 等同于 Shell 腳本來書寫，這種錯誤的理解還可能會導致出現(xiàn)下面這樣的錯誤：

RUN cd /app
RUN echo "hello" > world.txt

如果將這個 Dockerfile 進行構建鏡像運行后，會發(fā)現(xiàn)找不到 /app/world.txt 文件，或者其內(nèi)容不是 hello 。原因其實很簡單，在 Shell 中，連續(xù)兩行是同一個進程執(zhí)行環(huán)境，因此前一個命令修改的內(nèi)存狀態(tài)，會直接影響后一個命令；而在 Dockerfile 中，這兩行 RUN 命令的執(zhí)行環(huán)境根本不同，是兩個完全不同的容器。這就是對 Dockerfile 構建分層存儲的概念不了解所導致的錯誤。

之前說過每一個 RUN 都是啟動一個容器、執(zhí)行命令、然后提交存儲層文件變更。第一層 RUN cd /app 的執(zhí)行僅僅是當前進程的工作目錄變更，一個內(nèi)存上的變化而已，其結果不會造成任何文件變更。而到第二層的時候，啟動的是一個全新的容器，跟第一層的容器更完全沒關系，自然不可能繼承前一層構建過程中的內(nèi)存變化。

WORKDIR /opt/webapp/db
RUN bundle install
WORKDIR /opt/webapp
ENTRYPOINT [ "rackup" ]

這里，將工作目錄切換為 /opt/webapp/db 后運行了bundle install 命令，之后又將工作目錄設置為 /opt/webapp ，最后設置了 ENTRYPOINT指令來啟動 rackup 命令?？梢酝ㄟ^ -w 標志在運行時覆蓋工作目錄:

# 該命令會將容器內(nèi)的工作目錄設置為/var/log 。
$ sudo docker run -ti -w /var/log ubuntu pwd
/var/log

因此如果需要改變以后各層的工作目錄的位置，那么應該使用 WORKDIR 指令。

HEALTHCHECK 健康檢查

格式：

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

HEALTHCHECK 指令是告訴 Docker 應該如何進行判斷容器的狀態(tài)是否正常，這是 Docker 1.12 引入的新指令。

在沒有 HEALTHCHECK 指令前，Docker 引擎只可以通過容器內(nèi)主進程是否退出來判斷容器是否狀態(tài)異常。很多情況下這沒問題，但是如果程序進入死鎖狀態(tài)，或者死循環(huán)狀態(tài)，應用進程并不退出，但是該容器已經(jīng)無法提供服務了。在 1.12 以前，Docker 不會檢測到容器的這種狀態(tài)，從而不會重新調度，導致可能會有部分容器已經(jīng)無法提供服務了卻還在接受用戶請求。

而自 1.12 之后，Docker 提供了 HEALTHCHECK 指令，通過該指令指定一行命令，用這行命令來判斷容器主進程的服務狀態(tài)是否還正常，從而比較真實的反應容器實際狀態(tài)。

當在一個鏡像指定了 HEALTHCHECK 指令后，用其啟動容器，初始狀態(tài)會為 starting ，在 HEALTHCHECK 指令檢查成功后變?yōu)?healthy ，如果連續(xù)一定次數(shù)失敗，則會變?yōu)?unhealthy 。

HEALTHCHECK 支持下列選項：

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

和 CMD , ENTRYPOINT 一樣， HEALTHCHECK 只可以出現(xiàn)一次，如果寫了多個，只有最后一個生效。

在 HEALTHCHECK [選項] CMD 后面的命令，格式和 ENTRYPOINT 一樣，分為 shell 格式，和 exec 格式。命令的返回值決定了該次健康檢查的成功與否： 0 ：成功； 1 ：失??； 2 ：保留，不要使用這個值。

假設我們有個鏡像是個最簡單的 Web 服務，我們希望增加健康檢查來判斷其 Web 服務是否在正常工作，我們可以用 curl 來幫助判斷，其Dockerfile 的 HEALTHCHECK 可以這么寫：

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作為健康檢查命令。

使用 docker build 來構建這個鏡像：

$ docker build -t myweb:v1 .

構建好了后，我們啟動一個容器：

docker run -d --name web -p 80:80 myweb:v1

當運行該鏡像后，可以通過 docker ps 看到最初的狀態(tài)為 (health: starting)：

$ docker ps
CONTAINER ID IMAGE COMMAND CREATED S
TATUS PORTS NAMES
03e28eb00bd0 myweb:v1 "nginx -g 'daemon off" 3 seconds ago U
p 2 seconds (health: starting) 80/tcp, 443/tcp web

在等待幾秒鐘后，再次 docker ps ，就會看到健康狀態(tài)變化為了 (healthy)：

$ docker ps
CONTAINER ID IMAGE COMMAND CREATED S
TATUS PORTS NAMES
03e28eb00bd0 myweb:v1 "nginx -g 'daemon off" 18 seconds ago U
p 16 seconds (healthy) 80/tcp, 443/tcp web

如果健康檢查連續(xù)失敗超過了重試次數(shù)，狀態(tài)就會變?yōu)?(unhealthy) 。

為了幫助排障，健康檢查命令的輸出（包括 stdout 以及 stderr ）都會被存儲于健康狀態(tài)里，可以用 docker inspect 來查看。

ONBUILD-為他人做嫁衣裳

格式： ONBUILD <其它指令>

ONBUILD 是一個特殊的指令，它后面跟的是其它指令，比如 RUN , COPY 等，而這些指令，在當前鏡像構建時并不會被執(zhí)行。只有當以當前鏡像為基礎鏡像，去構建下一級鏡像的時候才會被執(zhí)行。

Dockerfile 中的其它指令都是為了定制當前鏡像而準備的，唯有 ONBUILD 是為了幫助別人定制自己而準備的。

假設我們要制作 Node.js 所寫的應用的鏡像。我們都知道 Node.js 使用 npm 進行包管理，所有依賴、配置、啟動信息等會放到 package.json 文件里。在拿到程序代碼后，需要先進行 npm install 才可以獲得所有需要的依賴。然后就可以通過 npm start 來啟動應用。因此，一般來說會這樣寫 Dockerfile ：

FROM node:slim
RUN mkdir /app
WORKDIR /app
COPY ./package.json /app
RUN [ "npm", "install" ]
COPY . /app/
CMD [ "npm", "start" ]

把這個 Dockerfile 放到 Node.js 項目的根目錄，構建好鏡像后，就可以直接拿來啟動容器運行。但是如果我們還有第二個 Node.js 項目也差不多呢？好吧，那就再把這個 Dockerfile 復制到第二個項目里。那如果有第三個項目呢？再復制么？文件的副本越多，版本控制就越困難，讓我們繼續(xù)看這樣的場景維護的問題。

如果第一個 Node.js 項目在開發(fā)過程中，發(fā)現(xiàn)這個 Dockerfile 里存在問題，比如敲錯字了、或者需要安裝額外的包，然后開發(fā)人員修復了這個 Dockerfile ，再次構建，問題解決。第一個項目沒問題了，但是第二個項目呢？雖然最初 Dockerfile 是復制、粘貼自第一個項目的，但是并不會因為第一個項目修復了他們的 Dockerfile ，而第二個項目的 Dockerfile 就會被自動修復。

那么我們可不可以做一個基礎鏡像，然后各個項目使用這個基礎鏡像呢？這樣基礎鏡像更新，各個項目不用同步 Dockerfile 的變化，重新構建后就繼承了基礎鏡像的更新？好吧，可以，讓我們看看這樣的結果。那么上面的這個 Dockerfile 就會變?yōu)椋?/p>

FROM node:slim
RUN mkdir /app
WORKDIR /app
CMD [ "npm", "start" ]

這里我們把項目相關的構建指令拿出來，放到子項目里去。假設這個基礎鏡像的名字為 my-node 的話，各個項目內(nèi)的自己的 Dockerfile 就變?yōu)椋?/p>

FROM my-node
COPY ./package.json /app
RUN [ "npm", "install" ]
COPY . /app/

基礎鏡像變化后，各個項目都用這個 Dockerfile 重新構建鏡像，會繼承基礎鏡像的更新。

那么，問題解決了么？沒有。準確說，只解決了一半。如果這個 Dockerfile 里面有些東西需要調整呢？比如 npm install 都需要加一些參數(shù)，那怎么辦？這一行 RUN 是不可能放入基礎鏡像的，因為涉及到了當前項目的 ./package.json ，難道又要一個個修改么？所以說，這樣制作基礎鏡像，只解決了原來的 Dockerfile 的前4條指令的變化問題，而后面三條指令的變化則完全沒辦法處理。

ONBUILD 可以解決這個問題。讓我們用 ONBUILD 重新寫一下基礎鏡像的 Dockerfile :

FROM node:slim
RUN mkdir /app
WORKDIR /app
ONBUILD COPY ./package.json /app
ONBUILD RUN [ "npm", "install" ]
ONBUILD COPY . /app/
CMD [ "npm", "start" ]

這次我們回到原始的 Dockerfile ，但是這次將項目相關的指令加上 ONBUILD ，這樣在構建基礎鏡像的時候，這三行并不會被執(zhí)行。然后各個項目的 Dockerfile 就變成了簡單地：

FROM my-node

是的，只有這么一行。當在各個項目目錄中，用這個只有一行的Dockerfile 構建鏡像時，之前基礎鏡像的那三行 ONBUILD 就會開始執(zhí)行，成功的將當前項目的代碼復制進鏡像、并且針對本項目執(zhí)行 npm install 生成應用鏡像。

ONBUILD 指令能為鏡像添加觸發(fā)器（trigger）。當一個鏡像被用做其他鏡像的基礎鏡像時（比如用戶的鏡像需要從某未準備好的位置添加觸發(fā)器會在構建過程中插入新指令，我們可以認為這些指令是緊跟在 FROM 之后指定的。源代碼，或者用戶需要執(zhí)行特定于構建鏡像的環(huán)境的構建腳本），該鏡像中的觸發(fā)器將會被執(zhí)行。

ONBUILD 觸發(fā)器會按照在父鏡像中指定的順序執(zhí)行，并且只能被繼承一次（也就是說只能在子鏡像中執(zhí)行，而不會在孫子鏡像中執(zhí)行）。

這里有好幾條指令是不能用在 ONBUILD 指令中的，包括 FROM 、MAINTAINER 和ONBUILD 本身。之所以這么規(guī)定是為了防止在 Dockerfile 構建過程中產(chǎn)生遞歸調用的問題。

構建鏡像

通過 Dockerfile 構建鏡像

-t選項指定鏡像名稱和版本號

docker build [選項] <上下文路徑/URL/->

docker build -t nginx:v3 .

如果注意，會看到 docker build 命令最后有一個 . 。 . 表示當前目錄，而 Dockerfile 就在當前目錄，因此不少初學者以為這個路徑是在指定 Dockerfile 所在路徑，這么理解其實是不準確的。如果對應上面的命令格式，你可能會發(fā)現(xiàn)，這是在指定上下文路徑。那么什么是上下文呢？

首先我們要理解 docker build 的工作原理。Docker 在運行時分為 Docker 引擎（也就是服務端守護進程）和客戶端工具。Docker 的引擎提供了一組 REST API，被稱為 Docker Remote API，而如 docker 命令這樣的客戶端工具，則是通過這組 API 與 Docker 引擎交互，從而完成各種功能。因此，雖然表面上我們好像是在本機執(zhí)行各種 docker 功能，但實際上，一切都是使用的遠程調用形式在服務端（Docker 引擎）完成。也因為這種 C/S 設計，讓我們操作遠程服務器的 Docker 引擎變得輕而易舉。

當我們進行鏡像構建的時候，并非所有定制都會通過 RUN 指令完成，經(jīng)常會需要將一些本地文件復制進鏡像，比如通過 COPY 指令、 ADD 指令等。而 docker build 命令構建鏡像，其實并非在本地構建，而是在服務端，也就是 Docker 引擎中構建的。那么在這種客戶端/服務端的架構中，如何才能讓服務端獲得本地文件呢？

這就引入了上下文的概念。當構建的時候，用戶會指定構建鏡像上下文的路徑， docker build 命令得知這個路徑后，會將路徑下的所有內(nèi)容打包，然后上傳給 Docker 引擎。這樣 Docker 引擎收到這個上下文包后，展開就會獲得構建鏡像所需的一切文件。

如果在 Dockerfile 中這么寫：

COPY ./package.json /app/

這并不是要復制執(zhí)行 docker build 命令所在的目錄下的 package.json ，也不是復制 Dockerfile 所在目錄下的 package.json ，而是復制 上下文（context） 目錄下的 package.json 。

因此， COPY 這類指令中的源文件的路徑都是相對路徑。這也是初學者經(jīng)常會問的為什么 COPY ../package.json /app 或者 COPY /opt/xxxx /app 無法工作的原因，因為這些路徑已經(jīng)超出了上下文的范圍，Docker 引擎無法獲得這些位置的文件。如果真的需要那些文件，應該將它們復制到上下文目錄中去。

現(xiàn)在就可以理解剛才的命令 docker build -t nginx:v3 . 中的這個 . ，實際上是在指定上下文的目錄， docker build 命令會將該目錄下的內(nèi)容打包交給 Docker 引擎以幫助構建鏡像。

如果觀察 docker build 輸出，我們其實已經(jīng)看到了這個發(fā)送上下文的過程：

$ docker build -t nginx:v3 .
Sending build context to Docker daemon 2.048 kB
...

理解構建上下文對于鏡像構建是很重要的，避免犯一些不應該的錯誤。比如有些初學者在發(fā)現(xiàn) COPY /opt/xxxx /app 不工作后，于是干脆將 Dockerfile 放到了硬盤根目錄去構建，結果發(fā)現(xiàn) docker build 執(zhí)行后，在發(fā)送一個幾十 GB 的東西，極為緩慢而且很容易構建失敗。那是因為這種做法是在讓 docker build 打包整個硬盤，這顯然是使用錯誤。

一般來說，應該會將 Dockerfile 置于一個空目錄下，或者項目根目錄下。如果該目錄下沒有所需文件，那么應該把所需文件復制一份過來。如果目錄下有些東西確實不希望構建時傳給 Docker 引擎，那么可以用 .gitignore 一樣的語法寫一個 .dockerignore ，該文件是用于剔除不需要作為上下文傳遞給 Docker 引擎的。

那么為什么會有人誤以為 . 是指定 Dockerfile 所在目錄呢？這是因為在默認情況下，如果不額外指定 Dockerfile 的話，會將上下文目錄下的名為 Dockerfile 的文件作為Dockerfile。

這只是默認行為，實際上 Dockerfile 的文件名并不要求必須為 Dockerfile，而且并不要求必須位于上下文目錄中，比如可以用 -f ../Dockerfile.php 參數(shù)指定某個文件作為 Dockerfile 。

當然，一般大家習慣性的會使用默認的文件名 Dockerfile ，以及會將其置于鏡像構建上下文目錄中。

構建緩存

FROM ubuntu
MAINTAINER Lemon "Lemon@example.com"
RUN apt-get update && apt-get install -y nginx
RUN echo 'Hi, I am in your container' \
    >/usr/share/nginx/html/index.html
EXPOSE 80

由于每一步的構建過程都會將結果提交為鏡像，所以 Docker 的構建鏡像過程就顯得非常聰明。它會將之前的鏡像層看作緩存。比如，在我們的調試例子里，我們不需要在第1步到第3步之間進行任何修改，因此 Docker 會將之前構建時創(chuàng)建的鏡像當做緩存并作為新的開始點。實際上，當再次進行構建時，Docker會直接從第4步開始。當之前的構建步驟沒有變化時，這會節(jié)省大量的時間。如果真的在第1步到第3步之間做了什么修改，Docker則會從第一條發(fā)生了變化的指令開始。然而，有些時候需要確保構建過程不會使用緩存。比如，如果已經(jīng)緩存了前面的第3步，即 apt-get update ，那么 Docker 將不會再次刷新 APT 包的緩存。這時用戶可能需要取得每個包的最新版本。要想略過緩存功能，可以使用 docker build 的 --no-cache 標志。

鏡像上傳

docker login # 此時會讓輸入用戶名和密碼
docker logout # 退出登錄
docker push youruser/yourimage # 上傳到遠程倉庫