2020-04-06
Dockerfilecd
mkdir static_web
cd static_web
touch Dockerfile
我們建立了一個名爲 static_web 的目錄用來儲存 Dockerfile ，這個目錄就是我們的構建環境（build environment），Docker 則稱此環境爲上下午（context）或者構建上下文（build context）。Docker 會在構建映象時將構建上下文和該上下文中的檔案和目錄上傳到 Docker 守護行程。這樣 Docker 守護行程就能直接存取使用者想在映象中儲存的任何程式碼、檔案或者其他數據。
使用 docker commit 命令雖然可以比較直觀的幫助理解映象分層儲存的概念，但是實際環境中並不會這樣使用。
首先，如果仔細觀察之前的 docker diff webserver 的結果，你會發現除了真正想要修改的/usr/share/nginx/html/index.html 檔案外，由於命令的執行，還有很多檔案被改動或新增了。這還僅僅是最簡單的操作，如果是安裝軟體包、編譯構建，那會有大量的無關內容被新增進來，如果不小心清理，將會導致映象極爲臃腫。
此外，使用 docker commit 意味着所有對映象的操作都是黑箱操作，生成的映象也被稱爲黑箱映象，換句話說，就是除了製作映象的人知道執行過什麼命令、怎麼生成的映象，別人根本無從得知。而且，即使是這個製作映象的人，過一段時間後也無法記清具體在操作的。雖然 docker diff 或許可以告訴得到一些線索，但是遠遠不到可以確保生成一致映象的地步。這種黑箱映象的維護工作是非常痛苦的。
而且，回顧之前提及的映象所使用的分層儲存的概念，除當前層外，之前的每一層都是不會發生改變的，換句話說，任何修改的結果僅僅是在當前層進行標記、新增、修改，而不會改動上一層。如果使用 docker commit 製作映象，以及後期修改的話，每一次修改都會讓映象更加臃腫一次，所刪除的上一層的東西並不會丟失，會一直如影隨形的跟着這個映象，即使根本無法存取到。這會讓映象更加臃腫。
映象的定製實際上就是定製每一層所新增的設定、檔案。如果我們可以把每一層修改、安裝、構建、操作的命令都寫入一個指令碼，用這個指令碼來構建、定製映象，那麼之前提及的無法重複的問題、映象構建透明性的問題、體積的問題就都會解決。這個指令碼就是 Dockerfile。
Dockerfile 是一個文字檔案，其內包含了一條條的指令(Instruction)，每一條指令構建一層，因此每一條指令的內容，就是描述該層應當如何構建。
所謂定製映象，那一定是以一個映象爲基礎，在其上進行定製。基礎映象是必須指定的。
FROM <image> # 指定基礎 image 爲該 image 的最後修改的版本
FROM <image>:<tag> # 指定基礎 image 爲該 image 的一個 tag 版本
# 例如
FROM python:3.6.5
除了選擇現有映象爲基礎映象外，Docker 還存在一個特殊的映象，名爲
scratch。這個映象是虛擬的概念，並不實際存在，它表示一個空白的映象。如果你以 scratch 爲基礎映象的話，意味着你不以任何映象爲基礎，接下來所寫的指令將作爲映象第一層開始存在。
MAINTAINER <name>
# 例如
FROM python:3.6.5
MAINTAINER ycbbs
- 如果基礎 image 選擇了 ubuntu，那麼軟體管理部分只能使用 ubuntu 的命令
- 如果基礎 image 選擇了 centos，那麼軟體管理部分職能使用 centos 的命令
# 兩種方式
# 1. shell格式： 就像直接在命令列中輸入的命令一樣。
RUN <command>
# 2. exec 格式：更像是函數呼叫中的格式。
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）的過程一樣：新建立一層，在其上執行這些命令，執行結束後， commit 這一層的修改，構成新的映象。
而上面的這種寫法，建立了 7 層映象。這是完全沒有意義的，而且很多執行時不需要的東西，都被裝進了映象裡，比如編譯環境、更新的軟體包等等。結果就是產生非常臃腫、非常多層的映象，不僅僅增加了構建部署的時間，也很容易出錯。
Union FS 是有最大層數限制的，比如 AUFS，曾經是最大不得超過 42 層，現在是不得超過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 可執行檔案。因此沒有必要建立很多層，這只是一層的事情。因此，這裏沒有使用很多個 RUN 對一一對應不同的命令，而是僅僅使用一個 RUN 指令，並使用 && 將各個所需命令串聯起來。將之前的 7 層，簡化爲了1 層。在撰寫 Dockerfile 的時候，要經常提醒自己，這並不是在寫 Shell 指令碼，而是在定義每一層該如何構建。並且，這裏爲了格式化還進行了換行。
Dockerfile 支援 Shell 類的行尾新增 \ 的命令換行方式，以及行首 # 進行註釋的格式。良好的格式，比如換行、縮排、註釋等，會讓維護、排障更爲容易，這是一個比較好的習慣。
此外，還可以看到這一組命令的最後新增了清理工作的命令，刪除了爲了編譯構建所需要的軟體，清理了所有下載、展開的檔案，並且還清理了 apt 快取檔案。這是很重要的一步，我們之前說過，映象是多層儲存，每一層的東西並不會在下一層被刪除，會一直跟隨着映象。因此映象構建時，一定要確保每一層只新增真正需要新增的東西，任何無關的東西都應該清理掉。
Docker 不是虛擬機器，容器就是進程。既然是進程，那麼在啓動容器的時候，需要指定所執行的程式及參數。 CMD 指令就是用於指定預設的容器主進程的啓動命令的。
在執行時可以指定新的命令來替代映象設定中的這個預設命令，比如， ubuntu 映象預設的CMD 是 /bin/bash ，如果我們直接 docker run -it ubuntu 的話，會直接進入 bash 。我們也可以在執行時指定執行別的命令，如 docker run -it ubuntu cat /etc/os-release 。這就是用 cat /etc/os-release 命令替換了預設的 /bin/bash 命令了，輸出了系統版本資訊。
在指令格式上，一般推薦使用 exec 格式，這類格式在解析時會被解析爲 JSON 陣列，因此一定要使用雙引號 " ，而不要使用單引號。
如果使用 shell 格式的話，實際的命令會被包裝爲 sh -c 的參數的形式進行執行。比如：
CMD echo $HOME
在實際執行中，會將其變更爲：
CMD [ "sh", "-c", "echo $HOME" ]
這就是爲什麼我們可以使用環境變數的原因，因爲這些環境變數會被 shell 進行解析處理。
Docker 不是虛擬機器，容器中的應用都應該以前臺執行，而不是像虛擬機器、物理機裏面那樣，用 upstart/systemd 去啓動後臺服務，容器內沒有後台服務的概念。
一些初學者將 CMD 寫爲：
CMD service nginx start
然後發現容器執行後就立即退出了。甚至在容器內去使用 systemctl 命令結果卻發現根本執行不了。這就是因爲沒有搞明白前臺、後臺的概念，沒有區分容器和虛擬機器的差異，依舊在以傳統虛擬機器的角度去理解容器。
對於容器而言，其啓動程式就是容器應用進程，容器就是爲了主進程而存在的，主進程退出，容器就失去了存在的意義，從而退出，其它輔助進程不是它需要關心的東西。
而使用 service nginx start 命令，則是希望 upstart 來以後台守護行程形式啓動 nginx 服務。而剛纔說了 CMD service nginx start 會被理解爲 CMD [ "sh", "-c", "service nginx start"] ，因此主進程實際上是 sh 。那麼當 service nginx start 命令結束後， sh 也就結束了， sh 作爲主進程退出了，自然就會令容器退出。
正確的做法是直接執行 nginx 可執行檔案，並且要求以前臺形式執行。比如：
CMD ["nginx", "-g", "daemon off;"]
CMD 指令是設定指令，用於設定容器 ( container ) 啓動時執行的操作CMD 指令用於 container 啓動時指定的操作。該操作可以是執行自定義指令碼，也可以是執行系統命令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 指定的是一個可執行的指令碼或者程式的路徑，該指定的指令碼或者程式將會以 param1 和 param2 作爲參數執行
所以如果 CMD 指令使用第三種格式，那麼 Dockerfile 中必須要有配套的 ENTRYPOINT
ENTRYPOINT 的格式和 RUN 指令格式一樣，分爲 exec 格式和 shell 格式。
# 兩種方式
ENTRYPOINT ["executable", "param1", "param2"]
ENTRYPOINT command param1 param2
ENTRYPOINT 的目的和 CMD 一樣，都是在指定容器啓動程式及參數。 ENTRYPOINT 在執行時也可以替代，不過比 CMD 要略顯繁瑣，需要通過 docker run 的參數 --entrypoint 來指定。
當指定了 ENTRYPOINT 後， CMD 的含義就發生了改變，不再是直接的執行其命令，而是將CMD 的內容作爲參數傳給 ENTRYPOINT 指令，換句話說實際執行時，將變爲：
<ENTRYPOINT> "<CMD>"
那麼有了 CMD 後，爲什麼還要有 ENTRYPOINT 呢？這種<ENTRYPOINT> "<CMD>" 有什麼好處麼？讓我們來看幾個場景。
假設我們需要一個得知自己當前公網 IP 的映象，那麼可以先用 CMD 來實現：
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 . 來構建映象的話，如果我們需要查詢當前公網 IP，只需要執行：
$ docker run myip
當前 IP：61.148.226.66 來自：北京市 聯通
嗯，這麼看起來好像可以直接把映象當做命令使用了，不過命令總有參數，如果我們希望加參數呢？比如從上面的 CMD 中可以看到實質的命令是 curl ，那麼如果我們希望顯示 HTTP 頭資訊，就需要加上 -i 參數。那麼我們可以直接加 -i 參數給 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".
我們可以看到可執行檔案找不到的報錯， executable file not found 。之前我們說過，跟在映象名後面的是 command ，執行時會替換 CMD 的預設值。因此這裏的 -i 替換了原來的 CMD ，而不是新增在原來的 curl -s http://ip.cn 後面。而 -i 根本不是命令，所以自然找不到。
那麼如果我們希望加入 -i 這參數，我們就必須重新完整的輸入這個命令：
docker run myip curl -s http://ip.cn -i
這顯然不是很好的解決方案，而使用 ENTRYPOINT 就可以解決這個問題。現在我們重新用 ENTRYPOINT 來實現這個映象：
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 來自：北京市 聯通
$ 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 來自：北京市 聯通
可以看到，這次成功了。這是因爲當存在 ENTRYPOINT 後， CMD 的內容將會作爲參數傳給 ENTRYPOINT ，而這裏 -i 就是新的 CMD ，因此會作爲參數傳給 curl ，從而達到了我們預期的效果。
啓動容器就是啓動主進程，但有些時候，啓動主進程前，需要一些準備工作。
比如 mysql 類的數據庫，可能需要一些數據庫設定、初始化的工作，這些工作要在最終的 mysql 伺服器執行之前解決。
此外，可能希望避免使用 root 使用者去啓動服務，從而提高安全性，而在啓動服務前還需要以 root 身份執行一些必要的準備工作，最後切換到服務使用者身份啓動服務。或者除了服務外，其它命令依舊可以使用 root 身份執行，方便偵錯等。
這些準備工作是和容器 CMD 無關的，無論 CMD 是什麼，都需要事先進行一個預處理的工作。這種情況下，可以寫一個指令碼，然後放入ENTRYPOINT 中去執行，而這個指令碼會將接到的參數（也就是 <CMD>）作爲命令，在指令碼最後執行。比如官方映象 redis 中就是這麼做的：
FROM alpine:3.4
...
RUN addgroup -S redis && adduser -S -G redis redis
...
ENTRYPOINT ["docker-entrypoint.sh"]
EXPOSE 6379
CMD [ "redis-server" ]
可以看到其中爲了 redis 服務建立了 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 "$@"
該指令碼的內容就是根據 CMD 的內容來判斷，如果是 redis-server 的話，則切換到 redis 使用者身份啓動伺服器，否則依舊使用 root 身份執行。比如：
$ docker run -it redis id
uid=0(root) gid=0(root) groups=0(root)
USER 是設定指令，用於設定執行容器 ( container ) 的使用者，預設是 root
格式： USER <使用者名稱>
USER 指令和 WORKDIR 相似，都是改變環境狀態並影響以後的層。 WORKDIR 是改變工作目錄， USER 則是改變之後層的執行， RUN ，CMD 以及 ENTRYPOINT 這類命令的身份。
當然，和 WORKDIR 一樣， USER 只是幫助你切換到指定使用者而已，這個使用者必須是事先建立好的，否則無法切換。
RUN groupadd -r redis && useradd -r -g redis redis
USER redis
RUN [ "redis-server" ]
如果以 root 執行的指令碼，在執行期間希望改變身份，比如希望以某個已經建立好的使用者來執行某個服務進程，不要使用 su 或者 sudo ，這些都需要比較麻煩的設定，而且在 TTY 缺失的環境下經常出錯。建議使用 gosu 。
# 建立 redis 使用者，並使用 gosu 換另一個使用者執行命令
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，並以另外的使用者執行
CMD [ "exec", "gosu", "redis", "redis-server" ]
格式爲 EXPOSE <埠1> [<埠2>...]
EXPOSE 指令是宣告執行時容器提供伺服器端口，這只是一個宣告，在執行時並不會因爲這個宣告應用就會開啓這個埠的服務。在 Dockerfile 中寫入這樣的宣告有兩個好處，一個是幫助映象使用者理解這個映象服務的守護埠，以方便設定對映；另一個用處則是在執行時使用隨機埠對映時，也就是 docker run -P 時，會自動隨機對映 EXPOSE 的埠。
此外，在早期 Docker 版本中還有一個特殊的用處。以前所有容器都執行於預設橋接網路中，因此所有容器互相之間都可以直接存取，這樣存在一定的安全性問題。於是有了一個 Docker 引擎參數 --icc=false ，當指定該參數後，容器間將預設無法互訪，除非互相間使用了 --links 參數的容器纔可以互通，並且只有映象中 EXPOSE 所宣告的埠纔可以被存取。這個 --icc=false 的用法，在引入了 docker network 後已經基本不用了，通過自定義網路可以很輕鬆的實現容器間的互聯與隔離。
要將 EXPOSE 和在執行時使用 -p <宿主埠>:<容器埠> 區分開來。 -p ，是對映宿主埠和容器埠，換句話說，就是將容器的對應埠服務公開給外界存取，而 EXPOSE 僅僅是宣告容器打算使用什麼埠而已，並不會自動在宿主進行埠對映。
# 格式有兩種：
ENV <key> <value>
ENV <key1>=<value1> <key2>=<value2>...
這個指令很簡單，就是設定環境變數而已，無論是後面的其它指令，如 RUN ，還是執行時的應用，都可以直接使用這裏定義的環境變數。
容器啓動後，可以通過 docker inspect 檢視這個環境變數
也可以通過在 docker run --env key=value 時設定或修改環境變數
假如我們安裝了 JAVA 程式，需要設定 JAVA_HOME 那麼可以在 Dockerfile 中這樣寫
ENV JAVA_HOME /path/to/java/dirent
格式： ARG <參數名>[=<預設值>]
構建參數和 ENV 的效果一樣，都是設定環境變數。所不同的是， ARG 所設定的構建環境的環境變數，在將來容器執行時是不會存在這些環境變數的。但是不要因此就使用 ARG 儲存密碼之類的資訊，因爲 docker history 還是可以看到所有值的。
Dockerfile 中的 ARG 指令是定義參數名稱，以及定義其預設值。該預設值可以在構建命令 docker build 中用 --build-arg <參數名>=<值> 來覆蓋。
COPY <源路徑>... <目標路徑>
COPY ["<源路徑1>",... "<目標路徑>"]
COPY 指令將從構建上下文目錄中 <源路徑> 的檔案或目錄複製到新的一層的映象內的 <目標路徑> 位置。<源路徑> 可以是多個，甚至可以是萬用字元。<目標路徑> 可以是容器內的絕對路徑，也可以是相對於工作目錄的相對路徑（工作目錄可以用 WORKDIR 指令來指定）。目標路徑不需要事先建立，如果目錄不存在會在複製檔案前先行建立缺失目錄。
此外，還需要注意一點，使用 COPY 指令，原始檔的各種元數據都會保留。比如讀、寫、執行許可權、檔案變更時間等。這個特性對於映象定製很有用。特別是構建相關檔案都在使用 Git 進行管理的時候。
ADD 指令和 COPY 的格式和性質基本一致。但是在 COPY 基礎上增加了一些功能。
比如 <源路徑> 可以是一個 URL ，這種情況下，Docker 引擎會試圖去下載這個鏈接的檔案放到 <目標路徑> 去。下載後的檔案許可權自動設定爲 600 ，如果這並不是想要的許可權，那麼還需要增加額外的一層 RUN 進行許可權調整，另外，如果下載的是個壓縮包，需要解壓縮，也一樣還需要額外的一層 RUN 指令進行解壓縮。所以不如直接使用 RUN 指令，然後使用 wget 或者 curl 工具下載，處理許可權、解壓縮、然後清理無用檔案更合理。因此，這個功能其實並不實用，而且不推薦使用。
如果 <源路徑> 爲一個 tar 壓縮檔案的話，壓縮格式爲 gzip , bzip2 以及 xz 的情況下， ADD 指令將會自動解壓縮這個壓縮檔案到 <目標路徑> 去。
在某些情況下，這個自動解壓縮的功能非常有用，但在某些情況下，如果我們真的是希望複製個壓縮檔案進去，而不解壓縮，這時就不可以使用 ADD 命令了。
在 Docker 官方的
Dockerfile最佳實踐文件 中要求，儘可能的使用COPY，因爲COPY的語意很明確，就是複製檔案而已，而ADD則包含了更復雜的功能，其行爲也不一定很清晰。最適合使用ADD的場合，就是所提及的需要自動解壓縮的場合。另外需要注意的是，ADD指令會令映象構建快取失效，從而可能會令映象構建變得比較緩慢。
因此在 COPY 和 ADD 指令中選擇的時候，可以遵循這樣的原則，所有的檔案複製均使用 COPY 指令，僅在需要自動解壓縮的場合使用 ADD。
所有拷貝到 container 中的檔案和資料夾許可權爲 0755，uid 和 gid 爲 0
ADD <src> <dest>
1、 如果 src 是一個目錄，那麼會將該目錄下的所有檔案新增到 container 中，不包括目錄
2、 如果檔案是可識別的壓縮格式，則 docker 會幫忙解壓縮 ( 注意壓縮格式 )
3、 如果 src 是檔案且 dest 中不使用斜槓結束，則會將 dest 視爲檔案，src 的內容會寫入 dest
4、 如果 src 是檔案且 dest 中使用斜槓結束，則會 src 檔案拷貝到 dest 目錄下
之前我們說過，容器執行時應該儘量保持容器儲存層不發生寫操作，對於數據庫類需要儲存動態數據的應用，其數據庫檔案應該儲存於卷(volume)中。爲了防止執行時使用者忘記將動態檔案所儲存目錄掛載爲卷，在 Dockerfile 中，我們可以事先指定某些目錄掛載爲匿名卷，這樣在執行時如果使用者不指定掛載，其應用也可以正常執行，不會向容器儲存層寫入大量數據。
# 格式
VOLUME ["<路徑1>", "<路徑2>"...]
VOLUME <路徑>
# 例如
VOLUME /data
這裏的 /data 目錄就會在執行時自動掛載爲匿名卷，任何向 /data 中寫入的資訊都不會記錄進容器儲存層，從而保證了容器儲存層的無狀態化。當然，執行時可以覆蓋這個掛載設定。比如：
docker run -d -v mydata:/data xxxx
在這行命令中，就使用了 mydata 這個命名卷掛載到了 /data 這個位置，替代了 Dockerfile 中定義的匿名卷的掛載設定。
WORKDIR 指令是設定指令，可用於多次切換 ( 相當於 cd 命令 )
格式爲 WORKDIR <工作目錄路徑>
使用 WORKDIR 指令可以來指定工作目錄（或者稱爲當前目錄），以後各層的當前目錄就被改爲指定的目錄，如該目錄不存在， WORKDIR 會幫你建立目錄。
之前提到一些初學者常犯的錯誤是把 Dockerfile 等同於 Shell 指令碼來書寫，這種錯誤的理解還可能會導致出現下面 下麪這樣的錯誤：
RUN cd /app
RUN echo "hello" > world.txt
如果將這個 Dockerfile 進行構建映象執行後，會發現找不到 /app/world.txt 檔案，或者其內容不是 hello 。原因其實很簡單，在 Shell 中，連續兩行是同一個進程執行環境，因此前一個命令修改的記憶體狀態，會直接影響後一個命令；而在 Dockerfile 中，這兩行 RUN 命令的執行環境根本不同，是兩個完全不同的容器。這就是對 Dockerfile 構建分層儲存的概念不瞭解所導致的錯誤。
之前說過每一個 RUN 都是啓動一個容器、執行命令、然後提交儲存層檔案變更。第一層 RUN cd /app 的執行僅僅是當前進程的工作目錄變更，一個記憶體上的變化而已，其結果不會造成任何檔案變更。而到第二層的時候，啓動的是一個全新的容器，跟第一層的容器更完全沒關係，自然不可能繼承前一層構建過程中的記憶體變化。
因此如果需要改變以後各層的工作目錄的位置，那麼應該使用 WORKDIR 指令。
格式：
HEALTHCHECK [選項] CMD <命令> ：設定檢查容器健康狀況的命令HEALTHCHECK NONE ：如果基礎映象有健康檢查指令，使用這行可以遮蔽掉其健康檢查指令HEALTHCHECK 指令是告訴 Docker 應該如何進行判斷容器的狀態是否正常，這是 Docker 1.12 引入的新指令。
在沒有 HEALTHCHECK 指令前，Docker 引擎只可以通過容器內主進程是否退出來判斷容器是否狀態異常。很多情況下這沒問題，但是如果程式進入死鎖狀態，或者死回圈狀態，應用進程並不退出，但是該容器已經無法提供服務了。在 1.12 以前，Docker 不會檢測到容器的這種狀態，從而不會重新排程，導致可能會有部分容器已經無法提供服務了卻還在接受使用者請求。
而自 1.12 之後，Docker 提供了 HEALTHCHECK 指令，通過該指令指定一行命令，用這行命令來判斷容器主進程的服務狀態是否還正常，從而比較真實的反應容器實際狀態。
當在一個映象指定了 HEALTHCHECK 指令後，用其啓動容器，初始狀態會爲 starting ，在 HEALTHCHECK 指令檢查成功後變爲 healthy ，如果連續一定次數失敗，則會變爲 unhealthy 。
HEALTHCHECK 支援下列選項：
--interval=<間隔> ：兩次健康檢查的間隔，預設爲 30 秒；--timeout=<時長> ：健康檢查命令執行超時時間，如果超過這個時間，本次健康檢查就被視爲失敗，預設 30 秒；--retries=<次數> ：當連續失敗指定次數後，則將容器狀態視爲 unhealthy ，預設 3 次。和 CMD , ENTRYPOINT 一樣， HEALTHCHECK 只可以出現一次，如果寫了多個，只有最後一個生效。
在 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 看到最初的狀態爲 (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 ，就會看到健康狀態變化爲了 (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
如果健康檢查連續失敗超過了重試次數，狀態就會變爲 (unhealthy) 。
爲了幫助排障，健康檢查命令的輸出（包括 stdout 以及 stderr ）都會被儲存於健康狀態裡，可以用 docker inspect 來檢視。
格式： ONBUILD <其它指令>
ONBUILD 是一個特殊的指令，它後面跟的是其它指令，比如 RUN , COPY 等，而這些指令，在當前映象構建時並不會被執行。只有當以當前映象爲基礎映象，去構建下一級映象的時候纔會被執行。
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 複製到第二個專案裡。那如果有第三個專案呢？再複製麼？檔案的副本越多，版本控制就越困難，讓我們繼續看這樣的場景維護的問題。
如果第一個 Node.js 專案在開發過程中，發現這個 Dockerfile 裡存在問題，比如敲錯字了、或者需要安裝額外的包，然後開發人員修復了這個 Dockerfile ，再次構建，問題解決。第一個專案沒問題了，但是第二個專案呢？雖然最初 Dockerfile 是複製、貼上自第一個專案的，但是並不會因爲第一個專案修復了他們的 Dockerfile ，而第二個專案的 Dockerfile 就會被自動修復。
那麼我們可不可以做一個基礎映象，然後各個專案使用這個基礎映象呢？這樣基礎映象更新，各個專案不用同步 Dockerfile 的變化，重新構建後就繼承了基礎映象的更新？好吧，可以，讓我們看看這樣的結果。那麼上面的這個 Dockerfile 就會變爲：
FROM node:slim
RUN mkdir /app
WORKDIR /app
CMD [ "npm", "start" ]
這裏我們把專案相關的構建指令拿出來，放到子專案裡去。假設這個基礎映象的名字爲 my-node 的話，各個專案內的自己的 Dockerfile 就變爲：
FROM my-node
COPY ./package.json /app
RUN [ "npm", "install" ]
COPY . /app/
基礎映象變化後，各個專案都用這個 Dockerfile 重新構建映象，會繼承基礎映象的更新。
那麼，問題解決了麼？沒有。準確說，只解決了一半。如果這個 Dockerfile 裏面有些東西需要調整呢？比如 npm install 都需要加一些參數，那怎麼辦？這一行 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 ，這樣在構建基礎映象的時候，這三行並不會被執行。然後各個專案的 Dockerfile 就變成了簡單地：
FROM my-node
是的，只有這麼一行。當在各個專案目錄中，用這個只有一行的Dockerfile 構建映象時，之前基礎映象的那三行 ONBUILD 就會開始執行，成功的將當前專案的程式碼複製進映象、並且針對本專案執行 npm install ，生成應用映象。
通過 Dockerfile 構建映象
-t選項指定映象名稱和版本號
docker build [選項] <上下文路徑/URL/->
docker build -t nginx:v3 .
如果注意，會看到 docker build 命令最後有一個 . 。 . 表示當前目錄，而 Dockerfile 就在當前目錄，因此不少初學者以爲這個路徑是在指定 Dockerfile 所在路徑，這麼理解其實是不準 不準確的。如果對應上面的命令格式，你可能會發現，這是在指定上下文路徑。那麼什麼是上下文呢？
首先我們要理解 docker build 的工作原理。Docker 在執行時分爲 Docker 引擎（也就是伺服器端守護行程）和用戶端工具。Docker 的引擎提供了一組 REST API，被稱爲 Docker Remote API，而如 docker 命令這樣的用戶端工具，則是通過這組 API 與 Docker 引擎互動，從而完成各種功能。因此，雖然表面上我們好像是在本機執行各種 docker 功能，但實際上，一切都是使用的遠端呼叫形式在伺服器端（Docker 引擎）完成。也因爲這種 C/S 設計，讓我們操作遠端伺服器的 Docker 引擎變得輕而易舉。
當我們進行映象構建的時候，並非所有定製都會通過 RUN 指令完成，經常會需要將一些本地檔案複製進映象，比如通過 COPY 指令、 ADD 指令等。而 docker build 命令構建映象，其實並非在本地構建，而是在伺服器端，也就是 Docker 引擎中構建的。那麼在這種用戶端/伺服器端的架構中，如何才能 纔能讓伺服器端獲得本地檔案呢？
這就引入了上下文的概念。當構建的時候，使用者會指定構建映象上下文的路徑， docker build 命令得知這個路徑後，會將路徑下的所有內容打包，然後上傳給 Docker 引擎。這樣 Docker 引擎收到這個上下文包後，展開就會獲得構建映象所需的一切檔案。
如果在 Dockerfile 中這麼寫：
COPY ./package.json /app/
這並不是要複製執行 docker build 命令所在的目錄下的 package.json ，也不是複製 Dockerfile 所在目錄下的 package.json ，而是複製 上下文（context） 目錄下的 package.json 。
因此， COPY 這類指令中的原始檔的路徑都是相對路徑。這也是初學者經常會問的爲什麼 COPY ../package.json /app 或者 COPY /opt/xxxx /app 無法運作的原因，因爲這些路徑已經超出了上下文的範圍，Docker 引擎無法獲得這些位置的檔案。如果真的需要那些檔案，應該將它們複製到上下文目錄中去。
現在就可以理解剛纔的命令 docker build -t nginx:v3 . 中的這個 . ，實際上是在指定上下文的目錄， docker build 命令會將該目錄下的內容打包交給 Docker 引擎以幫助構建映象。
如果觀察 docker build 輸出，我們其實已經看到了這個發送上下文的過程：
$ docker build -t nginx:v3 .
Sending build context to Docker daemon 2.048 kB
...
理解構建上下文對於映象構建是很重要的，避免犯一些不應該的錯誤。比如有些初學者在發現 COPY /opt/xxxx /app 不工作後，於是乾脆將 Dockerfile 放到了硬碟根目錄去構建，結果發現 docker build 執行後，在發送一個幾十 GB 的東西，極爲緩慢而且很容易構建失敗。那是因爲這種做法是在讓 docker build 打包整個硬碟，這顯然是使用錯誤。
一般來說，應該會將 Dockerfile 置於一個空目錄下，或者專案根目錄下。如果該目錄下沒有所需檔案，那麼應該把所需檔案複製一份過來。如果目錄下有些東西確實不希望構建時傳給 Docker 引擎，那麼可以用 .gitignore 一樣的語法寫一個 .dockerignore ，該檔案是用於剔除不需要作爲上下文傳遞給 Docker 引擎的。
那麼爲什麼會有人誤以爲 . 是指定 Dockerfile 所在目錄呢？這是因爲在預設情況下，如果不額外指定 Dockerfile 的話，會將上下文目錄下的名爲 Dockerfile 的檔案作爲Dockerfile。
這只是預設行爲，實際上 Dockerfile 的檔名並不要求必須爲 Dockerfile，而且並不要求必須位於上下文目錄中，比如可以用 -f ../Dockerfile.php 參數指定某個檔案作爲 Dockerfile 。
當然，一般大家習慣性的會使用預設的檔名 Dockerfile ，以及會將其置於映象構建上下文目錄中。
docker login # 此時會讓輸入使用者名稱和密碼
docker logout # 退出登錄
docker push # 上傳到遠端倉庫