優化Docker鏡像大小常見方法有哪些

本篇內容主要講解“優化Docker鏡像大小常見方法有哪些”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓小編來帶大家學習“優化Docker鏡像大小常見方法有哪些”吧!

手動管理

我們能夠直接想到的方法就是直接修改官方的 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。

到此，相信大家對“優化Docker鏡像大小常見方法有哪些”有了更深的了解，不妨來實際操作一番吧！這里是億速云網站，更多相關內容可以進入相關頻道進行查詢，關注我們，繼續學習！