我從2017年做Vulhub開始，一直在和一個麻煩的問題做斗爭：在編寫Dockerfile的時候， 如何減小 docker build 生成的鏡像大小 ？這篇文章就給大家總結一下我自己使用過的六種減小鏡像大小的方法。
1. 使用Alpine Linux
Alpine Linux是一個基于BusyBox和Musl Libc的Linux發行版，其最大的優勢就是小。一個純的基礎Alpine Docker鏡像在壓縮后僅有2.67MB。
不少Docker官方鏡像都有Alpine版本，比如PHP：
比較之下就可以發現，alpine版本鏡像大小是普通版本的1/5左右。
但是在Docker Hub中，大部分鏡像是沒有Alpine版本的，比如Mysql和PHP-Apache，如果我們需要基于這些環境開發，就不得不自己編寫Alpine版本，或者找一些第三方鏡像。
另外，Alpine的另一個缺點是，其使用了Musl Libc作為傳統的glibc的替代，編譯軟件的時候可能會遇到一些不可預知的問題，這一點會導致我們耗費不少不必要的時間。
2. 只安裝最少的依賴
apt-get、yum、apk等軟件包管理器是我們編譯鏡像時必然需要用到的工具，純凈的Docker基礎鏡像通常會缺少wget、curl、git、gcc等工具，需要我們手工來安裝。
我們以apt為例，apt-get在安裝軟件的時候，可以指定一個選項： --no-install-recommends ，指定這個參數后，有一些非必須的依賴將不會被一起安裝。比如，我們安裝wget時，如果增加這個選項，待安裝的包將從6個減少為3個：
這在一定程度上縮小了鏡像的大小，但這樣做帶來的副作用就是，可能導致目標軟件缺少一些功能。
比如，此時的wget將無法驗證服務器證書的真偽，導致命令出錯：
所以，我們一般的做法是，使用apt時盡量增加 --no-install-recommends ，等后面出現一些錯誤再及時糾正。像wget這種已知的問題，可以提前預判并進行處理：
apt-get install --no-install-recommends wget ca-certificates
3. 為apt擦屁股
某些工具只有編譯階段使用，我不希望它們占用我寶貴的鏡像容量，就可以在鏡像編譯完成后，將這些中間依賴刪掉。
我們以apt為例，在使用完成后，我們需要做的事情有：
- 刪除那些 不需要 的依賴：
apt-get pruge --autoremove ...
- 刪除本地的軟件包列表：
rm -rf /var/lib/apt/lists/*
這個過程中我們會遇到一個非常難解的問題，究竟哪些依賴是“不需要”的？
比如，在編譯PHP時，我們可能會用到三個工具：wget、libxml、gcc。這三個工具，在編譯PHP前都需要安裝。但是在編譯完成后，我們可以卸載wget和gcc，但不能卸載libxml。
原因是，libxml為PHP所依賴的一個動態鏈接庫，如果我們將其卸載，將會出現找不到共享鏈接庫的錯誤：
root@8eab53da8d5b:/# php -v
php: error while loading shared libraries: libxml2.so.2: cannot open shared object file: No such file or directory
那么，有沒有一個比較方便的辦法，我自動只找出那些不是“共享鏈接庫”的依賴并刪除他們呢？
當然有，比較簡單的辦法是，我們遍歷剛編譯的可執行文件，使用ldd命令列出其依賴的共享鏈接庫文件名，并在源中搜索這個文件名對應的包名：
這些包就是PHP依賴的所有動態鏈接庫，接著我們將這些包用 apt-mark 聲明為“手工安裝的包”，即可阻止 apt purge 的自動卸載。
然后，我們再自動卸載其余沒有用到的包即可。完整shell腳本如下：
find /usr/local -type f -executable -exec ldd '{}' ';' \
| awk '/=>/ { print $(NF-1) }' \
| sort -u \
| xargs -r dpkg-query --search \
| cut -d: -f1 \
| sort -u \
| xargs -r apt-mark manual \
; \
apt-get purge -y --auto-remove -o APT::AutoRemove::RecommendsImportant=false;
4. 盡量將中間依賴的安裝與卸載操作放在一個步驟中
docker鏡像是一個由“層”來堆疊起來的“千層餅”，我們可以使用 docker history <image name> 這條命令來查看任意一個鏡像是由哪些層組成的，以及每一層的大小：
對于Dockerfile來說，這些層的數據都將會被保存在鏡像中，即使后一層刪除了前一層內保存的文件。
比如，我們有如下Dockerfile：
FROM alpine:3.12
RUN truncate -s 50M /sample.dat
RUN rm -rf /sample.dat
我們可以試試看這個鏡像編譯出來有多大，58MB：
相比起來，正常的alpine:3.12只有5.57MB，說明即使我們已經刪除了 /sample.dat 文件，在最后的鏡像中也沒有這個內容，但是它永遠留在了鏡像的history中。
所以，在刪除上文說到的“中間依賴”時，我們需要將安裝、使用、卸載三個部分寫在一個步驟中，才能保證空間被釋放。比如：
FROM debian:buster
RUN apt-get update \
&& apt-get install gcc \
&& gcc ... \
&& apt-get purge --autoremove gcc \
&& rm -rf /var/lib/apt/lists/*
5. 多階段編譯
在Docker 17.05版本以后，新引入了 multi-stage builds 這一概念，這將會極大地簡化我們上述的所有操作。
簡單來說，multi-stage builds支持我們將Docker鏡像的編譯分成多個“階段”。比如常見的軟件編譯的情況，我們可以將編譯階段單獨提出來，軟件編譯完成后直接將二進制文件拷貝到一個新的基礎鏡像中，這樣做最大的好處就是，第二個鏡像不再包含任何編譯階段使用的中間依賴，干干凈凈明明白白。
以最常見的Java項目為例，編譯Jar包的時候，我們需要使用到JDK、Maven等工具，但在實際運行階段，我們只需要JRE環境即可。簡單比較下 maven:3-openjdk-8 和 openjdk:8-jre 兩個鏡像的大小：
差別一倍有余。
以Vulhub中的Shiro 1.2.4環境為例，在其Dockerfile中可以看到兩個 FROM 命令：
FROM maven:3-jdk-8 AS builder
LABEL MAINTAINER="phithon <root@leavesongs.com>"
COPY ./code/ /usr/src/
WORKDIR /usr/src
RUN cd /usr/src; \
mvn -U clean package -Dmaven.test.skip=true
FROM openjdk:8u102-jre
LABEL MAINTAINER="phithon <root@leavesongs.com>"
COPY --from=builder /usr/src/target/shirodemo-1.0-SNAPSHOT.jar /shirodemo-1.0-SNAPSHOT.jar
EXPOSE 8080
CMD ["java", "-jar", "/shirodemo-1.0-SNAPSHOT.jar"]
第一個 FROM 用來進入 maven:3-jdk-8 環境，使用maven對源碼進行編譯；第二個 FROM 進入較小的 openjdk:8u102-jre 環境，使用 COPY --from= 語法，從前一個階段的編譯結果中將jar文件復制到jre的環境中。
最后，在機器上將會留下兩個鏡像，一個是builder，一個是最終我們需要的那個shiro 1.2.4的環境，后者可以被其他任何用戶獨立使用，而前者可以直接刪除。
對于使用者來說，我們無需再糾結編譯軟件時中間依賴如何刪除才能讓鏡像比較小的問題，反正第一階段使用的任何依賴多不會被遺留到正式的生產環境中。
但多階段編譯對于動態鏈接庫的依賴仍然有上述的問題，如果我們拷貝編譯成果時只拷貝了可執行文件，在新環境下運行仍然會出現找不到共享鏈接庫的錯誤。所以個人覺得，多段式編譯僅適合于Java、golang等能夠跨平臺或靜態編譯的語言，對于C、Python這些依賴較多的項目仍然不友好。
6. 使用slim版本的鏡像
細心的同學可能注意過，Docker官方的Debian鏡像有個slim版本，這個版本的大小比默認的版本要小一倍多：
slim的中文意思就是“苗條的”，顧名思義， debian:stretch-slim 確實苗條的多，原因是其刪除了man文檔等許多不會在容器里用到的文件。
有一些上層的鏡像會基于slim版本的debian進行編寫，比如python。如果我們開發python的項目，可以使用 python:slim 這個基礎鏡像。
總結一下，六種方法，互相不會影響，我們可以同時使用。但第5個，多階段編譯將會是以后的主流方式。
到此這篇關于詳解六種減小Docker鏡像大小的方法的文章就介紹到這了,更多相關減小Docker鏡像大小內容請搜索腳本之家以前的文章或繼續瀏覽下面的相關文章希望大家以后多多支持腳本之家！
