Docker入門實踐之dokerfile編寫（2)

前面我介紹到dockerfile的經常使用的指令，本篇將繼續講到dockerfile相關指令。

1. CMD 容器啓動命令

CMD 指令的格式和 RUN 類似，也是兩種格式：

shell 格式：CMD <命令>
exec 格式：CMD ["可執行文件", "參數1", "參數2"...]

參數列表格式：CMD ["參數1", "參數2"...]。在指定了 ENTRYPOINT 指令後，用 CMD 指定具體的參數。

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 進行解析處理。提到 CMD 就不得不提容器中應用在前臺執行和後臺執行的問題。這是初學者常出現的一個混淆。

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;"]

2. EXPOSE 聲明對外映射端口

格式爲： EXPOSE <port> [<port>.....] 列如：

EXPOSE 22 80  8443

上述示例，申明docker應用服務須要暴露的端口，同時能夠在容器啓動的時能夠經過-P使容器主機隨機分配一個端口給指定的端口，使用-p能夠具體指定那個端口映射。

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

3. ENTRYPOINT 入口點

ENTRYPOINT 的格式和 RUN 指令格式同樣，分爲 exec 格式和 shell 格式。

ENTRYPOINT 的目的和 CMD 同樣，都是在指定容器啓動程序及參數。ENTRYPOINT 在運行時也能夠替代，不過比 CMD 要略顯繁瑣，須要經過 docker run 的參數 --entrypoint 來指定。當指定了 ENTRYPOINT 後，CMD 的含義就發生了改變，再也不是直接的運行其命令，而是將 CMD 的內容做爲參數傳給 ENTRYPOINT 指令，即：

<ENTRYPOINT> "<CMD>"

有了 CMD 後，爲啥還須要ENTRYPOINT，它們之間有什麼區別呢？以下示例所示：假設須要一個得知本身當前公網 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: container_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，從而達到了預期的結果。

4. HEALTHCHECK 健康檢查

格式：

HEALTHCHECK [選項] CMD <命令>：設置檢查容器健康情況的命令
HEALTHCHECK NONE：若是基礎鏡像有健康檢查指令，使用這行能夠屏蔽掉其健康檢查指令

HEALTHCHECK 指令是告訴 Docker 應該如何進行判斷容器的狀態是否正常，這是 Docker 1.12 引入的新指令。在沒有 HEALTHCHECK 指令前，Docker 引擎只能夠經過容器內主進程是否退出來判斷容器是否狀態異常。不少狀況下這沒問題，可是若是程序進入死鎖狀態，或者死循環狀態，應用進程並不退出，可是該容器已經沒法提供服務了。在 1.12 之前，Docker 不會檢測到容器的這種狀態，從而不會從新調度，致使可能會有部分容器已經沒法提供服務了卻還在接受用戶請求。而自 1.12 以後，Docker 提供了健康檢查指令，經過該指令指定一行命令，用這行命令來判斷容器主進程的服務狀態是否還正常，從而比較真實的反應容器實際狀態。當在一個鏡像指定了 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 container ls 看到最初的狀態爲 (health: starting)：

$ docker container ls
CONTAINER ID        IMAGE               COMMAND                  CREATED             STATUS                            PORTS               NAMES
03e28eb00bd0        myweb:v1            "nginx -g 'daemon off"   3 seconds ago       Up 2 seconds (health: starting)   80/tcp, 443/tcp     web

在等待幾秒鐘後，再次 docker container ls，就會看到健康狀態變化爲了 (healthy)：

$ docker container ls
CONTAINER ID        IMAGE               COMMAND                  CREATED             STATUS                    PORTS               NAMES
03e28eb00bd0        myweb:v1            "nginx -g 'daemon off"   18 seconds ago      Up 16 seconds (healthy)   80/tcp, 443/tcp     web

若是健康檢查連續失敗超過了重試次數，狀態就會變爲 (unhealthy)。爲了幫助排障，健康檢查命令的輸出（包括 stdout 以及 stderr）都會被存儲於健康狀態裏，能夠用 docker inspect 來查看。

$ docker inspect --format '{{json .State.Health}}' web | python -m json.tool
{
    "FailingStreak": 0,
    "Log": [
        {
            "End": "2016-11-25T14:35:37.940957051Z",
            "ExitCode": 0,
            "Output": "<!DOCTYPE html>\n<html>\n<head>\n<title>Welcome to nginx!</title>\n<style>\n    body {\n        width: 35em;\n        margin: 0 auto;\n        font-family: Tahoma, Verdana, Arial, sans-serif;\n    }\n</style>\n</head>\n<body>\n<h1>Welcome to nginx!</h1>\n<p>If you see this page, the nginx web server is successfully installed and\nworking. Further configuration is required.</p>\n\n<p>For online documentation and support please refer to\n<a href=\"http://nginx.org/\">nginx.org</a>.<br/>\nCommercial support is available at\n<a href=\"http://nginx.com/\">nginx.com</a>.</p>\n\n<p><em>Thank you for using nginx.</em></p>\n</body>\n</html>\n",
            "Start": "2016-11-25T14:35:37.780192565Z"
        }
    ],
    "Status": "healthy"
}

5. ONBUILD 爲他人作嫁衣裳

格式：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，生成應用鏡像。

6. ARG 構建參數

格式：ARG <參數名>[=<默認值>]

構建參數和 ENV 的效果同樣，都是設置環境變量。所不一樣的是，ARG 所設置的構建環境的環境變量，在未來容器運行時是不會存在這些環境變量的。可是不要所以就使用 ARG 保存密碼之類的信息，由於 docker history 仍是能夠看到全部值的。

Dockerfile 中的 ARG 指令是定義參數名稱，以及定義其默認值。該默認值能夠在構建命令 docker build 中用 --build-arg <參數名>=<值> 來覆蓋。在 1.13 以前的版本，要求 --build-arg 中的參數名，必須在 Dockerfile 中用 ARG 定義過了，換句話說，就是 --build-arg 指定的參數，必須在 Dockerfile 中使用了。若是對應參數沒有被使用，則會報錯退出構建。從 1.13 開始，這種嚴格的限制被放開，再也不報錯退出，而是顯示警告信息，並繼續構建。這對於使用 CI 系統，用一樣的構建流程構建不一樣的 Dockerfile 的時候比較有幫助，避免構建命令必須根據每一個 Dockerfile 的內容修改。