當前位置：首頁 > 编程资源 > 编程问答 >内容正文

编程问答

Dockerfile 指令详解2

發布時間：2024/9/3 编程问答 44 豆豆

生活随笔收集整理的這篇文章主要介紹了 Dockerfile 指令详解2 小編覺得挺不錯的,現在分享給大家,幫大家做個參考.

ENV 設置環境變量

格式有兩種：

ENV <key> <value>
ENV <key1>=<value1> <key2>=<value2>...

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

ENV VERSION=1.0 DEBUG=on \NAME="Happy Feet"

這個例子中演示了如何換行，以及對含有空格的值用雙引號括起來的辦法，這和 Shell 下的行為是一致的。

定義了環境變量，那么在后續的指令中，就可以使用這個環境變量。比如在官方 node 鏡像 Dockerfile 中，就有類似這樣的代碼：

ENV NODE_VERSION 7.2.0RUN 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、FROM、LABEL、USER、WORKDIR、VOLUME、STOPSIGNAL、ONBUILD、RUN。

可以從這個指令列表里感覺到，環境變量可以使用的地方很多，很強大。通過環境變量，我們可以讓一份 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 的端口。

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

參考文檔

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

總結

以上是生活随笔為你收集整理的Dockerfile 指令详解2的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。

上一篇： Dockerfile 指令详解1
下一篇： docker 多阶段构建