2019獨角獸企業(yè)重金招聘Python工程師標準>>>

我們已經(jīng)介紹了 FROM （指定基礎(chǔ)鏡像） ， RUN（執(zhí)行命令） ，還提及了 COPY , ADD ，其實 Dockerfile 功能很強大，它提供了十多個指令。下面我們繼續(xù)講解其他的指令。

COPY 復(fù)制文件

COPY 指令將從構(gòu)建上下文目錄中 <源路徑> 的文件/目錄復(fù)制到新的一層的鏡像內(nèi)的 <目標路徑> 位置。 格式： COPY <源路徑>... <目標路徑> COPY ["<源路徑1>",... "<目標路徑>"] 和 RUN 指令一樣，也有兩種格式，一種類似于命令行，一種類似于函數(shù)調(diào)用。比如： COPY package.json /usr/src/app/ <源路徑> 可以是多個，甚至可以是通配符，其通配符規(guī)則要滿足 Go 的 filepath.Match 規(guī)則，如： COPY hom* /mydir/ COPY hom?.txt /mydir/ <目標路徑> 可以是容器內(nèi)的絕對路徑，也可以是相對于工作目錄的相對路徑（工作目錄可以用 WORKDIR 指令來指定）。目標路徑不需要事先創(chuàng)建，如果目錄不存在會在復(fù)制文件前先行創(chuàng)建缺失目錄。 此外，還需要注意一點，使用 COPY 指令，源文件的各種元數(shù)據(jù)都會保留。比如讀、寫、執(zhí)行權(quán)限、文件變更時間等。這個特性對于鏡像定制很有用。特別是構(gòu)建相關(guān)文件都在使用 Git進行管理的時候。

ADD 更高級的復(fù)制文件

ADD 指令和 COPY 的格式和性質(zhì)基本一致。 但是在 COPY 基礎(chǔ)上增加了一些功能。比如 <源路徑> 可以是一個 URL ，這種情況下，Docker 引擎會試圖去下載這個鏈接的文件放到 <目標路徑> 去。 下載后的文件權(quán)限自動設(shè)置為 600 ，如果這并不是想要的權(quán)限，那么還需要增加額外的一層 RUN 進行權(quán)限調(diào)整，另外，如果下載的是個壓縮包，需要解壓縮，也一樣還需要額外的一層 RUN 指令進行解壓縮。 所以不如直接使用 RUN 指令，然后使用 wget 或者 curl 工具下載，處理權(quán)限、解壓縮、然后清理無用文件更合理。因此，這個功能其實并不實用，而且不推薦使用。 如果 <源路徑> 為一個 tar 壓縮文件的話，壓縮格式為 gzip , bzip2 以及 xz 的情況下， ADD 指令將會自動解壓縮這個壓縮文件到 <目標路徑> 去。 在某些情況下，這個自動解壓縮的功能非常有用， 比如官方鏡像 ubuntu 中： FROM scratch ADD ubuntu-xenial-core-cloudimg-amd64-root.tar.gz / ... 但在某些情況下，如果我們真的是希望復(fù)制個壓縮文件進去，而不解壓縮，這時就不可以使用 ADD 命令了。 在 Docker 官方的 Dockerfile 最佳實踐文檔 中要求，盡可能的使用 COPY ，因為 COPY 的語義很明確，就是復(fù)制文件而已，而 ADD 則包含了更復(fù)雜的功能，其行為也不一定很清晰。最適合使用 ADD 的場合，就是所提及的需要自動解壓縮的場合。 另外需要注意的是， ADD 指令會令鏡像構(gòu)建緩存失效，從而可能會令鏡像構(gòu)建變得比較緩慢。 因此在 COPY 和 ADD 指令中選擇的時候，可以遵循這樣的原則，所有的文件復(fù)制均使用COPY 指令，僅在需要自動解壓縮的場合使用 ADD 。

CMD 容器啟動命令

