DockerFile詳解--轉載

時間  2019-12-10
標籤 dockerfile 詳解 轉載 欄目 Docker 简体版
原文   原文鏈接

COPY 複製文件

格式：html

COPY <源路徑> ... <目標路徑>
COPY [" <源路徑1> ",... " <目標路徑> "]
和 RUN 指令同樣，也有兩種格式，一種相似於命令行，一種相似於函數調用。 node

COPY 指令將從構建上下文目錄中 <源路徑> 的文件/目錄複製到新的一層的鏡像內的 <目標路徑> 位置。好比： python

COPY package.json /usr/src/app/
<源路徑> 能夠是多個，甚至能夠是通配符，其通配符規則要知足 Go 的 filepath.Match 規則，如： mysql

COPY hom* /mydir/
COPY hom?.txt /mydir/

<目標路徑> 能夠是容器內的絕對路徑，也能夠是相對於工做目錄的相對路徑（工做目錄能夠用 WORKDIR 指令來指定）。目標路徑不須要事先建立，若是目錄不存在會在複製文件前先行建立缺失目錄。 linux

此外，還須要注意一點，使用 COPY 指令，源文件的各類元數據都會保留。好比讀、寫、執行權限、文件變動時間等。這個特性對於鏡像定製頗有用。特別是構建相關文件都在使用 Git 進行管理的時候。nginx

ADD 更高級的複製文件

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

好比 <源路徑> 能夠是一個 URL，這種狀況下，Docker 引擎會試圖去下載這個連接的文件放到 <目標路徑> 去。下載後的文件權限自動設置爲 600，若是這並非想要的權限，那麼還須要增長額外的一層 RUN 進行權限調整，另外，若是下載的是個壓縮包，須要解壓縮，也同樣還須要額外的一層 RUN 指令進行解壓縮。因此不如直接使用 RUN 指令，而後使用 wget 或者 curl 工具下載，處理權限、解壓縮、而後清理無用文件更合理。所以，這個功能其實並不實用，並且不推薦使用。 github

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

在某些狀況下，這個自動解壓縮的功能很是有用，好比官方鏡像 ubuntu 中：redis

FROM scratch
ADD ubuntu-xenial-core-cloudimg-amd64-root.tar.gz /
...

但在某些狀況下，若是咱們真的是但願複製個壓縮文件進去，而不解壓縮，這時就不可使用 ADD 命令了。

在 Docker 官方的 Dockerfile 最佳實踐文檔 中要求，儘量的使用 COPY，由於 COPY 的語義很明確，就是複製文件而已，而 ADD 則包含了更復雜的功能，其行爲也不必定很清晰。最適合使用 ADD 的場合，就是所說起的須要自動解壓縮的場合。

另外須要注意的是，ADD 指令會令鏡像構建緩存失效，從而可能會令鏡像構建變得比較緩慢。

所以在 COPY 和 ADD 指令中選擇的時候，能夠遵循這樣的原則，全部的文件複製均使用 COPY 指令，僅在須要自動解壓縮的場合使用 ADD。

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

ENTRYPOINT 入口點

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

ENTRYPOINT 的目的和 CMD 同樣，都是在指定容器啓動程序及參數。ENTRYPOINT 在運行時也能夠替代，不過比 CMD 要略顯繁瑣，須要經過 docker run 的參數 --entrypoint 來指定。

當指定了 ENTRYPOINT 後，CMD 的含義就發生了改變，再也不是直接的運行其命令，而是將 CMD 的內容做爲參數傳給 ENTRYPOINT 指令，換句話說實際執行時，將變爲：

" "
那麼有了 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，從而達到了咱們預期的效果。

場景二：應用運行前的準備工做
啓動容器就是啓動主進程，但有些時候，啓動主進程前，須要一些準備工做。

好比 mysql 類的數據庫，可能須要一些數據庫配置、初始化的工做，這些工做要在最終的 mysql 服務器運行以前解決。

此外，可能但願避免使用 root 用戶去啓動服務，從而提升安全性，而在啓動服務前還須要以 root 身份執行一些必要的準備工做，最後切換到服務用戶身份啓動服務。或者除了服務外，其它命令依舊可使用 root 身份執行，方便調試等。

