高可用集信達簡訊平臺專案，Redis叢集實戰
兩個奇技淫巧，將 Docker 映象體積減小 99%
2020-03-25 00:22·架構師之路對於剛接觸容器的人來說，他們很容易被自己構建的 Docker 映象體積嚇到，我只需要一個幾 MB 的可執行檔案而已，為何映象的體積會達到 1 GB 以上？本文將會介紹幾個奇技淫巧來幫助你精簡映象，同時又不犧牲開發人員和運維人員的操作便利性。本系列文章將分為三個部分：
第一部分著重介紹多階段構建（multi-stage builds），因為這是映象精簡之路至關重要的一環。在這部分內容中，我會解釋靜態連結和動態連結的區別，它們對映象帶來的影響，以及如何避免那些不好的影響。中間會穿插一部分對 Alpine 映象的介紹。
第二部分將會針對不同的語言來選擇適當的精簡策略，其中主要討論 Go，同時也涉及到了 Java，Node，Python，Ruby 和 Rust。這一部分也會詳細介紹 Alpine 映象的避坑指南。什麼？你不知道 Alpine 映象有哪些坑？我來告訴你。
第三部分將會探討適用於大多數語言和框架的通用精簡策略，例如使用常見的基礎映象、提取可執行檔案和減小每一層的體積。同時還會介紹一些更加奇特或激進的工具，例如 Bazel，Distroless，DockerSlim 和 UPX，雖然這些工具在某些特定場景下能帶來奇效，但大多情況下會起到反作用。
本文介紹第一部分。
1. 萬惡之源
我敢打賭，每一個初次使用自己寫好的程式碼構建 Docker 映象的人都會被映象的體積嚇到，來看一個例子。
讓我們搬出那個屢試不爽的 hello world C 程式：
/* hello.c */
int main () {
puts("Hello, world!");
return 0;
}複製程式碼並通過下面的 Dockerfile 構建映象：
FROM gcc
COPY hello.c .
RUN gcc -o hello hello.c
CMD ["./hello"]複製程式碼然後你會發現構建成功的映象體積遠遠超過了 1 GB。。。因為該映象包含了整個 gcc 映象的內容。
如果使用 Ubuntu 映象，安裝 C 編譯器，最後編譯程式，你會得到一個大概 300 MB 大小的映象，比上面的映象小多了。但還是不夠小，因為編譯好的可執行檔案還不到 20 KB：
$ ls -l hello
-rwxr-xr-x 1 root root 16384 Nov 18 14:36 hello複製程式碼類似地，Go 語言版本的 hello world 會得到相同的結果：
package main
import "fmt"
func main () {
fmt.Println("Hello, world!")
}複製程式碼使用基礎映象 golang 構建的映象大小是 800 MB，而編譯後的可執行檔案只有 2 MB 大小：
$ ls -l hello
-rwxr-xr-x 1 root root 2008801 Jan 15 16:41 hello複製程式碼還是不太理想，有沒有辦法大幅度減少映象的體積呢？往下看。
為了更直觀地對比不同映象的大小，所有映象都使用相同的映象名，不同的標籤。例如：hello:gcc，hello:ubuntu，hello:thisweirdtrick 等等，這樣就可以直接使用命令 docker images hello 列出所有映象名為 hello 的映象，不會被其他映象所幹擾。
2. 多階段構建
要想大幅度減少映象的體積，多階段構建是必不可少的。多階段構建的想法很簡單：“我不想在最終的映象中包含一堆 C 或 Go 編譯器和整個編譯工具鏈，我只要一個編譯好的可執行檔案！”
多階段構建可以由多個 FROM 指令識別，每一個 FROM 語句表示一個新的構建階段，階段名稱可以用 AS 引數指定，例如：
FROM gcc AS mybuildstage
COPY hello.c .
RUN gcc -o hello hello.c
FROM ubuntu
COPY --from=mybuildstage hello .
CMD ["./hello"]複製程式碼本例使用基礎映象 gcc 來編譯程式 hello.c，然後啟動一個新的構建階段，它以 ubuntu 作為基礎映象，將可執行檔案 hello 從上一階段拷貝到最終的映象中。最終的映象大小是 64 MB，比之前的 1.1 GB 減少了 95%：
→ docker images minimage
REPOSITORY TAG ... SIZE
minimage hello-c.gcc ... 1.14GB
minimage hello-c.gcc.ubuntu ... 64.2MB複製程式碼還能不能繼續優化？當然能。在繼續優化之前，先提醒一下：
在宣告構建階段時，可以不必使用關鍵詞 AS，最終階段拷貝檔案時可以直接使用序號表示之前的構建階段（從零開始）。也就是說，下面兩行是等效的：
COPY --from=mybuildstage hello .
COPY --from=0 hello .複製程式碼如果 Dockerfile 內容不是很複雜，構建階段也不是很多，可以直接使用序號表示構建階段。一旦 Dockerfile 變複雜了，構建階段增多了，最好還是通過關鍵詞 AS 為每個階段命名，這樣也便於後期維護。
使用經典的基礎映象
我強烈建議在構建的第一階段使用經典的基礎映象，這裡經典的映象指的是 CentOS，Debian，Fedora 和 Ubuntu 之類的映象。你可能還聽說過 Alpine 映象，不要用它！至少暫時不要用，後面我會告訴你有哪些坑。
COPY --from 使用絕對路徑
從上一個構建階段拷貝檔案時，使用的路徑是相對於上一階段的根目錄的。如果你使用 golang 映象作為構建階段的基礎映象，就會遇到類似的問題。假設使用下面的 Dockerfile 來構建映象：
FROM golang
COPY hello.go .
RUN go build hello.go
FROM ubuntu
COPY --from=0 hello .
CMD ["./hello"]複製程式碼你會看到這樣的報錯：
COPY failed: stat /var/lib/docker/overlay2/1be...868/merged/hello: no such file or directory複製程式碼這是因為 COPY 命令想要拷貝的是 /hello，而 golang 映象的 WORKDIR 是 /go，所以可執行檔案的真正路徑是 /go/hello。
當然你可以使用絕對路徑來解決這個問題，但如果後面基礎映象改變了 WORKDIR 怎麼辦？你還得不斷地修改絕對路徑，所以這個方案還是不太優雅。最好的方法是在第一階段指定 WORKDIR，在第二階段使用絕對路徑拷貝檔案，這樣即使基礎映象修改了 WORKDIR，也不會影響到映象的構建。例如：
FROM golang
WORKDIR /src
COPY hello.go .
RUN go build hello.go
FROM ubuntu
COPY --from=0 /src/hello .
CMD ["./hello"]複製程式碼最後的效果還是很驚人的，將映象的體積直接從 800 MB 降低到了 66 MB：
→ docker images minimage
REPOSITORY TAG ... SIZE
minimage hello-go.golang ... 805MB
minimage hello-go.golang.ubuntu-workdir ... 66.2MB複製程式碼3. FROM scratch 的魔力
回到我們的 hello world，C 語言版本的程式大小為 16 kB，Go 語言版本的程式大小為 2 MB，那麼我們到底能不能將映象縮減到這麼小？能否構建一個只包含我需要的程式，沒有任何多餘檔案的映象？
答案是肯定的，你只需要將多階段構建的第二階段的基礎映象改為 scratch 就好了。scratch 是一個虛擬映象，不能被 pull，也不能執行，因為它表示空、nothing！這就意味著新映象的構建是從零開始，不存在其他的映象層。例如：
FROM golang
COPY hello.go .
RUN go build hello.go
FROM scratch
COPY --from=0 /go/hello .
CMD ["./hello"]複製程式碼這一次構建的映象大小正好就是 2 MB，堪稱完美！
然而，但是，使用 scratch 作為基礎映象時會帶來很多的不便，且聽我一一道來。
缺少 shell
scratch 映象的第一個不便是沒有 shell，這就意味著 CMD/RUN 語句中不能使用字串，例如：
...
FROM scratch
COPY --from=0 /go/hello .
CMD ./hello複製程式碼如果你使用構建好的映象建立並執行容器，就會遇到下面的報錯：
docker: Error response from daemon: OCI runtime create failed: container_linux.go:345: starting container process caused "exec: \"/bin/sh\": stat /bin/sh: no such file or directory": unknown.複製程式碼從報錯資訊可以看出，映象中並不包含 /bin/sh，所以無法執行程式。這是因為當你在 CMD/RUN 語句中使用字串作為引數時，這些引數會被放到 /bin/sh 中執行，也就是說，下面這兩條語句是等效的：
CMD ./hello
CMD /bin/sh -c "./hello"複製程式碼解決辦法其實也很簡單：使用 JSON 語法取代字串語法。例如，將 CMD ./hello 替換為 CMD ["./hello"]，這樣 Docker 就會直接執行程式，不會把它放到 shell 中執行。
缺少除錯工具
scratch 映象不包含任何除錯工具，ls、ps、ping 這些統統沒有，當然了，shell 也沒有（上文提過了），你無法使用 docker exec 進入容器，也無法檢視網路堆疊資訊等等。
如果想檢視容器中的檔案，可以使用 docker cp；如果想檢視或除錯網路堆疊，可以使用 docker run --net container:，或者使用 nsenter；為了更好地除錯容器，Kubernetes 也引入了一個新概念叫 Ephemeral Containers，但現在還是 Alpha 特性。
雖然有這麼多雜七雜八的方法可以幫助我們除錯容器，但它們會將事情變得更加複雜，我們追求的是簡單，越簡單越好。
折中一下可以選擇 busybox 或 alpine 映象來替代 scratch，雖然它們多了那麼幾 MB，但從整體來看，這只是犧牲了少量的空間來換取除錯的便利性，還是很值得的。
缺少 libc
這是最難解決的問題。使用 scratch 作為基礎映象時，Go 語言版本的 hello world 跑得很歡快，C 語言版本就不行了，或者換個更復雜的 Go 程式也是跑不起來的（例如用到了網路相關的工具包），你會遇到類似於下面的錯誤：
standard_init_linux.go:211: exec user process caused "no such file or directory"複製程式碼從報錯資訊可以看出缺少檔案，但沒有告訴我們到底缺少哪些檔案，其實這些檔案就是程式執行所必需的動態庫（dynamic library）。
那麼，什麼是動態庫？為什麼需要動態庫？
所謂動態庫、靜態庫，指的是程式編譯的連結階段，連結成可執行檔案的方式。靜態庫指的是在連結階段將彙編生成的目標檔案.o 與引用到的庫一起連結打包到可執行檔案中，因此對應的連結方式稱為靜態連結（static linking）。而動態庫在程式編譯時並不會被連線到目的碼中，而是在程式執行是才被載入，因此對應的連結方式稱為動態連結（dynamic linking）。
90 年代的程式大多使用的是靜態連結，因為當時的程式大多數都執行在軟盤或者盒式磁帶上，而且當時根本不存在標準庫。這樣程式在執行時與函式庫再無瓜葛，移植方便。但對於 Linux 這樣的分時系統，會在在同一塊硬碟上併發執行多個程式，這些程式基本上都會用到標準的 C 庫，這時使用動態連結的優點就體現出來了。使用動態連結時，可執行檔案不包含標準庫檔案，只包含到這些庫檔案的索引。例如，某程式依賴於庫檔案 libtrigonometry.so 中的 cos 和 sin 函式，該程式執行時就會根據索引找到並載入 libtrigonometry.so，然後程式就可以呼叫這個庫檔案中的函式。
使用動態連結的好處顯而易見：
- 節省磁碟空間，不同的程式可以共享常見的庫。
- 節省記憶體，共享的庫只需從磁碟中載入到記憶體一次，然後在不同的程式之間共享。
- 更便於維護，庫檔案更新後，不需要重新編譯使用該庫的所有程式。
嚴格來說，動態庫與共享庫（shared libraries）相結合才能達到節省記憶體的功效。Linux 中動態庫的副檔名是 .so（ shared object），而 Windows 中動態庫的副檔名是 .DLL（Dynamic-link library）。
回到最初的問題，預設情況下，C 程式使用的是動態連結，Go 程式也是。上面的 hello world 程式使用了標準庫檔案 libc.so.6，所以只有映象中包含該檔案，程式才能正常執行。使用 scratch 作為基礎映象肯定是不行的，使用 busybox 和 alpine 也不行，因為 busybox 不包含標準庫，而 alpine 使用的標準庫是 musl libc，與大家常用的標準庫 glibc 不相容，後續的文章會詳細解讀，這裡就不贅述了。
那麼該如何解決標準庫的問題呢？有三種方案。
1、使用靜態庫
我們可以讓編譯器使用靜態庫編譯程式，辦法有很多，如果使用 gcc 作為編譯器，只需加上一個引數 -static：
$ gcc -o hello hello.c -static複製程式碼編譯完的可執行檔案大小為 760 kB，相比於之前的 16kB 是大了好多，這是因為可執行檔案中包含了其執行所需要的庫檔案。編譯完的程式就可以跑在 scratch 映象中了。
如果使用 alpine 映象作為基礎映象來編譯，得到的可執行檔案會更小（< 100kB），下篇文章會詳述。
2、拷貝庫檔案到映象中
為了找出程式執行需要哪些庫檔案，可以使用 ldd 工具：
$ ldd hello
linux-vdso.so.1 (0x00007ffdf8acb000)
libc.so.6 => /usr/lib/libc.so.6 (0x00007ff897ef6000)
/lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x00007ff8980f7000)複製程式碼從輸出結果可知，該程式只需要 libc.so.6 這一個庫檔案。linux-vdso.so.1 與一種叫做 VDSO 的機制有關，用來加速某些系統呼叫，可有可無。ld-linux-x86-64.so.2 表示動態連結器本身，包含了所有依賴的庫檔案的資訊。
你可以選擇將 ldd 列出的所有庫檔案拷貝到映象中，但這會很難維護，特別是當程式有大量依賴庫時。對於 hello world 程式來說，拷貝庫檔案完全沒有問題，但對於更復雜的程式（例如使用到 DNS 的程式），就會遇到令人費解的問題：glibc（GNU C library）通過一種相當複雜的機制來實現 DNS，這種機制叫 NSS（Name Service Switch, 名稱服務開關）。它需要一個配置檔案 /etc/nsswitch.conf 和額外的函式庫，但使用 ldd 時不會顯示這些函式庫，因為這些庫在程式執行後才會載入。如果想讓 DNS 解析正確工作，必須要拷貝這些額外的庫檔案（/lib64/libnss_*）。
我個人不建議直接拷貝庫檔案，因為它非常難以維護，後期需要不斷地更改，而且還有很多未知的隱患。
3、使用 busybox:glibc 作為基礎映象
有一個映象可以完美解決所有的這些問題，那就是 busybox:glibc。它只有 5 MB 大小，並且包含了 glibc 和各種除錯工具。如果你想選擇一個合適的映象來執行使用動態連結的程式，busybox:glibc 是最好的選擇。
注意：如果你的程式使用到了除標準庫之外的庫，仍然需要將這些庫檔案拷貝到映象中。
4. 總結
最後來對比一下不同構建方法構建的映象大小：
- 原始的構建方法：1.14 GB
- 使用 ubuntu 映象的多階段構建：64.2 MB
- 使用 alpine 映象和靜態 glibc：6.5 MB
- 使用 alpine 映象和動態庫：5.6 MB
- 使用 scratch 映象和靜態 glibc：940 kB
- 使用 scratch 映象和靜態 musl libc：94 kB
最終我們將映象的體積減少了 99.99%。
但我不建議使用 sratch 作為基礎映象，因為除錯起來非常麻煩，但如果你喜歡，我也不會攔著你。
下篇文章將會著重介紹 Go 語言的映象精簡策略，其中會花很大的篇幅來討論 alpine 映象，因為它實在是太酷了，在使用它之前必須得摸清它的底細。
作者：米開朗基楊
連結：
https://juejin.im/post/5e79a207f265da574e22bee3
來源：掘金
著作權歸作者所有。商業轉載請聯絡作者獲得授權，非商業轉載請註明出處。