優化 Docker 鏡像大小常見方法
平時我們構建的 Docker 鏡像通常比較大，占用大量的磁盤空間，隨著容器的大規模部署，同樣也會浪費寶貴的帶寬資源。本文將介紹幾種常用的方法來優化 Docker 鏡像大小，這里我們使用 Docker Hub 官方上的 Redis 鏡像進行說明。
手動管理
我們能夠直接想到的方法就是直接修改官方的 Redis 鏡像 Dockerfile 文件，手動刪除容器運行后不需要的組件，然后重新構建一個新鏡像。這種方法理論上是可行的，但是容易出錯，而且效果也不是特別明顯。主要是不能和官方的鏡像實時同步。
多階段構建
Docker 在17.05 版本起提供了多階段構建的功能來解決這個問題，這種方法是通過丟棄中間層來實現的，并通過中間層來提供有關如何創建最終鏡像及其內容信息來完成的，只需要保留容器化應用所需的組件即可。在更上層的實現如下所示：
- 以一些鏡像作為構建的基礎
- 和平常一樣運行命令來構造你的應用
- 將所需的制品復制到另外一個單獨的鏡像
Distroless
在嚴重依賴容器化技術，尤其是 Docker 之后，谷歌早就意識到了使用臃腫鏡像的弊端。所以他們提供了自己的方法來解決這個問題，即 distroless 鏡像。與典型的Linux 基礎鏡像(綁定了很多軟件)不同，在 distroless 上對你的應用進行 docker化，最終的鏡像只包含應用及其運行時的依賴項，大多數 Linux 發行版中包含的標準軟件，如包管理器，甚至 shell 都被會被排除在外。同樣的，要使用 Google 的 distroless 鏡像，需要使用上面我們提到的多階段構建，如下所示：
- FROM redis:latest AS build
- ARG TIME_ZONE
- RUN mkdir -p /opt/etc && \
- cp -a --parents /lib/x86_64-linux-gnu/libm.so.* /opt && \
- cp -a --parents /lib/x86_64-linux-gnu/libdl.so.* /opt && \
- cp -a --parents /lib/x86_64-linux-gnu/libpthread.so.* /opt && \
- cp -a --parents /lib/x86_64-linux-gnu/libc.so.* /opt && \
- cp -a --parents /usr/local/bin/redis-server /opt && \
- cp -a --parents /usr/local/bin/redis-sentinel /opt && \
- cp /usr/share/zoneinfo/${TIME_ZONE:-UTC} /opt/etc/localtime
- FROM gcr.io/distroless/base
- COPY --from=build /opt /
- VOLUME /data
- WORKDIR /data
- ENTRYPOINT ["redis-server"]
使用redis:latest為基礎鏡像，然后保留需要的一些二進制文件(redis-server二進制文件以及所有的相關依賴)，然后使用 distroless 鏡像作為構建的最終鏡像的基礎，將opt目錄內容復制到該鏡像目錄中來。
然后我們只需要重新構建鏡像即可：
- $ docker build -t redis:distroless .$ docker imagesREPOSITORY TAG IMAGE ID CREATED SIZEredis distroless 7d50bd873bea 15 seconds ago 28.2MBredis latest 1319b1eaa0b7 3 days ago 104MB
我們可以看到鏡像由以前的 104MB 變成了 28.2MB，大大降低了鏡像的大小。
注意：在 Linux 下面我們可以使用 ldd 工具來查找指定的二進制文件所需要的依賴，比如 $ ldd $(which redis-server) 。
使用 distroless 鏡像來降低 Docker 鏡像的大小是一個非常有效的方法，但是這樣做也有一個明顯的缺點就是最終的鏡像中沒有 shell 程序了，使得調試 Docker 容器就非常非常困難，當然這樣也降低了應用被攻擊的危險，使其更加安全，如果我們將應用部署到 Kubernetes 集群的話，我們可以利用 kubectl-debug這樣的工具來輔助調試應用。
Alpine Linux
另外一種比較常見的方式是選擇在 Alpine Linux 基礎上構建應用鏡像，Alpine Linux 是一個特別適合創建最小化 Docker 鏡像的發行版。Apline Linux 使用較小的 musl C 庫代替 glibc，并將其靜態鏈接，這意味著針對 musl 編譯的程序將變成可重定位的 (relocatable)的二進制文件，從而無需包含共享對象，從而可以顯著降低鏡像的大小。
redis:alpine 鏡像大概為 30MB 左右，這樣做的缺點是，通常 musl 的性能不如 glibc。當然也有另外一個好處，那就是和上面的 distroless 相比，Alpine 是成熟的 Linux 發行版，提供基本的 shell 訪問，使得調試 Docker 容器應用更為方便。在 Docker Hub 上面也可以找到幾乎所有流行軟件的 Alpine 版本，比如 Redis、Nginx、MySQL 等等。
GNU Guix
最后，我們可以使用 GNU Guix，一個多功能的軟件包管理工具，其中就有一項可以創建 Docker 鏡像的功能。Guix 區分了包的運行時依賴與構建依賴，所以 Guix 構建的 Docker 鏡像將只包含明確指定的程序，加上他們的運行時依賴，就像 distroless 的方法一樣。但和 distroless 不同的時候，distroless 需要你自己去查程序的運行時依賴關系(當然也要寫 Dockerfile)，而 Guix 只需要運行一條命令即可：$ guix pack -f docker redis 。
通過上面的命令創建的 Redis 鏡像大小約為 70MB，和原本的鏡像相比有明顯的減少，雖然比 distroless 和 Alpine 方法創建的鏡像稍大，但使用 Guinx 確實提供了一些其他的優點。比如，如果你想讓你的最終鏡像也包含一個 shell，以便像 Alpine 那樣去調試，那么只需要在 Guxi 打包的時候指定上就可以了：$ guix pack -f docker redis bash ，如果你想包含其他軟件，也可以繼續在后面添加即可。
Guix 的功能特性意味著包的構建可以100%復用，所以我們可以在 CI/CD 流水線管道中加入 Guix 支持，這樣構建過程就非常順暢了。
有的人可能會覺得 Guix 聽起來很酷，但是并不想為了構建更小的 Docker 鏡像而去下載安裝另外一個工具，更何況 Guix 只在 Linux 下面工作，很多開發者還是 MacOS 用戶，去配置 Guix 也挺麻煩。其實這點并不用擔心，Guix 本身也有 Docker 鏡像在 Docker Hub 上，所以使用起來也并不會太復雜，只需要簡單的使用 $ docker run guix 命令即可。
除了 Guix 之外，值得一提的還有一個名為 Nix 的軟件包管理工具，對 Guix 所述的每一點都同樣有效并且適用于 Nix。