這些準備工做是和容器 CMD 無關的，不管 CMD 爲何，都須要事先進行一個預處理的工做。這種狀況下，能夠寫一個腳本，而後放入 ENTRYPOINT 中去執行，而這個腳本會將接到的參數（也就是 ）做爲命令，在腳本最後執行。好比官方鏡像 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)

ENV 設置環境變量

格式有兩種：

ENV
ENV = = ...
這個指令很簡單，就是設置環境變量而已，不管是後面的其它指令，如 RUN，仍是運行時的應用，均可以直接使用這裏定義的環境變量。

ENV VERSION=1.0 DEBUG=on NAME="Happy Feet"
這個例子中演示瞭如何換行，以及對含有空格的值用雙引號括起來的辦法，這和 Shell 下的行爲是一致的。

定義了環境變量，那麼在後續的指令中，就可使用這個環境變量。好比在官方 node 鏡像 Dockerfile 中，就有相似這樣的代碼：

ENV NODE_VERSION 7.2.0

RUN curl -SLO "https://nodejs.org/dist/v$NODE_VERSION/node-v$NODE_VERSION-linux-x64.tar.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

在這裏先定義了環境變量 NODE_VERSION，其後的 RUN 這層裏，屢次使用 $NODE_VERSION 來進行操做定製。能夠看到，未來升級鏡像構建版本的時候，只須要更新 7.2.0 便可，Dockerfile 構建維護變得更輕鬆了。

下列指令能夠支持環境變量展開： ADD、COPY、ENV、EXPOSE、LABEL、USER、WORKDIR、VOLUME、STOPSIGNAL、ONBUILD。

能夠從這個指令列表裏感受到，環境變量可使用的地方不少，很強大。經過環境變量，咱們可讓一份 Dockerfile 製做更多的鏡像，只需使用不一樣的環境變量便可。

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 的內容修改。

VOLUME 定義匿名卷

格式爲：

VOLUME [" <路徑1> ", " <路徑2> "...]
VOLUME <路徑>
以前咱們說過，容器運行時應該儘可能保持容器存儲層不發生寫操做，對於數據庫類須要保存動態數據的應用，其數據庫文件應該保存於卷(volume)中，後面的章節咱們會進一步介紹 Docker 卷的概念。爲了防止運行時用戶忘記將動態文件所保存目錄掛載爲卷，在 Dockerfile 中，咱們能夠事先指定某些目錄掛載爲匿名卷，這樣在運行時若是用戶不指定掛載，其應用也能夠正常運行，不會向容器存儲層寫入大量數據。

VOLUME /data
這裏的 /data 目錄就會在運行時自動掛載爲匿名卷，任何向 /data 中寫入的信息都不會記錄進容器存儲層，從而保證了容器存儲層的無狀態化。固然，運行時能夠覆蓋這個掛載設置。好比：

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

EXPOSE 聲明端口

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

EXPOSE 指令是聲明運行時容器提供服務端口，這只是一個聲明，在運行時並不會由於這個聲明應用就會開啓這個端口的服務。在 Dockerfile 中寫入這樣的聲明有兩個好處，一個是幫助鏡像使用者理解這個鏡像服務的守護端口，以方便配置映射；另外一個用處則是在運行時使用隨機端口映射時，也就是 docker run -P 時，會自動隨機映射 EXPOSE 的端口。

此外，在早期 Docker 版本中還有一個特殊的用處。之前全部容器都運行於默認橋接網絡中，所以全部容器互相之間均可以直接訪問，這樣存在必定的安全性問題。因而有了一個 Docker 引擎參數 --icc=false，當指定該參數後，容器間將默認沒法互訪，除非互相間使用了 --links 參數的容器才能夠互通，而且只有鏡像中 EXPOSE 所聲明的端口才能夠被訪問。這個 --icc=false 的用法，在引入了 docker network 後已經基本不用了，經過自定義網絡能夠很輕鬆的實現容器間的互聯與隔離。

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

WORKDIR 指定工做目錄

格式爲 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 指令。

USER 指定當前用戶

格式：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" ]

HEALTHCHECK 健康檢查

格式：

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 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"
}

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

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程