CMD 指令的格式和 RUN 相似，也是兩種格式： shell 格式： CMD <命令> exec 格式： CMD ["可執(zhí)行文件", "參數(shù)1", "參數(shù)2"...] 參數(shù)列表格式： CMD ["參數(shù)1", "參數(shù)2"...] 。在指定了 ENTRYPOINT 指令后，用 CMD 指定具體的參數(shù)。之前介紹容器的時候曾經(jīng)說過，Docker 不是虛擬機，容器就是進程。 既然是進程，那么在啟動容器的時候，需要指定所運行的程序及參數(shù)。 CMD 指令就是用于指定默認的容器主進程的啟動命令的。在運行時可以指定新的命令來替代鏡像設(shè)置中的這個默認命令，比如， 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 進行解析處理。 提到 CMD 就不得不提容器中應(yīng)用在前臺執(zhí)行和后臺執(zhí)行的問題。這是初學(xué)者常出現(xiàn)的一個混淆。 Docker 不是虛擬機，容器中的應(yīng)用都應(yīng)該以前臺執(zhí)行，而不是像虛擬機、物理機里面那樣，用 upstart/systemd 去啟動后臺服務(wù)，容器內(nèi)沒有后臺服務(wù)的概念。 一些初學(xué)者將 CMD 寫為： CMD service nginx start 然后發(fā)現(xiàn)容器執(zhí)行后就立即退出了。甚至在容器內(nèi)去使用 systemctl 命令結(jié)果卻發(fā)現(xiàn)根本執(zhí)行不了。這就是因為沒有搞明白前臺、后臺的概念，沒有區(qū)分容器和虛擬機的差異，依舊在以傳統(tǒng)虛擬機的角度去理解容器。 對于容器而言，其啟動程序就是容器應(yīng)用進程，容器就是為了主進程而存在的，主進程退出，容器就失去了存在的意義，從而退出，其它輔助進程不是它需要關(guān)心的東西。 而使用 service nginx start 命令，則是希望 upstart 來以后臺守護進程形式啟動 nginx 服務(wù)。而剛才說了 CMD service nginx start 會被理解為 CMD [ "sh", "-c", "service nginxstart"] ，因此主進程實際上是 sh 。 那么當(dāng) service nginx start 命令結(jié)束后， sh 也就結(jié)束了， sh 作為主進程退出了，自然就會令容器退出。 正確的做法是直接執(zhí)行 nginx 可執(zhí)行文件，并且要求以前臺形式運行。 比如： CMD ["nginx", "-g", "daemon off;"]

ENTRYPOINT 入口點

ENTRYPOINT 的格式和 RUN 指令格式一樣，分為 exec 格式和 shell 格式。 ENTRYPOINT 的目的和 CMD 一樣，都是在指定容器啟動程序及參數(shù)。 ENTRYPOINT 在運行時也可以替代，不過比 CMD 要略顯繁瑣，需要通過 docker run 的參數(shù) --entrypoint 來指定。 當(dāng)指定了 ENTRYPOINT 后， CMD 的含義就發(fā)生了改變，不再是直接的運行其命令，而是將CMD 的內(nèi)容作為參數(shù)傳給 ENTRYPOINT 指令，換句話說實際執(zhí)行時，將變?yōu)?#xff1a; <ENTRYPOINT> "<CMD>" 那么有了 CMD 后，為什么還要有 ENTRYPOINT 呢？ 這種 <ENTRYPOINT> "<CMD>" 有什么好處么？讓我們來看幾個場景。場景一：讓鏡像變成像命令一樣使用 假設(shè)我們需要一個得知自己當(dāng)前公網(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 . 來構(gòu)建鏡像的話，如果我們需要查詢當(dāng)前公網(wǎng) IP，只需要執(zhí)行： $ docker run myip 當(dāng)前 IP: 112.74.185.172 來自: 廣東省深圳市 阿里云嗯，這么看起來好像可以直接把鏡像當(dāng)做命令使用了，不過命令總有參數(shù)，如果我們希望加參數(shù)呢？比如從上面的 CMD 中可以看到實質(zhì)的命令是 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: container_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 build -t myip . $ docker run myip 當(dāng)前 IP: 112.74.185.172 來自: 廣東省深圳市 阿里云$ docker run myip -i HTTP/1.1 200 OK Date: Wed, 07 Nov 2018 08:14:51 GMT Content-Type: text/html; charset=UTF-8 Transfer-Encoding: chunked Connection: keep-alive Set-Cookie: __cfduid=dba4b6fb8f58508496e470c222fa3c86d1541578491; expires=Thu, 07-Nov-19 08:14:51 GMT; path=/; domain=.ip.cn; HttpOnly Server: cloudflare CF-RAY: 475e594650b193de-SJC 當(dāng)前 IP: 112.74.185.172 來自: 廣東省深圳市 阿里云可以看到，這次成功了。這是因為當(dāng)存在 ENTRYPOINT 后， CMD 的內(nèi)容將會作為參數(shù)傳給ENTRYPOINT ，而這里 -i 就是新的 CMD ，因此會作為參數(shù)傳給 curl ，從而達到了我們預(yù)期的效果。場景二：應(yīng)用運行前的準備工作 啟動容器就是啟動主進程，但有些時候，啟動主進程前，需要一些準備工作。 比如 mysql 類的數(shù)據(jù)庫，可能需要一些數(shù)據(jù)庫配置、初始化的工作，這些工作要在最終的mysql 服務(wù)器運行之前解決。 此外，可能希望避免使用 root 用戶去啟動服務(wù)，從而提高安全性，而在啟動服務(wù)前還需要以 root 身份執(zhí)行一些必要的準備工作，最后切換到服務(wù)用戶身份啟動服務(wù)。或者除了服務(wù)外，其它命令依舊可以使用 root 身份執(zhí)行，方便調(diào)試等。 這些準備工作是和容器 CMD 無關(guān)的，無論 CMD 為什么，都需要事先進行一個預(yù)處理的工作。這種情況下，可以寫一個腳本，然后放入 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 服務(wù)創(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用戶身份啟動服務(wù)器，否則依舊使用 root 身份執(zhí)行。 比如： $ docker run -it redis id uid=0(root) gid=0(root) groups=0(root)

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

