Dockerfile的語法非常簡單，然而如何加快鏡像構建速度，如何減少Docker鏡像的大小卻不是那么直觀，需要積累實踐經驗。這篇文章可以幫助你快速掌握編寫Dockerfile的技巧。

目標

• 更快的構建速度
• 更小的Docker鏡像大小
• 更少的Docker鏡像層
• 充分利用鏡像緩存
• 增加Dockerfile可讀性
• 讓Docker容器使用起來更簡單

總結

• 編寫.dockerignore文件
• 容器只運行單個應用
• 將多個RUN指令合并為一個
• 基礎鏡像的標簽不要用latest
• 每個RUN指令后刪除多余文件
• 選擇合適的基礎鏡像(alpine版本最好)
• 設置WORKDIR和CMD
• 使用ENTRYPOINT (可選)
• 在entrypoint腳本中使用exec
• COPY與ADD優先使用前者
• 合理調整COPY與RUN的順序
• 設置默認的環境變量，映射端口和數據卷
• 使用LABEL設置鏡像元數據
• 添加HEALTHCHECK
• 多階段構建

示例

示例Dockerfile犯了幾乎所有的錯(當然我是故意的)。接下來，我會一步步優化它。假設我們需要使用Docker運行一個Node.js應用，下面就是它的Dockerfile(CMD指令太復雜了，所以我簡化了，它是錯誤的，僅供參考)。

FROM ubuntu
ADD . /app
RUN apt-get update  
RUN apt-get upgrade -y  
RUN apt-get install -y nodejs ssh mysql  
RUN cd /app && npm install
# this should start three processes, mysql and ssh
# in the background and node app in foreground
# isn't it beautifully terrible? <3
CMD mysql & sshd & npm start

構建鏡像：

你能發現上面Dockerfile所有的錯誤嗎? 不能? 那接下來讓我們一步一步完善它。

優化

1. 編寫.dockerignore文件

構建鏡像時，Docker需要先準備context ，將所有需要的文件收集到進程中。默認的context包含Dockerfile目錄中的所有文件，但是實際上，我們并不需要.git目錄，node_modules目錄等內容。 .dockerignore 的作用和語法類似于 .gitignore，可以忽略一些不需要的文件，這樣可以有效加快鏡像構建時間，同時減少Docker鏡像的大小。示例如下：

2. 容器只運行單個應用

從技術角度講，你可以在Docker容器中運行多個進程。你可以將數據庫，前端，后端，ssh，supervisor都運行在同一個Docker容器中。但是，這會讓你非常痛苦：

• 非常長的構建時間(修改前端之后，整個后端也需要重新構建)
• 非常大的鏡像大小
• 多個應用的日志難以處理(不能直接使用stdout，否則多個應用的日志會混合到一起)
• 橫向擴展時非常浪費資源(不同的應用需要運行的容器數并不相同)
• 僵尸進程問題 - 你需要選擇合適的init進程

因此，建議大家為每個應用構建單獨的Docker鏡像，然后使用 Docker Compose 運行多個Docker容器。現在，我從Dockerfile中刪除一些不需要的安裝包，另外，SSH可以用docker exec替代。示例如下：

FROM ubuntu
ADD . /app
RUN apt-get update  
RUN apt-get upgrade -y
# we should remove ssh and mysql, and use
# separate container for database 
RUN apt-get install -y nodejs  # ssh mysql  
RUN cd /app && npm install
CMD npm start

3. 將多個RUN指令合并為一個

Docker鏡像是分層的，下面這些知識點非常重要：

• Dockerfile中的每個指令都會創建一個新的鏡像層。
• 鏡像層將被緩存和復用
• 當Dockerfile的指令修改了，復制的文件變化了，或者構建鏡像時指定的變量不同了，對應的鏡像層緩存就會失效
• 某一層的鏡像緩存失效之后，它之后的鏡像層緩存都會失效
• 鏡像層是不可變的，如果我們再某一層中添加一個文件，然后在下一層中刪除它，則鏡像中依然會包含該文件(只是這個文件在Docker容器中不可見了)。

