理解Docker的多階段鏡像構建

作者：佚名 2017-11-13 17:17:11

什么是鏡像多階段構建呢?直接給出概念定義太突兀，這里先賣個關子，我們先從日常開發中用到的鏡像構建的方式和所遇到的鏡像構建的問題說起。

Docker技術從 2013年誕生到目前已經4年有余了。對于已經接納和使用 Docker技術在日常開發工作中的開發者而言，構建 Docker鏡像已經是家常便飯。但這是否意味著Docker的image構建機制已經相對完美了呢?不是的，Docker官方依舊在持續優化鏡像構建機制。這不，從今年發布的 Docker 17.05版本起，Docker開始支持容器鏡像的多階段構建(multi-stage build) 了。

什么是鏡像多階段構建呢?直接給出概念定義太突兀，這里先賣個關子，我們先從日常開發中用到的鏡像構建的方式和所遇到的鏡像構建的問題說起。

一、同構的鏡像構建

我們在做鏡像構建時的一個常見的場景就是：應用在開發者自己的開發機或服務器上直接編譯，編譯出的二進制程序再打入鏡像。這種情況一般要求編譯環境與鏡像所使用的base image是兼容的，比如說：我在 Ubuntu 14.04 上編譯應用，并將應用打入基于 ubuntu系列base image 的鏡像。這種構建我稱之為“同構的鏡像構建”，因為應用的編譯環境與其部署運行的環境是兼容的：我在Ubuntu 14.04下編譯出來的應用，可以基本無縫地在基于ubuntu:14.04及以后版本base image鏡像(比如：16.04、16.10、17.10等)中運行;但在不完全兼容的base image中，比如 centos 中就可能會運行失敗。

1、同構鏡像構建舉例

這里舉個同構鏡像構建的例子(后續的章節也是基于這個例子的)，注意：我們的編譯環境為 Ubuntu 16.04 x86_64虛擬機、Go 1.8.3和docker 17.09.0-ce 。

我們用一個Go語言中最常見的http server作為例子：

// github.com/bigwhite/experiments/multi_stage_image_build/isomorphism/httpserver.go 
package main 
 
import ( 
        "net/http" 
        "log" 
        "fmt" 
) 
 
func home(w http.ResponseWriter, req *http.Request) { 
        w.Write([]byte("Welcome to this website!\n")) 
} 
 
func main() { 
        http.HandleFunc("/", home) 
        fmt.Println("Webserver start") 
        fmt.Println("  -> listen on port:1111") 
        err := http.ListenAndServe(":1111", nil) 
        if err != nil { 
                log.Fatal("ListenAndServe:", err) 
        } 
}

編譯這個程序：

# go build -o myhttpserver httpserver.go 
# ./myhttpserver 
Webserver start 
  -> listen on port:1111

這個例子看起來很簡單，也沒幾行代碼，但背后Go net/http包在底層做了大量的事情，包括很多系統調用，能夠反映出應用與操作系統的“耦合”，這在后續的講解中會體現出來。接下來我們就來為這個程序構建一個docker image，并基于這個image來啟動一個myhttpserver容器。我們選擇ubuntu:14.04作為base image：

// github.com/bigwhite/experiments/multi_stage_image_build/isomorphism/Dockerfile 
From ubuntu:14.04 
 
COPY ./myhttpserver /root/myhttpserver 
RUN chmod +x /root/myhttpserver 
 
WORKDIR /root 
ENTRYPOINT ["/root/myhttpserver"]

執行構建：

# docker build -t myrepo/myhttpserver:latest . 
Sending build context to Docker daemon  5.894MB 
Step 1/5 : FROM ubuntu:14.04 
 ---> dea1945146b9 
Step 2/5 : COPY ./myhttpserver /root/myhttpserver 
 ---> 993e5129c081 
Step 3/5 : RUN chmod +x /root/myhttpserver 
 ---> Running in 104d84838ab2 
 ---> ebaeca006490 
Removing intermediate container 104d84838ab2 
Step 4/5 : WORKDIR /root 
 ---> 7afdc2356149 
Removing intermediate container 450ccfb09ffd 
Step 5/5 : ENTRYPOINT /root/myhttpserver 
 ---> Running in 3182766e2a68 
 ---> 77f315e15f14 
Removing intermediate container 3182766e2a68 
Successfully built 77f315e15f14 
Successfully tagged myrepo/myhttpserver:latest 
 
# docker images 
REPOSITORY            TAG                 IMAGE ID            CREATED             SIZE 
myrepo/myhttpserver   latest              77f315e15f14        18 seconds ago      200MB 
 
# docker run myrepo/myhttpserver 
Webserver start 
  -> listen on port:1111

以上是最基本的image build方法。

接下來，我們可能會遇到如下需求：