格式有兩種： ENV <key> <value> ENV <key1>=<value1> <key2>=<value2>... 這個指令很簡單，就是設(shè)置環(huán)境變量而已，無論是后面的其它指令，如 RUN ，還是運行時的應(yīng)用，都可以直接使用這里定義的環(huán)境變量。 ENV VERSION=1.0 DEBUG=on \ NAME="Happy Feet" 這個例子中演示了如何換行，以及對含有空格的值用雙引號括起來的辦法，這和 Shell 下的行為是一致的。 定義了環(huán)境變量，那么在后續(xù)的指令中，就可以使用這個環(huán)境變量。 比如在官方 node 鏡像Dockerfile 中，就有類似這樣的代碼： ENV NODE_VERSION 7.2.0 RUN curl -SLO "https://nodejs.org/dist/v$NODE_VERSION/node-v$NODE_VERSION-linux-x64.ta r.xz" \ && curl -SLO "https://nodejs.org/dist/v$NODE_VERSION/SHASUMS256.txt.asc" \ && gpg --batch --decrypt --output SHASUMS256.txt SHASUMS256.txt.asc \ && grep " node-v$NODE_VERSION-linux-x64.tar.xz\$" SHASUMS256.txt | sha256sum -c - \ && tar -xJf "node-v$NODE_VERSION-linux-x64.tar.xz" -C /usr/local --strip-components= 1 \ && rm "node-v$NODE_VERSION-linux-x64.tar.xz" SHASUMS256.txt.asc SHASUMS256.txt \ && ln -s /usr/local/bin/node /usr/local/bin/nodejs 在這里先定義了環(huán)境變量 NODE_VERSION ，其后的 RUN 這層里，多次使用 $NODE_VERSION 來進行操作定制。 可以看到，將來升級鏡像構(gòu)建版本的時候，只需要更新 7.2.0 即可， Dockerfile 構(gòu)建維護變得更輕松了。 下列指令可以支持環(huán)境變量展開： ADD 、 COPY 、 ENV 、 EXPOSE 、 LABEL 、 USER 、 WORKDIR 、 VOLUME 、 STOPSIGNAL 、 ONBUILD 。 可以從這個指令列表里感覺到，環(huán)境變量可以使用的地方很多，很強大。 通過環(huán)境變量，我們可以讓一份 Dockerfile 制作更多的鏡像，只需使用不同的環(huán)境變量即可。

ARG 構(gòu)建參數(shù)