Docker鏡像類似于洋蔥。它們都有很多層。為了修改內層，則需要將外面的層都刪掉。記住這一點的話，其他內容就很好理解了。現在，我們將所有的RUN指令合并為一個。同時把apt-get upgrade刪除，因為它會使得鏡像構建非常不確定(我們只需要依賴基礎鏡像的更新就好了)。

FROM ubuntu
ADD . /app
RUN apt-get update \  
    && apt-get install -y nodejs \
    && cd /app \
    && npm install
CMD npm start

記住一點，我們只能將變化頻率一樣的指令合并在一起。將node.js安裝與npm模塊安裝放在一起的話，則每次修改源代碼，都需要重新安裝node.js，這顯然不合適。因此，正確的寫法是這樣的：

FROM ubuntu
RUN apt-get update && apt-get install -y nodejs  
ADD . /app  
RUN cd /app && npm install
CMD npm start

4. 基礎鏡像的標簽不要用latest

當鏡像沒有指定標簽時，將默認使用latest 標簽。因此， FROM ubuntu 指令等同于FROM ubuntu:latest。當時，當鏡像更新時，latest標簽會指向不同的鏡像，這時構建鏡像有可能失敗。如果你的確需要使用最新版的基礎鏡像，可以使用latest標簽，否則的話，最好指定確定的鏡像標簽。示例Dockerfile應該使用16.04作為標簽。

FROM ubuntu:16.04  # it's that easy!
RUN apt-get update && apt-get install -y nodejs  
ADD . /app  
RUN cd /app && npm install
CMD npm start

5. 每個RUN指令后刪除多余文件

假設我們更新了apt-get源，下載，解壓并安裝了一些軟件包，它們都保存在/var/lib/apt/lists/目錄中。但是，運行應用時Docker鏡像中并不需要這些文件。我們最好將它們刪除，因為它會使Docker鏡像變大。示例Dockerfile中，我們可以刪除/var/lib/apt/lists/目錄中的文件(它們是由apt-get update生成的)。

