兩個奇技淫巧，將 Docker 鏡像體積減少 99%

時間 2020-03-25

標籤兩個 docker 鏡像體積減少 99% 欄目 Docker 简体版

原文原文鏈接

原文連接：Docker Images : Part I - Reducing Image Sizelinux

對於剛接觸容器的人來講，他們很容易被本身構建的 Docker 鏡像體積嚇到，我只須要一個幾 MB 的可執行文件而已，爲什麼鏡像的體積會達到 1 GB 以上？本文將會介紹幾個奇技淫巧來幫助你精簡鏡像，同時又不犧牲開發人員和運維人員的操做便利性。本系列文章將分爲三個部分：golang

第一部分着重介紹多階段構建（multi-stage builds），由於這是鏡像精簡之路相當重要的一環。在這部份內容中，我會解釋靜態連接和動態連接的區別，它們對鏡像帶來的影響，以及如何避免那些很差的影響。中間會穿插一部分對 Alpine 鏡像的介紹。docker

第二部分將會針對不一樣的語言來選擇適當的精簡策略，其中主要討論 Go，同時也涉及到了 Java，Node，Python，Ruby 和 Rust。這一部分也會詳細介紹 Alpine 鏡像的避坑指南。什麼？你不知道 Alpine 鏡像有哪些坑？我來告訴你。shell

第三部分將會探討適用於大多數語言和框架的通用精簡策略，例如使用常見的基礎鏡像、提取可執行文件和減少每一層的體積。同時還會介紹一些更加奇特或激進的工具，例如 Bazel，Distroless，DockerSlim 和 UPX，雖然這些工具在某些特定場景下能帶來奇效，但大多狀況下會起到副作用。ubuntu

本文介紹第一部分。bash

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 不兼容，後續的文章會詳細解讀，這裏就不贅述了。

那麼該如何解決標準庫的問題呢？有三種方案。

一、使用靜態庫

咱們可讓編譯器使用靜態庫編譯程序，辦法有不少，若是使用 gcc 做爲編譯器，只需加上一個參數 -static：

$ gcc -o hello hello.c -static複製代碼

編譯完的可執行文件大小爲 760 kB，相比於以前的 16kB 是大了好多，這是由於可執行文件中包含了其運行所須要的庫文件。編譯完的程序就能夠跑在 scratch 鏡像中了。

若是使用 alpine 鏡像做爲基礎鏡像來編譯，獲得的可執行文件會更小（< 100kB），下篇文章會詳述。

二、拷貝庫文件到鏡像中

爲了找出程序運行須要哪些庫文件，可使用 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_*）。

我我的不建議直接拷貝庫文件，由於它很是難以維護，後期須要不斷地更改，並且還有不少未知的隱患。