格式： ARG <參數(shù)名>[=<默認值>] 構(gòu)建參數(shù)和 ENV 的效果一樣，都是設(shè)置環(huán)境變量。 所不同的是， ARG 所設(shè)置的構(gòu)建環(huán)境的環(huán)境變量，在將來容器運行時是不會存在這些環(huán)境變量的。 但是不要因此就使用 ARG 保存密碼之類的信息，因為 docker history 還是可以看到所有值的。 Dockerfile 中的 ARG 指令是定義參數(shù)名稱，以及定義其默認值。 該默認值可以在構(gòu)建命令docker build 中用 --build-arg <參數(shù)名>=<值> 來覆蓋。 在 1.13 之前的版本，要求 --build-arg 中的參數(shù)名，必須在 Dockerfile 中用 ARG 定義過了，換句話說，就是 --build-arg 指定的參數(shù)，必須在 Dockerfile 中使用了。 如果對應(yīng)參數(shù)沒有被使用，則會報錯退出構(gòu)建。從 1.13 開始，這種嚴格的限制被放開，不再報錯退出，而是顯示警告信息，并繼續(xù)構(gòu)建。 這對于使用 CI 系統(tǒng)，用同樣的構(gòu)建流程構(gòu)建不同的Dockerfile 的時候比較有幫助，避免構(gòu)建命令必須根據(jù)每個 Dockerfile 的內(nèi)容修改。

VOLUME 定義匿名卷

格式為： VOLUME ["<路徑1>", "<路徑2>"...] VOLUME <路徑> 之前我們說過，容器運行時應(yīng)該盡量保持容器存儲層不發(fā)生寫操作，對于數(shù)據(jù)庫類需要保存動態(tài)數(shù)據(jù)的應(yīng)用，其數(shù)據(jù)庫文件應(yīng)該保存于卷(volume)中，后面的章節(jié)我們會進一步介紹Docker 卷的概念。 為了防止運行時用戶忘記將動態(tài)文件所保存目錄掛載為卷，在Dockerfile 中，我們可以事先指定某些目錄掛載為匿名卷，這樣在運行時如果用戶不指定掛載，其應(yīng)用也可以正常運行，不會向容器存儲層寫入大量數(shù)據(jù)。 VOLUME /data 這里的 /data 目錄就會在運行時自動掛載為匿名卷，任何向 /data 中寫入的信息都不會記錄進容器存儲層，從而保證了容器存儲層的無狀態(tài)化。當(dāng)然，運行時可以覆蓋這個掛載設(shè)置。比如： docker run -d -v mydata:/data xxxx 在這行命令中，就使用了 mydata 這個命名卷掛載到了 /data 這個位置，替代了Dockerfile 中定義的匿名卷的掛載配置。

EXPOSE 聲明端口

格式為 EXPOSE <端口1> [<端口2>...] EXPOSE 指令是聲明運行時容器提供服務(wù)端口，這只是一個聲明，在運行時并不會因為這個聲明應(yīng)用就會開啟這個端口的服務(wù)。 在 Dockerfile 中寫入這樣的聲明有兩個好處，一個是幫助鏡像使用者理解這個鏡像服務(wù)的守護端口，以方便配置映射；另一個用處則是在運行時使用隨機端口映射時，也就是 docker run -P 時，會自動隨機映射 EXPOSE 的端口。 此外，在早期 Docker 版本中還有一個特殊的用處。以前所有容器都運行于默認橋接網(wǎng)絡(luò)中，因此所有容器互相之間都可以直接訪問，這樣存在一定的安全性問題。 于是有了一個 Docker引擎參數(shù) --icc=false ，當(dāng)指定該參數(shù)后，容器間將默認無法互訪， 除非互相間使用了 --links 參數(shù)的容器才可以互通，并且只有鏡像中 EXPOSE 所聲明的端口才可以被訪問。這個--icc=false 的用法，在引入了 docker network 后已經(jīng)基本不用了，通過自定義網(wǎng)絡(luò)可以很輕松的實現(xiàn)容器間的互聯(lián)與隔離。 要將 EXPOSE 和在運行時使用 -p <宿主端口>:<容器端口> 區(qū)分開來。 -p ，是映射宿主端口和容器端口，換句話說，就是將容器的對應(yīng)端口服務(wù)公開給外界訪問， 而 EXPOSE 僅僅是聲明容器打算使用什么端口而已，并不會自動在宿主進行端口映射。

WORKDIR 指定工作目錄

