怎么使用Docker Dockerfile定制鏡像

這篇“怎么使用Docker Dockerfile定制鏡像”文章的知識點大部分人都不太理解，所以小編給大家總結了以下內容，內容詳細，步驟清晰，具有一定的借鑒價值，希望大家閱讀完這篇文章能有所收獲，下面我們一起來看看這篇“怎么使用Docker Dockerfile定制鏡像”文章吧。

使用 dockerfile 定制鏡像

鏡像的定制實際上就是定制每一層所添加的配置、文件。如果我們可以把每一層修改、安裝、構建、操作的命令都寫入一個腳本，用這個腳本來構建、定制鏡像，那么無法重復的問題、鏡像構建透明性的問題、體積的問題就都會解決。這個腳本就是 dockerfile。

dockerfile 是一個文本文件，其內包含了一條條的指令(instruction)，每一條指令構建一層，因此每一條指令的內容，就是描述該層應當如何構建。

此處以定制 nginx 鏡像為例，使用 dockerfile 來定制。

在一個空白目錄中，建立一個文本文件，并命名為 dockerfile ：

$ mkdir mynginx
$ cd mynginx
$ touch dockerfile

其內容為：

from nginx
run echo '<h1>hello, docker!</h1>' > /usr/share/nginx/html/index.html

這個 dockerfile 很簡單，一共就兩行。涉及到了兩條指令， from 和 run 。

dockerfile 指令詳解

from 指定基礎鏡像

所謂定制鏡像，那一定是以一個鏡像為基礎，在其上進行定制。而 from 就是指定基礎鏡像，因此一個 dockerfile 中 from 是必備的指令，并且必須是第一條指令。

在 docker store 上有非常多的高質量的官方鏡像，有可以直接拿來使用的服務類的鏡像，如nginx 、 redis 、 mongo 、mysql 等；也有一些方便開發、構建、運行各種語言應用的鏡像，如 node 、 openjdk 、 python 等。可以在其中尋找一個最符合我們最終目標的鏡像為基礎鏡像進行定制。

如果沒有找到對應服務的鏡像，官方鏡像中還提供了一些更為基礎的操作系統鏡像，如ubuntu 、 debian 、 centos 等，這些操作系統的軟件庫為我們提供了更廣闊的擴展空間。

除了選擇現有鏡像為基礎鏡像外，docker 還存在一個特殊的鏡像，名為 scratch 。這個鏡像是虛擬的概念，并不實際存在，它表示一個空白的鏡像。

from scratch
...

如果你以 scratch 為基礎鏡像的話，意味著你不以任何鏡像為基礎，接下來所寫的指令將作為鏡像第一層開始存在。

不以任何系統為基礎，直接將可執行文件復制進鏡像的做法并不罕見，比如 swarm 、 coreos/etcd 。對于 linux 下靜態編譯的程序來說，并不需要有操作系統提供運行時支持，所需的一切庫都已經在可執行文件里了，因此直接 from scratch 會讓鏡像體積更加小巧。使用 go 語言 開發的應用很多會使用這種方式來制作鏡像，這也是為什么有人認為 go是特別適合容器微服務架構的語言的原因之一。

run 執行命令

run 指令是用來執行命令行命令的。由于命令行的強大能力， run 指令在定制鏡像時是最常用的指令之一。其格式有兩種：

shell 格式： run <命令> ，就像直接在命令行中輸入的命令一樣。剛才寫的 dockerfile 中的 run 指令就是這種格式。

run echo '<h1>hello, docker!</h1>' > /usr/share/nginx/html/index.html

exec 格式： run ["可執行文件", "參數1", "參數2"]，這更像是函數調用中的格式。
既然 run 就像 shell 腳本一樣可以執行命令，那么我們是否就可以像 shell 腳本一樣把每個命令對應一個 run 呢？比如這樣：

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 這一層的修改，構成新的鏡像。

而上面的這種寫法，創建了 7 層鏡像。這是完全沒有意義的，而且很多運行時不需要的東西，都被裝進了鏡像里，比如編譯環境、更新的軟件包等等。結果就是產生非常臃腫、非常多層的鏡像，不僅僅增加了構建部署的時間，也很容易出錯。 這是很多初學 docker 的人常犯的一個錯誤（我也不能原諒自己ε=(&acute;ο｀*)))唉）。

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 制作出了很臃腫的鏡像的原因之一，就是忘記了每一層構建的最后一定要清理掉無關文件。

