電子發(fā)燒友App
簡介：?本文主要講解針對不同的語言來選擇適當?shù)木啿呗?，其中主要討?Go，同時也涉及到了?Java，Node，Python，Ruby和?Rust。同時也會詳細介紹 Alpine 鏡像的避坑指南。
一、Go 語言鏡像精簡
?
Go?語言程序編譯時會將所有必須的依賴編譯到二進制文件中，但也不能完全肯定它使用的是靜態(tài)鏈接，因為?Go?的某些包是依賴系統(tǒng)標準庫的，例如使用到 DNS 解析的包。只要代碼中導(dǎo)入了這些包，編譯的二進制文件就需要調(diào)用到某些系統(tǒng)庫，為了這個需求，Go 實現(xiàn)了一種機制叫?cgo，以允許 Go 調(diào)用 C 代碼，這樣編譯好的二進制文件就可以調(diào)用系統(tǒng)庫。
也就是說，如果 Go 程序使用了?net?包，就會生成一個動態(tài)的二進制文件，如果想讓鏡像能夠正常工作，必須將需要的庫文件復(fù)制到鏡像中，或者直接使用?busybox:glibc?鏡像。
當然，你也可以禁止?cgo，這樣 Go 就不會使用系統(tǒng)庫，使用內(nèi)置的實現(xiàn)來替代系統(tǒng)庫（例如使用內(nèi)置的 DNS 解析器），這種情況下生成的二進制文件就是靜態(tài)的?？梢酝ㄟ^設(shè)置環(huán)境變量?CGO_ENABLED=0?來禁用 cgo，例如：
FROM golang
COPY whatsmyip.go .ENV CGO_ENABLED=0RUN go build whatsmyip.go
FROM scratch
COPY --from=0 /go/whatsmyip .CMD ["./whatsmyip"]
?
由于編譯生成的是靜態(tài)二進制文件，因此可以直接跑在?scratch?鏡像中 ?
當然，也可以不用完全禁用?cgo，可以通過?-tags?參數(shù)指定需要使用的內(nèi)建庫，例如?-tags netgo?就表示使用內(nèi)建的 net 包，不依賴系統(tǒng)庫：
$ go build -tags netgo whatsmyip.go
?
這樣指定之后，如果導(dǎo)入的其他包都沒有用到系統(tǒng)庫，那么編譯得到的就是靜態(tài)二進制文件。也就是說，只要還有一個包用到了系統(tǒng)庫，都會開啟?cgo，最后得到的就是動態(tài)二進制文件。要想一勞永逸，還是設(shè)置環(huán)境變量?CGO_ENABLED=0?吧。
二、Alpine 鏡像探秘
?
上篇文章已經(jīng)對?Alpine?鏡像作了簡要的介紹，并保證會在后面的文章中花很大的篇幅來討論?Alpine?鏡像，現(xiàn)在時候到了！
Alpine?是眾多 Linux 發(fā)行版中的一員，和?CentOS、Ubuntu、Archlinux?之類一樣，只是一個發(fā)行版的名字，號稱小巧安全，有自己的包管理工具?apk。
與 CentOS 和 Ubuntu 不同，Alpine 并沒有像?Red Hat?或?Canonical?之類的大公司為其提供維護支持，軟件包的數(shù)量也比這些發(fā)行版少很多（如果只看開箱即用的默認軟件倉庫，Alpine 只有?10000?個軟件包，而 Ubuntu、Debian 和 Fedora 的軟件包數(shù)量均大于?50000。）
容器崛起之前，Alpine?還是個無名之輩，可能是因為大家并不是很關(guān)心操作系統(tǒng)本身的大小，畢竟大家只關(guān)心業(yè)務(wù)數(shù)據(jù)和文檔，程序、庫文件和系統(tǒng)本身的大小通?？梢院雎圆挥?。
容器技術(shù)席卷整個軟件產(chǎn)業(yè)之后，大家都注意到了一個問題，那就是容器的鏡像太大了，浪費磁盤空間，拉取鏡像的時間也很長。于是，人們開始尋求適用于容器的更小的鏡像。對于那些耳熟能詳?shù)陌l(fā)行版（例如 Ubuntu、Debian、Fedora）來說，只能通過刪除某些工具（例如?ifconfig?和?netstat）將鏡像體積控制在?100M?以下。而對于 Alpine 而言，什么都不用刪除，鏡像大小也就只有?5M?而已。
Alpine 鏡像的另一個優(yōu)勢是包管理工具的執(zhí)行速度非常快，安裝軟件體驗非常順滑。誠然，在傳統(tǒng)的虛擬機上不需要太關(guān)心軟件包的安裝速度，同一個包只需要裝一次即可，無需不停重復(fù)安裝。容器就不一樣了，你可能會定期構(gòu)建新鏡像，也可能會在運行的容器中臨時安裝某些調(diào)試工具，如果軟件包的安裝速度很慢，會很快消磨掉我們的耐心。
為了更直觀，我們來做個簡單的對比測試，看看不同的發(fā)行版安裝?tcpdump?需要多長時間，測試命令如下：
? → time docker run install tcpdump
測試結(jié)果如下：
Base image Size Time to install tcpdump
---------------------------------------------------------
alpine:3.11 5.6 MB 1-2s
archlinux:20200106 409 MB 7-9s
centos:8 237 MB 5-6s
debian:10 114 MB 5-7s
fedora:31 194 MB 35-60s
ubuntu:18.04 64 MB 6-8s
?
如果你想了解更多關(guān)于 Alpine 的內(nèi)幕，可以看看?Natanel Copa 的演講。
好吧，既然 Alpine 這么棒，為什么不用它作為所有鏡像的基礎(chǔ)鏡像呢？別急，先一步一步來，為了趟平所有的坑，需要分兩種情況來考慮：
使用 Alpine 作為第二構(gòu)建階段（run?階段）的基礎(chǔ)鏡像
使用 ALpine 作為所有構(gòu)建階段（run?階段和?build?階段）的基礎(chǔ)鏡像
run 階段使用 Alpine
帶著激動的心情，將 Alpine 鏡像加入了 Dockerfile：
FROM gcc AS mybuildstage
COPY hello.c .RUN gcc -o hello hello.c
FROM alpine
COPY --from=mybuildstage hello .CMD ["./hello"]
第一個坑來了，啟動容器出現(xiàn)了錯誤：
standard_init_linux.go:211: exec user process caused "no such file or directory"
?
這個報錯在上篇文章已經(jīng)見識過了，上篇文章的場景是使用?scratch?鏡像作為?C?語言程序的基礎(chǔ)鏡像，錯誤的原因是?scratch?鏡像中缺少動態(tài)庫文件?？墒菫槭裁词褂?Alpine 鏡像也有報錯，難道它也缺少動態(tài)庫文件？
也不完全是，Alpine 使用的也是動態(tài)庫，畢竟它的設(shè)計目標之一就是占用更少的空間。但 Alpine 使用的標準庫與大多數(shù)發(fā)行版不同，它使用的是?musl libc，這個庫相比于?glibc?更小、更簡單、更安全，但是與大家常用的標準庫?glibc?并不兼容。
你可能又要問了：『既然?musl libc?更小、更簡單，還特么更安全，為啥其他發(fā)行版還在用?glibc？』
mmm。。。因為?glibc?有很多額外的擴展，并且很多程序都用到了這些擴展，而?musl libc?是不包含這些擴展的。詳情可以參考?musl 的文檔。
也就是說，如果想讓程序跑在 Alpine 鏡像中，必須在編譯時使用?musl libc?作為動態(tài)庫。
所有階段使用 Alpine
為了生成一個與?musl libc?鏈接的二進制文件，有兩條路：
某些官方鏡像提供了 Alpine 版本，可以直接拿來用。
還有些官方鏡像沒有提供 Alpine 版本，我們需要自己構(gòu)建。
?
golang 鏡像就屬于第一種情況，golang:alpine?提供了基于 Alpine 構(gòu)建的?Go?工具鏈。
構(gòu)建 Go 程序可以使用下面的?Dockerfile：
FROM golang:alpine
COPY hello.go .RUN go build hello.go
FROM alpine
COPY --from=0 /go/hello .CMD ["./hello"]
生成的鏡像大小為 7.5M，對于一個只打印 『hello world』的程序來說確實有點大了，但我們可以換個角度：
即使程序很復(fù)雜，生成的鏡像也不會很大。
包含了很多有用的調(diào)試工具。
即使運行時缺少某些特殊的調(diào)試工具，也可以迅速安裝。
Go 語言搞定了，C 語言呢？并沒有?gcc:alpine?這樣的鏡像啊。只能以 Alpine 鏡像作為基礎(chǔ)鏡像，自己安裝 C 編譯器了，Dockerfile 如下：
FROM alpine
RUN apk add build-baseCOPY hello.c .RUN gcc -o hello hello.c
FROM alpine
COPY --from=0 hello .CMD ["./hello"]
必須安裝?build-base，如果安裝?gcc，就只有編譯器，沒有標準庫。build-base 相當于 Ubuntu 的?build-essentials，引入了編譯器、標準庫和 make 之類的工具。
最后來對比一下不同構(gòu)建方法得到的 『hello world』鏡像大小：
使用基礎(chǔ)鏡像?golang?構(gòu)建：805MB
多階段構(gòu)建，build 階段使用基礎(chǔ)鏡像?golang，run 階段使用基礎(chǔ)鏡像?ubuntu：66.2MB
多階段構(gòu)建，build 階段使用基礎(chǔ)鏡像?golang:alpine，run 階段使用基礎(chǔ)鏡像?alpine：7.6MB
多階段構(gòu)建，build 階段使用基礎(chǔ)鏡像?golang，run 階段使用基礎(chǔ)鏡像?scratch：2MB
最終鏡像體積減少了?99.75%，相當驚人了。再來看一個更實際的例子，上一節(jié)提到的使用?net?的程序，最終的鏡像大小對比：
使用基礎(chǔ)鏡像?golang?構(gòu)建：810MB
多階段構(gòu)建，build 階段使用基礎(chǔ)鏡像?golang，run 階段使用基礎(chǔ)鏡像?ubuntu：71.2MB
多階段構(gòu)建，build 階段使用基礎(chǔ)鏡像?golang:alpine，run 階段使用基礎(chǔ)鏡像?alpine：12.6MB
多階段構(gòu)建，build 階段使用基礎(chǔ)鏡像?golang，run 階段使用基礎(chǔ)鏡像?busybox:glibc：12.2MB
多階段構(gòu)建，build 階段使用基礎(chǔ)鏡像?golang?并使用參數(shù) CGO_ENABLED=0，run 階段使用基礎(chǔ)鏡像?ubuntu：7MB
?
鏡像體積仍然減少了?99%。
三、Java 語言鏡像精簡
?
Java?屬于編譯型語言，但運行時還是要跑在?JVM?中。那么對于 Java 語言來說，該如何使用多階段構(gòu)建呢？
靜態(tài)還是動態(tài)？
?
從概念上來看，Java 使用的是動態(tài)鏈接，因為 Java 代碼需要調(diào)用?JVM?提供的?Java API，這些 API 的代碼都在可執(zhí)行文件之外，通常是?JAR?文件或?WAR?文件。
然而這些 Java 庫并不是完全獨立于系統(tǒng)庫的，某些 Java 函數(shù)最終還是會調(diào)用系統(tǒng)庫，例如打開文件時需要調(diào)用?open(),?fopen()?或它們的變體，因此?JVM?本身可能會與系統(tǒng)庫動態(tài)鏈接。
這就意味著理論上可以使用任意的?JVM?來運行 Java 程序，系統(tǒng)標準庫是?musl libc?還是?glibc?都無所謂。因此，也就可以使用任意帶有?JVM?的基礎(chǔ)鏡像來構(gòu)建 Java 程序，也可以使用任意帶有?JVM?的鏡像作為運行 Java 程序的基礎(chǔ)鏡像。
類文件格式
?
Java 類文件（Java 編譯器生成的字節(jié)碼）的格式會隨著版本而變化，且大部分變化都是?Java API?的變化。還有一部分更改與 Java 語言本身有關(guān)，例如?Java 5?中添加了泛型，這種變化就可能會導(dǎo)致類文件格式的變化，從而破壞與舊版本的兼容性。
所以默認情況下，使用給定版本的 Java 編譯器編譯的類不能與更早版本的 JVM 兼容，但可以指定編譯器的?-target?（Java 8 及其以下版本）參數(shù)或者?--release?（Java 9 及其以上版本）參數(shù)來使用較舊的類文件格式。--release?參數(shù)還可以指定類文件的路徑，以確保程序運行在指定的 JVM 版本中（例如 Java 11），不會意外調(diào)用 Java 12 的 API。
JDK vs JRE
?
如果你對大多數(shù)平臺上的 Java 打包方式很熟悉，那你應(yīng)該知道?JDK?和?JRE。
JRE?即 Java 運行時環(huán)境（Java Runtime Environment），包含了運行 Java 程序所需要的環(huán)境，即?JVM。
JDK?即 Java 開發(fā)工具包（Java Development Kit），既包含了 JRE，也包含了開發(fā) Java 程序所需的工具，即 Java 編譯器。
大多數(shù) Java 鏡像都提供了 JDK 和 JRE 兩種標簽，因此可以在多階段構(gòu)建的?build?階段使用?JDK?作為基礎(chǔ)鏡像，run?階段使用?JRE?作為基礎(chǔ)鏡像。
Java vs OpenJDK
?
推薦使用?openjdk，因為開源啊，更新勤快啊~~
也可以使用?amazoncorretto，這是?Amazon?fork OpenJDK 后打了補丁的版本，號稱企業(yè)級。
開始構(gòu)建
說了那么多，到底該用哪個鏡像呢？這里給出幾個參考：
openjdk:8-jre-alpine（85MB）
openjdk:11-jre（267MB）或者?openjdk:11-jre-slim（204MB）
openjdk:14-alpine（338MB）
如果你想要更直觀的數(shù)據(jù)，可以看我的例子，還是搬出屢試不爽的 『hello world』，只不過這次是 Java 版本：
class hello {
public static void main(String [] args) {
System.out.println("Hello, world!");
}
}
不同構(gòu)建方法得到的鏡像大小：
使用基礎(chǔ)鏡像?java?構(gòu)建：643MB
使用基礎(chǔ)鏡像?openjdk?構(gòu)建：490MB
多階段構(gòu)建，build 階段使用基礎(chǔ)鏡像?openjdk，run 階段使用基礎(chǔ)鏡像?openjdk:jre：479MB
使用基礎(chǔ)鏡像?amazoncorretto?構(gòu)建：390MB
多階段構(gòu)建，build 階段使用基礎(chǔ)鏡像?openjdk:11，run 階段使用基礎(chǔ)鏡像?openjdk:11-jre：267MB
多階段構(gòu)建，build 階段使用基礎(chǔ)鏡像?openjdk:8，run 階段使用基礎(chǔ)鏡像?openjdk:8-jre-alpine：85MB
?
所有的 Dockerfile 都可以在這個倉庫找到。
四、解釋型語言鏡像精簡
?
對于諸如?Node、Python、Rust?之類的解釋型語言來說，情況就比較復(fù)雜一點了。先來看看 Alpine 鏡像。
Alpine 鏡像
對于解釋型語言來說，如果程序僅用到了標準庫或者依賴項和程序本身使用的是同一種語言，且無需調(diào)用 C 庫和外部依賴，那么使用?Alpine?作為基礎(chǔ)鏡像一般是沒有啥問題的。一旦你的程序需要調(diào)用外部依賴，情況就復(fù)雜了，想繼續(xù)使用 Alpine 鏡像，就得安裝這些依賴。根據(jù)難度可以劃分為三個等級：
簡單：依賴庫有針對 Alpine 的安裝說明，一般會說明需要安裝哪些軟件包以及如何建立依賴關(guān)系。但這種情況非常罕見，原因前面也提到了，Alpine 的軟件包數(shù)量比大多數(shù)流行的發(fā)行版要少得多。
中等：依賴庫沒有針對 Alpine 的安裝說明，但有針對別的發(fā)行版的安裝說明。我們可以通過對比找到與別的發(fā)行版的軟件包相匹配的 Alpine 軟件包（假如有的話）。
困難：依賴庫沒有針對 Alpine 的安裝說明，但有針對別的發(fā)行版的安裝說明，但是 Alpine 也沒有與之對應(yīng)的軟件包。這種情況就必須從源碼開始構(gòu)建！
?
最后一種情況最不推薦使用 Alpine 作為基礎(chǔ)鏡像，不但不能減小體積，可能還會適得其反，因為你需要安裝編譯器、依賴庫、頭文件等等。。。更重要的是，構(gòu)建時間會很長，效率低下。如果非要考慮多階段構(gòu)建，就更復(fù)雜了，你得搞清楚如何將所有的依賴編譯成二進制文件，想想就頭大。因此一般不推薦在解釋型語言中使用多階段構(gòu)建。
有一種特殊情況會同時遇到 Alpine 的絕大多數(shù)問題：將 Python 用于數(shù)據(jù)科學(xué)。numpy?和?pandas?之類的包都被預(yù)編譯成了?wheel，wheel?是 Python 新的打包格式，被編譯成了二進制，用于替代 Python 傳統(tǒng)的?egg?文件，可以通過?pip?直接安裝。但這些 wheel 都綁定了特定的 C 庫，這就意味著在大多數(shù)使用?glibc?的鏡像中都可以正常安裝，但 Alpine 鏡像就不行，原因你懂得，前面已經(jīng)說過了。如果非要在 Alpine 中安裝，你需要安裝很多依賴，重頭構(gòu)建，耗時又費力，有一篇文章專門解釋了這個問題：使用 Alpine 構(gòu)建 Pyhton 鏡像會將構(gòu)建速度拖慢 50 倍！。
既然 Alpine 鏡像這么坑，那么是不是只要是 Python 寫的程序就不推薦使用 Alpine 鏡像來構(gòu)建呢？也不能完全這么肯定，至少 Python 用于數(shù)據(jù)科學(xué)時不推薦使用 Alpine，其他情況還是要具體情況具體分析，如果有可能，還是可以試一試 Alpine 的。
:slim 鏡像
?
如果實在不想折騰，可以選擇一個折衷的鏡像?xxx:slim。slim 鏡像一般都基于?Debian?和?glibc，刪除了許多非必需的軟件包，優(yōu)化了體積。如果構(gòu)建過程中需要編譯器，那么 slim 鏡像不適合，除此之外大多數(shù)情況下還是可以使用 slim 作為基礎(chǔ)鏡像的。
下面是主流的解釋型語言的 Alpine 鏡像和 slim 鏡像大小對比：
Image Size
---------------------------
node 939 MB
node:alpine 113 MB
node:slim 163 MB
python 932 MB
python:alpine 110 MB
python:slim 193 MB
ruby 842 MB
ruby:alpine 54 MB
ruby:slim 149 MB
再來舉個特殊情況的例子，同時安裝?matplotlib，numpy?和?pandas，不同的基礎(chǔ)鏡像構(gòu)建的鏡像大小如下：
Image and technique Size
--------------------------------------
python 1.26 GB
python:slim 407 MB
python:alpine 523 MB
python:alpine multi-stage 517 MB
?
可以看到這種情況下使用 Alpine 并沒有任何幫助，即使使用多階段構(gòu)建也無濟于事。
但也不能全盤否定 Alpine，比如下面這種情況：包含大量依賴的?Django?應(yīng)用。
Image and technique Size
--------------------------------------
python 1.23 GB
python:alpine 636 MB
python:alpine multi-stage 391 MB
?
最后來總結(jié)一下：到底使用哪個基礎(chǔ)鏡像并不能蓋棺定論，有時使用 Alpine 效果更好，有時反而使用 slim 效果更好，如果你對鏡像體積有著極致的追求，可以這兩種鏡像都嘗試一下。相信隨著時間的推移，我們就會積累足夠的經(jīng)驗，知道哪種情況該用 Alpine，哪種情況該用 slim，不用再一個一個嘗試。
五、Rust 語言鏡像精簡
?
Rust?是最初由?Mozilla?設(shè)計的現(xiàn)代編程語言，并且在?Web?和基礎(chǔ)架構(gòu)領(lǐng)域中越來越受歡迎。Rust 編譯的二進制文件動態(tài)鏈接到 C 庫，可以正常運行于?Ubuntu、Debian?和?Fedora?之類的鏡像中，但不能運行于?busybox:glibc?中。因為 Rust 二進制需要調(diào)用?libdl?庫，busybox:glibc?中不包含該庫。
還有一個?rust:alpine?鏡像，Rust 編譯的二進制也可以正常運行其中。
如果考慮編譯成靜態(tài)鏈接，可以參考?Rust 官方文檔。在 Linux 上需要構(gòu)建一個特殊版本的 Rust 編譯器，構(gòu)建的依賴庫就是?musl libc，你沒有看錯，就是 Alpine 中的那個?musl libc。如果你想獲得更小的鏡像，請按照文檔中的說明進行操作，最后將生成的二進制文件扔進?scratch?鏡像中就好了。
審核編輯：湯梓紅
?
工商網(wǎng)監(jiān)
評論