Dockerfile文件中，除了有FROM指令和RUN指令外，還有幾個比較常用的指令

• 1、 COTY 復制文件

格式：

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

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

COPY package.json /usr/src/app/

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

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

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

• 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 官方的最佳實踐文檔中要求，盡可能的使用 COPY，因為 COPY 的語義很明確，就是復制文件而已，而 ADD 則包含了更復雜的功能，其行為也不一定很清晰。最適合使用 ADD 的場合，就是所提及的需要自動解壓縮的場合。

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

因此在 COPY 和 ADD 指令中選擇的時候，可以遵循這樣的原則，所有的文件復制均使用 COPY 指令，僅在需要自動解壓縮的場合使用 ADD。

***
- 3、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;"]

***
- 4、ENTRYPOINT 入口點
> ENTRYPOINT 的格式和 RUN 指令格式一樣，分為 exec 格式和 shell 格式。
ENTRYPOINT 的目的和 CMD 一樣，都是在指定容器啟動程序及參數。ENTRYPOINT 在運行時也可以替代，不過比 CMD 要略顯繁瑣，需要通過 docker run 的參數 --entrypoint 來指定。
當指定了 ENTRYPOINT 后，CMD 的含義就發生了改變，不再是直接的運行其命令，而是將 CMD 的內容作為參數傳給 ENTRYPOINT 指令，換句話說實際執行時，將變為：

<ENTRYPOINT> "<CMD>"

***
- 5、ENV 設置環境變量
> 格式有兩種：

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

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

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

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

***
- 7、VOLUME 定義匿名卷
> 格式為：

VOLUME ["<路徑1>", "<路徑2>"...]
VOLUME <路徑>

之前我們說過，容器運行時應該盡量保持容器存儲層不發生寫操作，對于數據庫類需要保存動態數據的應用，其數據庫文件應該保存于卷(volume)中，后面的章節我們會進一步介紹 Docker 卷的概念。為了防止運行時用戶忘記將動態文件所保存目錄掛載為卷，在 Dockerfile 中，我們可以事先指定某些目錄掛載為匿名卷，這樣在運行時如果用戶不指定掛載，其應用也可以正常運行，不會向容器存儲層寫入大量數據。

VOLUME /data

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

docker run -d -v mydata:/data xxxx

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

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

***
- 9、WORKDIR 指定工作目錄
> 格式為 WORKDIR <工作目錄路徑>。
使用 WORKDIR 指令可以來指定工作目錄（或者稱為當前目錄），以后各層的當前目錄就被改為指定的目錄，如該目錄不存在，WORKDIR 會幫你建立目錄。
之前提到一些初學者常犯的錯誤是把 Dockerfile 等同于 Shell 腳本來書寫，這種錯誤的理解還可能會導致出現下面這樣的錯誤：

RUN cd /app
RUN echo "hello" > world.txt

如果將這個 Dockerfile 進行構建鏡像運行后，會發現找不到 /app/world.txt 文件，或者其內容不是 hello。原因其實很簡單，在 Shell 中，連續兩行是同一個進程執行環境，因此前一個命令修改的內存狀態，會直接影響后一個命令；而在 Dockerfile 中，這兩行 RUN 命令的執行環境根本不同，是兩個完全不同的容器。這就是對 Dokerfile 構建分層存儲的概念不了解所導致的錯誤。
之前說過每一個 RUN 都是啟動一個容器、執行命令、然后提交存儲層文件變更。第一層 RUN cd /app 的執行僅僅是當前進程的工作目錄變更，一個內存上的變化而已，其結果不會造成任何文件變更。而到第二層的時候，啟動的是一個全新的容器，跟第一層的容器更完全沒關系，自然不可能繼承前一層構建過程中的內存變化。
因此如果需要改變以后各層的工作目錄的位置，那么應該使用 WORKDIR 指令。