* 搭建一個Go程序的構建環境有時候是很耗時的，尤其是對那些依賴很多第三方開源包的Go應用來說，下載包就需要很長時間。我們最好將這些易變的東西統統打包到一個用于Go程序構建的builder image中;

* 我們看到上面我們構建出的myrepo/myhttpserver image的SIZE是200MB，這似乎有些過于“龐大”了。雖然每個主機node上的docker有cache image layer的能力，但我們還是希望能build出更加精簡短小的image。

2、借助golang builder image

Docker Hub上提供了一個帶有go dev環境的官方 golang image repository ，我們可以直接使用這個golang builder image來輔助構建我們的應用image;對于一些對第三方包依賴較多的Go應用，我們也可以以這個golang image為base image定制我們自己的專用builder image。

我們基于golang:latest這個base image構建我們的golang-builder image，我們編寫一個Dockerfile.build用于build golang-builder image:

// github.com/bigwhite/experiments/multi_stage_image_build/isomorphism/Dockerfile.build 
FROM golang:latest 
 
WORKDIR /go/src 
COPY httpserver.go . 
 
RUN go build -o myhttpserver ./httpserver.go

在同目錄下構建golang-builder image:

# docker build -t myrepo/golang-builder:latest -f Dockerfile.build . 
Sending build context to Docker daemon  5.895MB 
Step 1/4 : FROM golang:latest 
 ---> 1a34fad76b34 
Step 2/4 : WORKDIR /go/src 
 ---> 2361824677d3 
Removing intermediate container 01d8f4e9f0c4 
Step 3/4 : COPY httpserver.go . 
 ---> 1ff14bb0bc56 
Step 4/4 : RUN go build -o myhttpserver ./httpserver.go 
 ---> Running in 37a1b76b7b9e 
 ---> 2ac5347bb923 
Removing intermediate container 37a1b76b7b9e 
Successfully built 2ac5347bb923 
Successfully tagged myrepo/golang-builder:latest 
 
REPOSITORY              TAG                 IMAGE ID            CREATED             SIZE 
myrepo/golang-builder   latest              2ac5347bb923        3 minutes ago       739MB

接下來，我們就基于golang-builder中已經build完畢的myhttpserver來構建我們最終的應用image：

# docker create --name appsource myrepo/golang-builder:latest 
# docker cp appsource:/go/src/myhttpserver ./ 
# docker rm -f appsource 
# docker rmi myrepo/golang-builder:latest 
# docker build -t myrepo/myhttpserver:latest .

這段命令的邏輯就是從基于golang-builder image啟動的容器appsource中將已經構建完畢的myhttpserver拷貝到主機當前目錄中，然后刪除臨時的container appsource以及上面構建的那個golang-builder image;最后的步驟和第一個例子一樣，基于本地目錄中的已經構建完的myhttpserver構建出最終的image。為了方便，你也可以將這一系列命令放到一個Makefile中去。

3、使用size更小的alpine image

builder image并不能幫助我們為最終的應用image“減重”，myhttpserver image的Size依舊停留在200MB。要想“減重”，我們需要更小的base image，我們選擇了 alpine 。 Alpine image 的size不到4M，再加上應用的size，最終應用Image的Size估計可以縮減到20M以下。

結合builder image，我們只需將Dockerfile的base image改為alpine:latest：

// github.com/bigwhite/experiments/multi_stage_image_build/isomorphism/Dockerfile.alpine 
 
From alpine:latest 
 
COPY ./myhttpserver /root/myhttpserver 
RUN chmod +x /root/myhttpserver 
 
WORKDIR /root 
ENTRYPOINT ["/root/myhttpserver"]

構建alpine版應用image:

# docker build -t myrepo/myhttpserver-alpine:latest -f Dockerfile.alpine . 
Sending build context to Docker daemon  6.151MB 
Step 1/5 : FROM alpine:latest 
 ---> 053cde6e8953 
Step 2/5 : COPY ./myhttpserver /root/myhttpserver 
 ---> ca0527a62d39 
Step 3/5 : RUN chmod +x /root/myhttpserver 
 ---> Running in 28d0a8a577b2 
 ---> a3833af97b5e 
Removing intermediate container 28d0a8a577b2 
Step 4/5 : WORKDIR /root 
 ---> 667345b78570 
Removing intermediate container fa59883e9fdb 
Step 5/5 : ENTRYPOINT /root/myhttpserver 
 ---> Running in adcb5b976ca3 
 ---> 582fa2aedc64 
Removing intermediate container adcb5b976ca3 
Successfully built 582fa2aedc64 
Successfully tagged myrepo/myhttpserver-alpine:latest 
 
# docker images 
REPOSITORY                   TAG                 IMAGE ID            CREATED             SIZE 
myrepo/myhttpserver-alpine   latest              582fa2aedc64        4 minutes ago       16.3MB