構建鏡像

好了，讓我們再回到之前定制的 nginx 鏡像的 dockerfile 來。現在我們明白了這個 dockerfile的內容，那么讓我們來構建這個鏡像吧。

在 dockerfile 文件所在目錄執行：

$ docker build -t nginx:v3 .
sending build context to docker daemon 2.048 kb
step 1 : from nginx
---> e43d811ce2f4
step 2 : run echo '<h1>hello, docker!</h1>' > /usr/share/nginx/html/index.html
---> running in 9cdc27646c7b
---> 44aa4490ce2c
removing intermediate container 9cdc27646c7b
successfully built 44aa4490ce2c

從命令的輸出結果中，我們可以清晰的看到鏡像的構建過程。在 step 2 中，如同我們之前所說的那樣， run 指令啟動了一個容器 9cdc27646c7b ，執行了所要求的命令，并最后提交了這一層 44aa4490ce2c ，隨后刪除了所用到的這個容器 9cdc27646c7b 。

這里我們使用了 docker build 命令進行鏡像構建。其格式為：

docker build [選項] <上下文路徑/url/->

在這里我們指定了最終鏡像的名稱 -t nginx:v3 ，構建成功后，我們可以直接運行這個鏡像，其結果就是我們的主頁被改變成了hello, docker!。

鏡像構建上下文（context）

如果注意，會看到 docker build 命令最后有一個 . 。 . 表示當前目錄，而 dockerfile就在當前目錄，因此不少初學者以為這個路徑是在指定 dockerfile 所在路徑，這么理解其實是不準確的。如果對應上面的命令格式，你可能會發現，這是在指定上下文路徑。那么什么是上下文呢？

首先我們要理解 docker build 的工作原理。docker 在運行時分為 docker 引擎（也就是服務端守護進程）和客戶端工具。docker 的引擎提供了一組 rest api，被稱為 dockerremote 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 build 的用法

直接用 git repo 進行構建

或許你已經注意到了， docker build 還支持從 url 構建，比如可以直接從 git repo 中構建：

$ docker build https://github.com/twang2218/gitlab-ce-zh.git#:8.14
docker build https://github.com/twang2218/gitlab-ce-zh.git\#:8.14
sending build context to docker daemon 2.048 kb
step 1 : from gitlab/gitlab-ce:8.14.0-ce.0
8.14.0-ce.0: pulling from gitlab/gitlab-ce
aed15891ba52: already exists
773ae8583d14: already exists
...

這行命令指定了構建所需的 git repo，并且指定默認的 master 分支，構建目錄為 /8.14/ ，然后 docker 就會自己去 git clone 這個項目、切換到指定分支、并進入到指定目錄后開始構建。

用給定的 tar 壓縮包構建

$ docker build http://server/context.tar.gz

如果所給出的 url 不是個 git repo，而是個 tar 壓縮包，那么 docker 引擎會下載這個包，并自動解壓縮，以其作為上下文，開始構建。

從標準輸入中讀取 dockerfile 進行構建

docker build - < dockerfile

或

cat dockerfile | docker build -

如果標準輸入傳入的是文本文件，則將其視為 dockerfile ，并開始構建。這種形式由于直接從標準輸入中讀取 dockerfile 的內容，它沒有上下文，因此不可以像其他方法那樣可以將本地文件 copy 進鏡像之類的事情。

從標準輸入中讀取上下文壓縮包進行構建

$ docker build - < context.tar.gz

如果發現標準輸入的文件格式是 gzip 、 bzip2 以及 xz 的話，將會使其為上下文壓縮包，直接將其展開，將里面視為上下文，并開始構建。

copy 復制文件
格式：

• copy <源路徑>... <目標路徑>

• copy ["<源路徑1>",... "<目標路徑>"]

和 run 指令一樣，也有兩種格式，一種類似于命令行，一種類似于函數調用。copy 指令將從構建上下文目錄中 <源路徑> 的文件/目錄復制到新的一層的鏡像內的 <目標路徑> 位置。比如：

copy package.json /usr/src/app/

<源路徑> 可以是多個，甚至可以是通配符，其通配符規則要滿足 go 的 filepath.match 規則，如：

