從Docker版本 17.05.0-ce 開始，就支持了一種新的構(gòu)建鏡像的方法，叫做：多階段構(gòu)建(Multi-stage builds)，旨在解決Docker構(gòu)建應(yīng)用容器中的一些痛點。在日常構(gòu)建容器的場景中，經(jīng)常會遇到在同一個容器中進行源碼的獲取，編譯和生成，最終才構(gòu)建為鏡像。這樣做的劣勢在于：

1. 不得不在容器中安裝構(gòu)建程序所必須的運行時環(huán)境
2. 不得不在同一個容器中，獲取程序的源碼和構(gòu)建所需的一些生態(tài)工具
3. 構(gòu)建出的鏡像甚至包含了程序源碼和一些不必要的文件，導(dǎo)致容器鏡像尺寸偏大

當然，還有一種稍微優(yōu)雅的方式，就是我們事先在外部將項目及其依賴庫編譯測試打包好后，再將其拷貝到構(gòu)建目錄中，這種雖然可以很好地規(guī)避第一種方式存在的風險點，但是也需要考慮不同鏡像運行時，對于程序運行兼容性所帶來的差異。

其實，這些痛點，Docker也想到了，官方提供了簡便的多階段構(gòu)建 (multi-stage build) 方案。所謂多階段構(gòu)建，也即將構(gòu)建過程分為多個階段，在同一個Dockerfile中，通過不同的階段來構(gòu)建和生成所需要的應(yīng)用文件，最終將這些應(yīng)用文件添加到一個release的鏡像中。這樣做能完全規(guī)避上面所遇到的一系列問題。實現(xiàn)多階段構(gòu)建，主要依賴于新提供的關(guān)鍵字：from 和 as 。

下面舉個栗子：

FROM muninn/glide:alpine AS build-envADD . /go/src/my-projWORKDIR /go/src/my-projRUN go get -vRUN go build -o /go/src/my-proj/my-serverFROM alpineRUN apk add -U tzdataRUN ln -sf /usr/share/zoneinfo/Asia/Shanghai /etc/localtimeCOPY --from=build-env /go/src/my-proj/my-server /my-serverEXPOSE 80CMD ["my-server"]

多階段構(gòu)建的Dockerfile看起來像是把兩個或者更多的Dockerfile合并在了一起，這也即多階段的意思。as 關(guān)鍵字用來為構(gòu)建階段賦予一個別名，這樣，在另外一個構(gòu)建階段中，可以通過 from 關(guān)鍵字來引用和使用對應(yīng)關(guān)鍵字階段的構(gòu)建輸出，并打包到容器中。

在多階段構(gòu)建完成之后，輸出的鏡像僅僅包含了最終輸出的my-server應(yīng)用，沒有其他的源碼文件和第三方源碼包，非常的干凈和簡潔。因為 build-env 階段只是一個構(gòu)建的中間過程而已。

甚至，我們還可以使用更多的構(gòu)建階段來構(gòu)建不同的應(yīng)用，最終將這些構(gòu)建產(chǎn)出的應(yīng)用，合并到一個最終需要發(fā)布的鏡像中。我們可以看一個更復(fù)雜一點的栗子：

from debian as build-essentialarg APT_MIRRORrun apt-get updaterun apt-get install -y make gccworkdir /srcfrom build-essential as foocopy src1 .run makefrom build-essential as barcopy src2 .run makefrom alpinecopy --from=foo bin1 .copy --from=bar bin2 .cmd ...

多階段構(gòu)建的好處不言而喻，既可以很方便地將多個彼此依賴的項目通過一個Dockerfile就可輕松構(gòu)建出期望的容器鏡像，并且不用擔心鏡像太大、源碼泄露等風險。不得不說，這是一個非常不錯的改進。

以上就是本文的全部內(nèi)容，希望對大家的學習有所幫助，也希望大家多多支持VEVB武林網(wǎng)。