16.3MB，Size的確降下來了!我們基于該image啟動一個容器，看應用運行是否有什么問題：

# docker run myrepo/myhttpserver-alpine:latest 
standard_init_linux.go:185: exec user process caused "no such file or directory"

容器啟動失敗了!為什么呢?因為alpine image并非ubuntu環境的同構image。我們在下面詳細說明。

二、異構的鏡像構建

我們的image builder: myrepo/golang-builder:latest是基于golang:latest這個image。 golang base image 有兩個模板：Dockerfile-debain.template和Dockerfile-alpine.template。而golang:latest是基于debian模板的，與ubuntu兼容。構建出來的myhttpserver對動態共享鏈接庫的情況如下：

# ldd myhttpserver 
    linux-vdso.so.1 =>  (0x00007ffd0c355000) 
    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007ffa8b36f000) 
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007ffa8afa5000) 
    /lib64/ld-linux-x86-64.so.2 (0x000055605ea5d000)

debian 系的linux distribution使用了glibc。但alpine則不同， alpine 使用的是 musl libc 的實現，因此當我們運行上面的那個容器時，加載器因找不到myhttpserver依賴的libc.so.6而失敗退出。

這種構建環境與運行環境不兼容的情況我這里稱之為“異構的鏡像構建”。那么如何解決這個問題呢?我們繼續看：

1、靜態構建

在主流編程語言中，Go的移植性已經是數一數二的了，尤其是Go 1.5之后，Go將runtime中的C代碼都用Go重寫了，對libc的依賴已經降到最低了，但仍有一些feature提供了兩個版本的實現：C實現和Go實現。并且默認情況下，即在CGO_ENABLED=1的情況下，程序和預編譯的標準庫都采用了C的實現。關于這方面的詳細論述請參見我之前寫的《也談Go的可移植性》一文，這里就不贅述了。于是采用了不同libc實現的debian系和alpine系自然存在不兼容的情況。要解決這個問題，我們首先考慮對Go程序進行靜態構建，然后將靜態構建后的Go應用放入alpine image中。

我們修改一下Dockerfile.build，在編譯Go源文件時加上CGO_ENABLED=0：

// github.com/bigwhite/experiments/multi_stage_image_build/heterogeneous/Dockerfile.build 
 
FROM golang:latest 
 
WORKDIR /go/src 
COPY httpserver.go . 
 
RUN CGO_ENABLED=0 go build -o myhttpserver ./httpserver.go

構建這個builder image：

# docker build -t myrepo/golang-static-builder:latest -f Dockerfile.build . 
Sending build context to Docker daemon  4.096kB 
Step 1/4 : FROM golang:latest 
 ---> 1a34fad76b34 
Step 2/4 : WORKDIR /go/src 
 ---> 593cd9692019 
Removing intermediate container ee005d487ad5 
Step 3/4 : COPY httpserver.go . 
 ---> a095eb69e716 
Step 4/4 : RUN CGO_ENABLED=0 go build -o myhttpserver ./httpserver.go 
 ---> Running in d9f3b3a6c36c 
 ---> c06fe8dccbad 
Removing intermediate container d9f3b3a6c36c 
Successfully built c06fe8dccbad 
Successfully tagged myrepo/golang-static-builder:latest 
 
# docker images 
REPOSITORY                     TAG                 IMAGE ID            CREATED             SIZE 
myrepo/golang-static-builder   latest              c06fe8dccbad        31 seconds ago      739MB

接下來，我們再基于golang-static-builder中已經build完畢的靜態連接的myhttpserver來構建我們最終的應用image：

# docker create --name appsource myrepo/golang-static-builder:latest 
# docker cp appsource:/go/src/myhttpserver ./ 
# ldd myhttpserver 
    not a dynamic executable 
# docker rm -f appsource 
# docker rmi myrepo/golang-static-builder:latest 
# docker build -t myrepo/myhttpserver-alpine:latest -f Dockerfile.alpine .

運行新image:

# docker run myrepo/myhttpserver-alpine:latest 
Webserver start 
  -> listen on port:1111

Note: 我們可以用strace來證明靜態連接時Go只使用的是Go自己的runtime實現，而并未使用到libc.a中的代碼：

# CGO_ENABLED=0 strace -f go build httpserver.go 2>&1 | grep open | grep -o '/.*\.a'  > go-static-build-strace-file-open.txt

打開 go-static-build-strace-file-open.txt 文件查看文件內容，你不會找到libc.a這個文件(在Ubuntu下，一般libc.a躺在/usr/lib/x86_64-linux-gnu/下面)，這說明go build根本沒有嘗試去open libc.a文件并獲取其中的符號定義。