格式為 WORKDIR <工作目錄路徑> 使用 WORKDIR 指令可以來指定工作目錄（或者稱為當(dāng)前目錄），以后各層的當(dāng)前目錄就被改為指定的目錄，如該目錄不存在， WORKDIR 會幫你建立目錄。 之前提到一些初學(xué)者常犯的錯誤是把 Dockerfile 等同于 Shell 腳本來書寫，這種錯誤的理解還可能會導(dǎo)致出現(xiàn)下面這樣的錯誤： RUN cd /app RUN echo "hello" > world.txt 如果將這個 Dockerfile 進行構(gòu)建鏡像運行后，會發(fā)現(xiàn)找不到 /app/world.txt 文件，或者其內(nèi)容不是 hello 。 原因其實很簡單，在 Shell 中，連續(xù)兩行是同一個進程執(zhí)行環(huán)境，因此前一個命令修改的內(nèi)存狀態(tài)，會直接影響后一個命令；而在 Dockerfile 中，這兩行 RUN 命令的執(zhí)行環(huán)境根本不同，是兩個完全不同的容器。這就是對 Dockerfile 構(gòu)建分層存儲的概念不了解所導(dǎo)致的錯誤。 之前說過每一個 RUN 都是啟動一個容器、執(zhí)行命令、然后提交存儲層文件變更。 第一層 RUNcd /app 的執(zhí)行僅僅是當(dāng)前進程的工作目錄變更，一個內(nèi)存上的變化而已，其結(jié)果不會造成任何文件變更。 而到第二層的時候，啟動的是一個全新的容器，跟第一層的容器更完全沒關(guān)系，自然不可能繼承前一層構(gòu)建過程中的內(nèi)存變化。因此如果需要改變以后各層的工作目錄的位置，那么應(yīng)該使用 WORKDIR 指令。

USER 指定當(dāng)前用戶

格式： USER <用戶名> USER 指令和 WORKDIR 相似，都是改變環(huán)境狀態(tài)并影響以后的層。WORKDIR 是改變工作目錄， USER 則是改變之后層的執(zhí)行 RUN , CMD 以及 ENTRYPOINT 這類命令的身份。 當(dāng)然，和 WORKDIR 一樣， USER 只是幫助你切換到指定用戶而已，這個用戶必須是事先建立好的，否則無法切換。 RUN groupadd -r redis && useradd -r -g redis redis USER redis RUN [ "redis-server" ] 如果以 root 執(zhí)行的腳本，在執(zhí)行期間希望改變身份，比如希望以某個已經(jīng)建立好的用戶來運行某個服務(wù)進程，不要使用 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 # 設(shè)置 CMD，并以另外的用戶執(zhí)行 CMD [ "exec", "gosu", "redis", "redis-server" ]

HEALTHCHECK 健康檢查