FROM ubuntu:16.04
RUN apt-get update \  
    && apt-get install -y nodejs \
    # added lines
    && rm -rf /var/lib/apt/lists/*
ADD . /app  
RUN cd /app && npm install
CMD npm start

6. 選擇合適的基礎鏡像(alpine版本最好)

在示例中，我們選擇了ubuntu作為基礎鏡像。但是我們只需要運行node程序，有必要使用一個通用的基礎鏡像嗎？node鏡像應該是更好的選擇。

FROM node
ADD . /app  
# we don't need to install node 
# anymore and use apt-get
RUN cd /app && npm install
CMD npm start

更好的選擇是alpine版本的node鏡像。alpine是一個極小化的Linux發行版，只有4MB，這讓它非常適合作為基礎鏡像。

FROM node:7-alpine
ADD . /app  
RUN cd /app && npm install
CMD npm start

apk是Alpine的包管理工具。它與apt-get有些不同，但是非常容易上手。另外，它還有一些非常有用的特性，比如no-cache和 --virtual選項，它們都可以幫助我們減少鏡像的大小。

7. 設置WORKDIR和 CMD

WORKDIR指令可以設置默認目錄，也就是運行RUN / CMD / ENTRYPOINT指令的地方。CMD指令可以設置容器創建是執行的默認命令。另外，你應該講命令寫在一個數組中，數組中每個元素為命令的每個單詞(參考官方文檔)。

FROM node:7-alpine
WORKDIR /app  
ADD . /app  
RUN npm install
CMD ["npm", "start"]

8. 使用ENTRYPOINT (可選)

ENTRYPOINT指令并不是必須的，因為它會增加復雜度。ENTRYPOINT是一個腳本，它會默認執行，并且將指定的命令當成參數接收。它通常用于構建可執行的Docker鏡像。entrypoint.sh如下:

示例Dockerfile:

FROM node:7-alpine
WORKDIR /app  
ADD . /app  
RUN npm install
ENTRYPOINT ["./entrypoint.sh"]  
CMD ["start"]

可以使用如下命令運行該鏡像:

9. 在entrypoint腳本中使用exec

在前文的entrypoint腳本中，我使用了exec命令運行node應用。不使用exec的話，我們則不能順利地關閉容器，因為SIGTERM信號會被bash腳本進程吞沒。exec命令啟動的進程可以取代腳本進程，因此所有的信號都會正常工作。這里擴展介紹一下docker容器的停止過程：(1). 對于容器來說，init 系統不是必須的，當你通過命令 docker stop mycontainer 來停止容器時，docker CLI 會將 TERM 信號發送給 mycontainer 的 PID 為 1 的進程。

• 如果 PID 1 是 init 進程 - 那么 PID 1 會將 TERM 信號轉發給子進程，然后子進程開始關閉，最后容器終止。
• 如果沒有 init 進程- 那么容器中的應用進程（Dockerfile 中的ENTRYPOINT或CMD指定的應用）就是 PID 1，應用進程直接負責響應TERM信號。這時又分為兩種情況：

應用不處理 SIGTERM - 如果應用沒有監聽 SIGTERM 信號，或者應用中沒有實現處理 SIGTERM 信號的邏輯，應用就不會停止，容器也不會終止。

容器停止時間很長 - 運行命令 docker stop mycontainer 之后，Docker 會等待 10s，如果 10s 后容器還沒有終止，Docker 就會繞過容器應用直接向內核發送 SIGKILL，內核會強行殺死應用，從而終止容器。

(2).如果容器中的進程沒有收到 SIGTERM 信號，很有可能是因為應用進程不是 PID 1，PID 1 是 shell，而應用進程只是 shell 的子進程。而 shell 不具備 init 系統的功能，也就不會將操作系統的信號轉發到子進程上，這也是容器中的應用沒有收到 SIGTERM 信號的常見原因。問題的根源就來自 Dockerfile，例如：

FROM alpine:3.7
COPY popcorn.sh .
RUN chmod +x popcorn.sh
ENTRYPOINT ./popcorn.sh
CMD ["start"]

ENTRYPOINT 指令使用的是 **shell 模式**，這樣 Docker 就會把應用放到 shell 中運行，因此 shell 是 PID 1。解決方案有以下幾種：

方案 1：使用 exec 模式的 ENTRYPOINT 指令

與其使用 shell 模式，不如使用 exec 模式，例如：

FROM alpine:3.7
COPY popcorn.sh .
RUN chmod +x popcorn.sh
ENTRYPOINT ["./popcorn.sh"]

這樣 PID 1 就是 ./popcorn.sh，它將負責響應所有發送到容器的信號，至于 ./popcorn.sh 是否真的能捕捉到系統信號，那是另一回事。舉個例子，假設使用上面的 Dockerfile 來構建鏡像，popcorn.sh 腳本每過一秒打印一次日期：

#!/bin/sh

while true
do
    date
    sleep 1
done

構建鏡像并創建容器：

docker build -t truek8s/popcorn .
docker run -it --name corny --rm truek8s/popcorn

打開另外一個終端執行停止容器的命令，并計時：

time docker stop corny

因為 popcorn.sh 并沒有實現捕獲和處理 SIGTERM 信號的邏輯，所以需要 10s 左右才能停止容器。要想解決這個問題，就要往腳本中添加信號處理代碼，讓它捕獲到 SIGTERM 信號時就終止進程：

#!/bin/sh
# catch the TERM signal and then exit
trap "exit" TERM
while true
do
    date
    sleep 1
done

注意：下面這條指令與 shell 模式的 ENTRYPOINT 指令是等效的：

ENTRYPOINT ["/bin/sh", "./popcorn.sh"]

方案 2：直接使用 exec 命令

如果你就想使用 shell 模式的 ENTRYPOINT 指令，也不是不可以，只需將啟動命令追加到 exec 后面即可，例如：

FROM alpine:3.7
COPY popcorn.sh .
RUN chmod +x popcorn.sh
ENTRYPOINT exec ./popcorn.sh

這樣 exec 就會將 shell 進程替換為 ./popcorn.sh 進程，PID 1 仍然是 ./popcorn.sh。

方案 3：使用 init 系統

如果容器中的應用默認無法處理 SIGTERM 信號，又不能修改代碼，這時候方案 1 和 2 都行不通了，只能在容器中添加一個 init 系統。init 系統有很多種，這里推薦使用 tini，它是專用于容器的輕量級 init 系統，使用方法也很簡單：

1. 安裝 tini
2. 將 tini 設為容器的默認應用
3. 將 popcorn.sh 作為 tini 的參數

具體的 Dockerfile 如下：

FROM alpine:3.7
COPY popcorn.sh .
RUN chmod +x popcorn.sh
RUN apk add --no-cache tini
ENTRYPOINT ["/sbin/tini", "--", "./popcorn.sh"]

現在 ``` tini

就是 PID 1，它會將收到的系統信號轉發給子進程 ```
popcorn.sh

10. COPY與ADD優先使用前者

COPY指令非常簡單，僅用于將文件拷貝到鏡像中。ADD相對來講復雜一些，可以用于下載遠程文件以及解壓壓縮包(參考官方文檔)。

FROM node:7-alpine
WORKDIR /app
COPY . /app  
RUN npm install
ENTRYPOINT ["./entrypoint.sh"]  
CMD ["start"]

11. 合理調整COPY與RUN的順序

我們應該把變化最少的部分放在Dockerfile的前面，這樣可以充分利用鏡像緩存。在構建鏡像的時候,docker 會按照dockerfile中的指令順序來一次執行。每一個指令被執行的時候 docker 都會去緩存中檢查是否有已經存在的鏡像可以復用，而不是去創建一個新的鏡像復制。如果不想使用構建緩存,可以使用docker build參數選項--no-cache=true來禁用構建緩存。在使用鏡像緩存時,要弄清楚緩存合適生效,何時失效。構建緩存最基本規則如下:

• 如果引用的父鏡像在構建緩存中,下一個命令將會和所有從該父進程派生的子鏡像做比較,如果有子鏡像使用相同的命令,那么緩存命中,否則緩存失效。
• 在大部分情況下,通過比較Dockerfile中的指令和子鏡像已經足夠了。但是有些指令需要進一步的檢查。
• 對于ADD和COPY指令, 文件的內容會被檢查,并且會計算每一個文件的校驗碼。但是文件最近一次的修改和訪問時間不在校驗碼的考慮范圍內。在構建過程中,docker 會比對已經存在的鏡像,只要有文件內容和元數據發生變動，那么緩存就會失效。
• 除了ADD和COPY指令,鏡像緩存不會檢查容器中文件來判斷是否命中緩存。例如,在處理RUN apt-get -y update命令時,不會檢查容器中的更新文件以確定是否命中緩存,這種情況下只會檢查命令字符串是否相同。

示例中，源代碼會經常變化，則每次構建鏡像時都需要重新安裝NPM模塊，這顯然不是我們希望看到的。因此我們可以先拷貝package.json，然后安裝NPM模塊，最后才拷貝其余的源代碼。這樣的話，即使源代碼變化，也不需要重新安裝NPM模塊。

FROM node:7-alpine
WORKDIR /app
COPY package.json /app  
RUN npm install  
COPY . /app
ENTRYPOINT ["./entrypoint.sh"]  
CMD ["start"]

同樣舉一反三，Python項目的時候，我們同樣可以先拷貝requerements.txt,然后進行pip install requerements.txt，最后再進行COPY 代碼。

ROM python:3.6
# 創建 app 目錄
WORKDIR /app
# 安裝 app 依賴
COPY src/requirements.txt ./
RUN pip install -r requirements.txt
# 打包 app 源碼
COPY src /app
EXPOSE 8080
CMD [ "python", "server.py" ]

## 12. 設置默認的環境變量，映射端口和數據卷 運行Docker容器時很可能需要一些環境變量。在Dockerfile設置默認的環境變量是一種很好的方式。另外，我們應該在Dockerfile中設置映射端口和數據卷。示例如下: ```dockerfile FROM node:7-alpine ENV PROJECT_DIR=/app WORKDIRPROJECT_DIR   RUN npm install   COPY .MEDIA_DIR   EXPOSE $APP_PORT ENTRYPOINT ["./entrypoint.sh"]   CMD ["start"] ``` [ENV](https://docs.docker.com/engine/reference/builder/#env)指令指定的環境變量在容器中可以使用。如果你只是需要指定構建鏡像時的變量，你可以使用[ARG](https://docs.docker.com/engine/reference/builder/#arg)指令。

13. 使用LABEL設置鏡像元數據

使用LABEL指令，可以為鏡像設置元數據，例如鏡像創建者或者鏡像說明。舊版的Dockerfile語法使用MAINTAINER指令指定鏡像創建者，但是它已經被棄用了。有時，一些外部程序需要用到鏡像的元數據，例如nvidia-docker需要用到com.nvidia.volumes.needed。示例如下:

FROM node:7-alpine  
LABEL maintainer "jakub.skalecki@example.com"  
...

14. 添加HEALTHCHECK

運行容器時，可以指定--restart always選項。這樣的話，容器崩潰時，Docker守護進程(docker daemon)會重啟容器。對于需要長時間運行的容器，這個選項非常有用。但是，如果容器的確在運行，但是不可(陷入死循環，配置錯誤)用怎么辦？使用HEALTHCHECK指令可以讓Docker周期性的檢查容器的健康狀況。我們只需要指定一個命令，如果一切正常的話返回0，否則返回1。對HEALTHCHECK感興趣的話，可以參考這篇博客。示例如下:

FROM node:7-alpine  
LABEL maintainer "jakub.skalecki@example.com"
ENV PROJECT_DIR=/app  
WORKDIR $PROJECT_DIR
COPY package.json $PROJECT_DIR  
RUN npm install  
COPY . $PROJECT_DIR
ENV MEDIA_DIR=/media \  
    NODE_ENV=production \
    APP_PORT=3000
VOLUME $MEDIA_DIR  
EXPOSE $APP_PORT  
HEALTHCHECK CMD curl --fail http://localhost:$APP_PORT || exit 1
ENTRYPOINT ["./entrypoint.sh"]  
CMD ["start"]

當請求失敗時，curl --fail 命令返回非0狀態。

15. 多階段構建

參考文檔《https://docs.docker.com/develop/develop-images/multistage-build/》在docker不支持多階段構建的年代，我們構建docker鏡像時通常會采用如下兩種方法：方法A.將所有的構建過程編寫在同一個Dockerfile中，包括項目及其依賴庫的編譯、測試、打包等流程，可能會有如下問題：

• Dockerfile可能會特別臃腫
• 鏡像層次特別深
• 存在源碼泄露的風險

方法B.事先在外部將項目及其依賴庫編譯測試打包好后，再將其拷貝到構建目錄中執行構建鏡像。方法B較方法A略顯優雅一些，而且可以很好地規避方法A存在的風險點，但仍需要我們編寫兩套或多套Dockerfile或者一些腳本才能將其兩個階段自動整合起來，例如有多個項目彼此關聯和依賴，就需要我們維護多個Dockerfile，或者需要編寫更復雜的腳本，導致后期維護成本很高。為解決以上問題，**Docker v17.05 開始支持多階段構建 (multistage builds)**。使用多階段構建我們就可以很容易解決前面提到的問題，并且只需要編寫一個 Dockerfile。你可以在一個 Dockerfile 中使用多個 FROM 語句。每個 FROM 指令都可以使用不同的基礎鏡像，并表示開始一個新的構建階段。你可以很方便的將一個階段的文件復制到另外一個階段，在最終的鏡像中保留下你需要的內容即可。默認情況下，構建階段是沒有命令的，我們可以通過它們的索引來引用它們，第一個 FROM 指令從0開始，我們也可以用AS指令為構建階段命名。

案例1

FROM golang:1.7.3
WORKDIR /go/src/github.com/alexellis/href-counter/
RUN go get -d -v golang.org/x/net/html
COPY app.go .
RUN CGO_ENABLED=0 GOOS=linux go build -a -installsuffix cgo -o app .

FROM alpine:latest
RUN apk --no-cache add ca-certificates
WORKDIR /root/
COPY --from=0 /go/src/github.com/alexellis/href-counter/app .
CMD ["./app"]

通過 docker build 構建后，最終結果是產生與之前相同大小的 Image，但復雜性顯著降低。您不需要創建任何中間 Image，也不需要將任何編譯結果臨時提取到本地系統。哪它是如何工作的呢？關鍵就在 COPY --from=0 這個指令上。Dockerfile 中第二個 FROM 指令以 alpine:latest 為基礎鏡像開始了一個新的構建階段，并通過 COPY --from=0 僅將前一階段的構建文件復制到此階段。前一構建階段中產生的 Go SDK 和任何中間層都會在此階段中被舍棄，而不是保存在最終 Image 中。使用多階段構建一個python應用。

案例2

默認情況下，構建階段是未命名的。您可以通過一個整數值來引用它們，默認是從第 0 個 FROM 指令開始的。 為了方便管理，您也可以通過向 FROM 指令添加 as NAME 來命名您的各個構建階段。下面的示例就通過命名各個構建階段并在 COPY 指令中使用名稱來訪問指定的構建階段。這樣做的好處就是即使稍后重新排序 Dockerfile 中的指令，COPY 指令一樣能找到對應的構建階段。

FROM golang:1.7.3 as builder
WORKDIR /go/src/github.com/alexellis/href-counter/
RUN go get -d -v golang.org/x/net/html
COPY app.go    .
RUN CGO_ENABLED=0 GOOS=linux go build -a -installsuffix cgo -o app .

FROM alpine:latest
RUN apk --no-cache add ca-certificates
WORKDIR /root/
COPY --from=builder /go/src/github.com/alexellis/href-counter/app .
CMD ["./app"]

案例3

停在特定的構建階段構建鏡像時，不一定需要構建整個 Dockerfile 中每個階段，您也可以指定需要構建的階段。比如：您只構建 Dockerfile 中名為 builder 的階段

$ docker build --target builder -t alexellis2/href-counter:latest .

此功能適合以下場景：

• 調試特定的構建階段。
• 在 Debug 階段，啟用所有程序調試模式或調試工具，而在生產階段盡量精簡。
• 在 Testing 階段，您的應用程序使用測試數據，但在生產階段則使用生產數據。

案例4

使用外部鏡像作為構建階段使用多階段構建時，您不僅可以從 Dockerfile 中創建的鏡像中進行復制。您還可以使用 COPY --from 指令從單獨的 Image 中復制，支持使用本地 Image 名稱、本地或 Docker 注冊中心可用的標記或標記 ID。

COPY --from=nginx:latest /etc/nginx/nginx.conf /nginx.conf

案例5

把前一個階段作為一個新的階段在使用 FROM 指令時，您可以通過引用前一階段停止的地方來繼續。同樣，采用此方式也可以方便一個團隊中的不同角色，如何使用類似流水線的方式，一級一級提供基礎鏡像，同樣更方便快速的復用團隊其他人的基礎鏡像。例如:

FROM alpine:latest as builder
RUN apk --no-cache add build-base
FROM builder as build1
COPY source1.cpp source.cpp
RUN g++ -o /binary source.cpp
FROM builder as build2
COPY source2.cpp source.cpp
RUN g++ -o /binary source.cpp

# ---- 基礎 python 鏡像 ----
FROM python:3.6 AS base
# 創建 app 目錄
WORKDIR /app
# ---- 依賴 ----
FROM base AS dependencies  
COPY gunicorn_app/requirements.txt ./
# 安裝 app 依賴
RUN pip install -r requirements.txt
# ---- 復制文件并 build ----
FROM dependencies AS build  
WORKDIR /app
COPY . /app
# 在需要時進行 Build 或 Compile
# --- 使用 Alpine 發布 ----
FROM python:3.6-alpine3.7 AS release  
# 創建 app 目錄
WORKDIR /app
COPY --from=dependencies /app/requirements.txt ./
COPY --from=dependencies /root/.cache /root/.cache
# 安裝 app 依賴
RUN pip install -r requirements.txt
COPY --from=build /app/ ./
CMD ["gunicorn", "--config", "./gunicorn_app/conf/gunicorn_config.py", "gunicorn_app:app"]