2、使用alpine golang builder

我們的Go應用運行在alpine based的container中，我們可以使用alpine golang builder來構建我們的應用(無需靜態鏈接)。前面提到過golang有alpine模板：

REPOSITORY                   TAG                 IMAGE ID            CREATED             SIZE 
golang                       alpine              9e3f14138abd        7 days ago          269MB

alpine版golang builder的Dockerfile內容如下：

//github.com/bigwhite/experiments/multi_stage_image_build/heterogeneous/Dockerfile.alpine.build 
 
FROM golang:alpine 
 
WORKDIR /go/src 
COPY httpserver.go . 
 
RUN go build -o myhttpserver ./httpserver.go

后續的操作與前面golang builder的操作并不二致：利用alpine golang builder構建我們的應用，并將其打入alpine image，這里就不贅述了。

三、多階段鏡像構建：提升開發者體驗

在Docker 17.05以前，我們都是像上面那樣構建鏡像的。你會發現即便采用異構image builder模式，我們也要維護兩個Dockerfile，并且還要在docker build命令之外執行一些諸如從容器內copy應用程序、清理build container和build image等的操作。Docker社區看到了這個問題，于是實現了多階段鏡像構建機制 (multi-stage)。

我們先來看一下針對上面例子，multi-stage build所使用Dockerfile：

//github.com/bigwhite/experiments/multi_stage_image_build/multi_stages/Dockerfile  
FROM golang:alpine as builder  
WORKDIR /go/src 
COPY httpserver.go .  
RUN go build -o myhttpserver ./httpserver.go  
From alpine:latest  
WORKDIR /root/ 
COPY --from=builder /go/src/myhttpserver . 
RUN chmod +x /root/myhttpserver  
ENTRYPOINT ["/root/myhttpserver"]

看完這個Dockerfile的內容，你的第一趕腳是不是把之前的兩個Dockerfile合并在一塊兒了，每個Dockerfile單獨作為一個“階段”!事實也是這樣，但這個Docker也多了一些新的語法形式，用于建立各個“階段”之間的聯系。針對這樣一個Dockerfile，我們應該知道以下幾點：

支持Multi-stage build的Dockerfile在以往的多個build階段之間建立內在連接，讓后一個階段構建可以使用前一個階段構建的產物，形成一條構建階段的chain;
Multi-stages build的最終結果僅產生一個image，避免產生冗余的多個臨時images或臨時容器對象，這正是我們所需要的：我們只要結果。

我們來使用multi-stage來build一下上述例子：

# docker build -t myrepo/myhttserver-multi-stage:latest . 
Sending build context to Docker daemon  3.072kB 
Step 1/9 : FROM golang:alpine as builder 
 ---> 9e3f14138abd 
Step 2/9 : WORKDIR /go/src 
 ---> Using cache 
 ---> 7a99431d1be6 
Step 3/9 : COPY httpserver.go . 
 ---> 43a196658e09 
Step 4/9 : RUN go build -o myhttpserver ./httpserver.go 
 ---> Running in 9e7b46f68e88 
 ---> 90dc73912803 
Removing intermediate container 9e7b46f68e88 
Step 5/9 : FROM alpine:latest 
 ---> 053cde6e8953 
Step 6/9 : WORKDIR /root/ 
 ---> Using cache 
 ---> 30d95027ee6a 
Step 7/9 : COPY --from=builder /go/src/myhttpserver . 
 ---> f1620b64c1ba 
Step 8/9 : RUN chmod +x /root/myhttpserver 
 ---> Running in e62809993a22 
 ---> 6be6c28f5fd6 
Removing intermediate container e62809993a22 
Step 9/9 : ENTRYPOINT /root/myhttpserver 
 ---> Running in e4000d1dde3d 
 ---> 639cec396c96 
Removing intermediate container e4000d1dde3d 
Successfully built 639cec396c96 
Successfully tagged myrepo/myhttserver-multi-stage:latest 
 
# docker images 
REPOSITORY                       TAG                 IMAGE ID            CREATED             SIZE 
myrepo/myhttserver-multi-stage   latest              639cec396c96        About an hour ago   16.3MB

我們來Run一下這個image：

# docker run myrepo/myhttserver-multi-stage:latest 
Webserver start 
  -> listen on port:1111

四、小結

多階段鏡像構建可以讓開發者通過一個Dockerfile，一次性地、更容易地構建出size較小的image，體驗良好并且更容易接入CI/CD等自動化系統。不過當前多階段構建僅是在Docker 17.05及之后的版本中才能得到支持。如果想學習和實踐這方面功能，但又沒有環境，可以使用 play-with-docker 提供的實驗環境。

Play with Docker labs

責任編輯：未麗燕來源： Tony Bai

Docker 鏡像 Go