格式： HEALTHCHECK [選項] CMD <命令> ：設(shè)置檢查容器健康狀況的命令HEALTHCHECK NONE ：如果基礎(chǔ)鏡像有健康檢查指令，使用這行可以屏蔽掉其健康檢查指令HEALTHCHECK 指令是告訴 Docker 應(yīng)該如何進行判斷容器的狀態(tài)是否正常，這是 Docker 1.12引入的新指令。在沒有 HEALTHCHECK 指令前，Docker 引擎只可以通過容器內(nèi)主進程是否退出來判斷容器是否狀態(tài)異常。 很多情況下這沒問題，但是如果程序進入死鎖狀態(tài)，或者死循環(huán)狀態(tài)，應(yīng)用進程并不退出，但是該容器已經(jīng)無法提供服務(wù)了。在 1.12 以前，Docker 不會檢測到容器的這種狀態(tài)，從而不會重新調(diào)度，導(dǎo)致可能會有部分容器已經(jīng)無法提供服務(wù)了卻還在接受用戶請求。 而自 1.12 之后，Docker 提供了 HEALTHCHECK 指令，通過該指令指定一行命令，用這行命令來判斷容器主進程的服務(wù)狀態(tài)是否還正常，從而比較真實的反應(yīng)容器實際狀態(tài)。當(dāng)在一個鏡像指定了 HEALTHCHECK 指令后，用其啟動容器，初始狀態(tài)會為 starting ，在HEALTHCHECK 指令檢查成功后變?yōu)?healthy ，如果連續(xù)一定次數(shù)失敗，則會變?yōu)閡nhealthy 。HEALTHCHECK 支持下列選項： --interval=<間隔> ：兩次健康檢查的間隔，默認為 30 秒； --timeout=<時長> ：健康檢查命令運行超時時間，如果超過這個時間，本次健康檢查就被視為失敗，默認 30 秒； --retries=<次數(shù)> ：當(dāng)連續(xù)失敗指定次數(shù)后，則將容器狀態(tài)視為 unhealthy ，默認 3次。和 CMD , ENTRYPOINT 一樣， HEALTHCHECK 只可以出現(xiàn)一次，如果寫了多個，只有最后一個生效。在 HEALTHCHECK [選項] CMD 后面的命令，格式和 ENTRYPOINT 一樣，分為 shell 格式，和exec 格式。 命令的返回值決定了該次健康檢查的成功與否： 0 ：成功； 1 ：失敗； 2 ：保留，不要使用這個值。假設(shè)我們有個鏡像是個最簡單的 Web 服務(wù)，我們希望增加健康檢查來判斷其 Web 服務(wù)是否在正常工作， 我們可以用 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 這里我們設(shè)置了每 5 秒檢查一次（這里為了試驗所以間隔非常短，實際應(yīng)該相對較長），如果健康檢查命令超過 3 秒沒響應(yīng)就視為失敗，并且使用 curl -fs http://localhost/ || exit1 作為健康檢查命令。使用 docker build 來構(gòu)建這個鏡像： $ docker build -t myweb:v1 . 構(gòu)建好了后，我們啟動一個容器： $ docker run -d --name web -p 80:80 myweb:v1 當(dāng)運行該鏡像后，可以通過 docker container ls 看到最初的狀態(tài)為 (health: starting) ： $ docker container ls CONTAINER ID ? ? ? ?IMAGE ? ? ? ? ? ? ? ? COMMAND ? ? ? ? ? ? ? ? ?CREATED ? ? ? ? ? ? STATUS ? ? ? ? ? ? ? ? ? ? ? ? ? ?PORTS ? ? ? ? ? ? ? ? ? ?NAMES 9a5d766dbd5b ? ? ? ?myweb:v1 ? ? ? ? ? ? ?"nginx -g 'daemon of…" ? 4 seconds ago ? ? ? Up 3 seconds (health: starting) ? 0.0.0.0:80->80/tcp ? ? ? web在等待幾秒鐘后，再次 docker container ls ，就會看到健康狀態(tài)變化為了 (healthy) ： $ docker container ls CONTAINER ID ? ? ? ?IMAGE ? ? ? ? ? ? ? ? COMMAND ? ? ? ? ? ? ? ? ?CREATED ? ? ? ? ? ? STATUS ? ? ? ? ? ? ? ? ? ?PORTS ? ? ? ? ? ? ? ? ? ?NAMES 9a5d766dbd5b ? ? ? ?myweb:v1 ? ? ? ? ? ? ?"nginx -g 'daemon of…" ? 35 seconds ago ? ? ?Up 34 seconds (healthy) ? 0.0.0.0:80->80/tcp ? ? ? web如果健康檢查連續(xù)失敗超過了重試次數(shù)，狀態(tài)就會變?yōu)?(unhealthy) 。 為了幫助排障，健康檢查命令的輸出（包括 stdout 以及 stderr ）都會被存儲于健康狀態(tài)里，可以用 docker inspect 來查看。$ docker inspect --format '{{json .State.Health}}' web | python -m json.tool {"FailingStreak": 0,"Log": [{"End": "2018-11-07T17:30:55.418758779+08:00","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>

ONBUILD 為他人做嫁衣裳