copy hom* /mydir/
copy hom?.txt /mydir/

<目標路徑> 可以是容器內的絕對路徑，也可以是相對于工作目錄的相對路徑（工作目錄可以用 workdir 指令來指定）。目標路徑不需要事先創建，如果目錄不存在會在復制文件前先行創建缺失目錄。

此外，還需要注意一點，使用 copy 指令，源文件的各種元數據都會保留。比如讀、寫、執行權限、文件變更時間等。這個特性對于鏡像定制很有用。特別是構建相關文件都在使用 git進行管理的時候。

add 更高級的復制文件

add 指令和 copy 的格式和性質基本一致。但是在 copy 基礎上增加了一些功能。比如 <源路徑> 可以是一個 url ，這種情況下，docker 引擎會試圖去下載這個鏈接的文件放到 <目標路徑> 去。下載后的文件權限自動設置為 600 ，如果這并不是想要的權限，那么還需要增加額外的一層 run 進行權限調整，另外，如果下載的是個壓縮包，需要解壓縮，也一樣還需要額外的一層 run 指令進行解壓縮。所以不如直接使用 run 指令，然后使用 wget 或者 curl 工具下載，處理權限、解壓縮、然后清理無用文件更合理。因此，這個功能其實并不實用，而且不推薦使用。

如果 <源路徑> 為一個 tar 壓縮文件的話，壓縮格式為 gzip , bzip2 以及 xz 的情況下， add 指令將會自動解壓縮這個壓縮文件到 <目標路徑> 去。

在某些情況下，這個自動解壓縮的功能非常有用，比如官方鏡像 ubuntu 中：

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 命令，則是希望 systemd 來以后臺守護進程形式啟動 nginx 服務。而剛才說了 cmd service nginx start 會被理解為 cmd [ “sh”, “-c”, “service nginxstart”] ，因此主進程實際上是 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 指令，換句話說實際執行時，將變為：

<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 中去執行，而這個腳本會將接到的參數（也就是 ）作為命令，在腳本最后執行。比如官方鏡像 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 為 dockerentrypoint.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 設置環境變量

格式有兩種：

1. env <key> <value>

2. env <key1>=<value1> <key2>=<value2>...

這個指令很簡單，就是設置環境變量而已，無論是后面的其它指令，如 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.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

在這里先定義了環境變量 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)中。為了防止運行時用戶忘記將動態文件所保存目錄掛載為卷，在 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 都是啟動一個容器、執行命令、然后提交存儲層文件變更。第一層 runcd /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  || 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 (health: healthy)     80/tcp, 443/tcp     web

如果健康檢查連續失敗超過了重試次數，狀態就會變為 (unhealthy) 。

為了幫助排障，健康檢查命令的輸出（包括 stdout 以及 stderr ）都會被存儲于健康狀態里，可以用 docker inspect 來查看。

$ docker inspect --format '{{json .state.health}}' upbeat_allen | python -m json.tool
{
  "failingstreak": 0,
  "log": [
    {
      "end": "2018-06-14t04:55:37.477730277-04: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>\n",
      "start": "2018-06-14t04:55:37.408045977-04:00"
    },
    {
      "end": "2018-06-14t04:55:42.553816257-04: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>\n",
      "start": "2018-06-14t04:55:42.480940888-04:00"
    },
    {
      "end": "2018-06-14t04:55:47.631694051-04: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>\n",
      "start": "2018-06-14t04:55:47.557214953-04:00"
    },
    {
      "end": "2018-06-14t04:55:52.708195002-04: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>\n",
      "start": "2018-06-14t04:55:52.63499573-04:00"
    },
    {
      "end": "2018-06-14t04:55:57.795117794-04: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>\n",
      "start": "2018-06-14t04:55:57.714289056-04:00"
    }
  ],
  "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" ]

這里我們把項目相關的構建指令拿出來，放到子項目里去。假設這個基礎鏡像的名字為 mynode 的話，各個項目內的自己的 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 ，生成應用鏡像。

以上就是關于“怎么使用Docker Dockerfile定制鏡像”這篇文章的內容，相信大家都有了一定的了解，希望小編分享的內容對大家有幫助，若想了解更多相關的知識內容，請關注億速云行業資訊頻道。