格式： ONBUILD <其它指令> ONBUILD 是一個特殊的指令，它后面跟的是其它指令，比如 RUN , COPY 等，而這些指令，在當(dāng)前鏡像構(gòu)建時并不會被執(zhí)行。 只有當(dāng)以當(dāng)前鏡像為基礎(chǔ)鏡像，去構(gòu)建下一級鏡像的時候才會被執(zhí)行。 Dockerfile 中的其它指令都是為了定制當(dāng)前鏡像而準備的，唯有 ONBUILD 是為了幫助別人定制自己而準備的。 假設(shè)我們要制作 Node.js 所寫的應(yīng)用的鏡像。 我們都知道 Node.js 使用 npm 進行包管理，所有依賴、配置、啟動信息等會放到 package.json 文件里。 在拿到程序代碼后，需要先進行npm install 才可以獲得所有需要的依賴。然后就可以通過 npm start 來啟動應(yīng)用。 因此，一般來說會這樣寫 Dockerfile ： FROM node:slim RUN mkdir /app WORKDIR /app COPY ./package.json /app RUN [ "npm", "install" ] COPY . /app/ CMD [ "npm", "start" ] 把這個 Dockerfile 放到 Node.js 項目的根目錄，構(gòu)建好鏡像后，就可以直接拿來啟動容器運行。 但是如果我們還有第二個 Node.js 項目也差不多呢？好吧，那就再把這個 Dockerfile 復(fù)制到第二個項目里。 那如果有第三個項目呢？再復(fù)制么？文件的副本越多，版本控制就越困難，讓我們繼續(xù)看這樣的場景維護的問題。 如果第一個 Node.js 項目在開發(fā)過程中，發(fā)現(xiàn)這個 Dockerfile 里存在問題，比如敲錯字了、或者需要安裝額外的包，然后開發(fā)人員修復(fù)了這個 Dockerfile ，再次構(gòu)建，問題解決。 第一個項目沒問題了，但是第二個項目呢？雖然最初 Dockerfile 是復(fù)制、粘貼自第一個項目的，但是并不會因為第一個項目修復(fù)了他們的 Dockerfile ，而第二個項目的 Dockerfile 就會被自動修復(fù)。 那么我們可不可以做一個基礎(chǔ)鏡像，然后各個項目使用這個基礎(chǔ)鏡像呢？這樣基礎(chǔ)鏡像更新，各個項目不用同步 Dockerfile 的變化，重新構(gòu)建后就繼承了基礎(chǔ)鏡像的更新？ 好吧，可以，讓我們看看這樣的結(jié)果。那么上面的這個 Dockerfile 就會變?yōu)?#xff1a; FROM node:slim RUN mkdir /app WORKDIR /app CMD [ "npm", "start" ]這里我們把項目相關(guān)的構(gòu)建指令拿出來，放到子項目里去。假設(shè)這個基礎(chǔ)鏡像的名字為 mynode的話，各個項目內(nèi)的自己的 Dockerfile 就變?yōu)?#xff1a; FROM my-node COPY ./package.json /app RUN [ "npm", "install" ] COPY . /app/ 基礎(chǔ)鏡像變化后，各個項目都用這個 Dockerfile 重新構(gòu)建鏡像，會繼承基礎(chǔ)鏡像的更新。 那么，問題解決了么？沒有。準確說，只解決了一半。如果這個 Dockerfile 里面有些東西需要調(diào)整呢？比如 npm install 都需要加一些參數(shù)，那怎么辦？這一行 RUN 是不可能放入基礎(chǔ)鏡像的，因為涉及到了當(dāng)前項目的 ./package.json ，難道又要一個個修改么？所以說，這樣制作基礎(chǔ)鏡像，只解決了原來的 Dockerfile 的前4條指令的變化問題，而后面三條指令的變化則完全沒辦法處理。 ONBUILD 可以解決這個問題。 讓我們用 ONBUILD 重新寫一下基礎(chǔ)鏡像的 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 ，但是這次將項目相關(guān)的指令加上 ONBUILD ，這樣在構(gòu)建基礎(chǔ)鏡像的時候，這三行并不會被執(zhí)行。然后各個項目的 Dockerfile 就變成了簡單地： FROM my-node 是的，只有這么一行。當(dāng)在各個項目目錄中，用這個只有一行的 Dockerfile 構(gòu)建鏡像時，之前基礎(chǔ)鏡像的那三行 ONBUILD 就會開始執(zhí)行，成功的將當(dāng)前項目的代碼復(fù)制進鏡像、并且針對本項目執(zhí)行 npm install ，生成應(yīng)用鏡像。

參考文檔
Dockerfie 官方文檔：https://docs.docker.com/engine/reference/builder/
Dockerfile 最佳實踐文檔：https://docs.docker.com/engine/userguide/engimage/dockerfile_best-practices/
Docker 官方鏡像 Dockerfile ：https://github.com/docker-library/docs

轉(zhuǎn)載于:https://my.oschina.net/wuweixiang/blog/2870494

總結(jié)

以上是生活随笔為你收集整理的Docker学习——Dockerfile 指令详解（五）的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。