alpine docker 圖像和busybox docker 圖像有什么區別？

Question

alpine docker圖像和busybox docker圖像有什么區別？

當我檢查他們的dockfile時， alpine是這樣的（對於Alpine v3.12 - 3.12.7）

FROM scratch
ADD alpine-minirootfs-3.12.7-x86_64.tar.gz /
CMD ["/bin/sh"]

busybox 是這樣的

FROM scratch
ADD busybox.tar.xz /
CMD ["sh"]

但正如https://alpinelinux.org/about/所說

Alpine Linux 是圍繞musl libc和busybox構建的。

那么究竟有什么區別呢？

我也很好奇許多 docker 圖像（nodejs/nginx/php 僅舉幾例）提供基於 alpine 而不是基於busybox的圖像。 這是為什么？ 那么busybox圖像的用例是什么？ 我需要強調的是，我不是在尋找關於為什么 A 比 B 更好或反之亦然或軟件推薦的答案。

I have been experiencing intermittent DNS lookup failure for my alpine docker, as here musl-libc - Alpine's Greatest Weakness and here Does Alpine have known DNS issue within Kubernetes? 說。 這是我問我問題的原因之一。

PS, https://musl.libc.org/ says "musl is an implementation of the C standard library built on top of the Linux system call API" and https://en.wikipedia.org/wiki/Alpine_Linux mentioned

它以前使用 uClibc 作為其 C 標准庫，而不是最常用的傳統 GNU C 庫 (glibc)。 盡管它更輕量級，但它確實存在與 glibc 二進制不兼容的重大缺點。 因此，所有軟件都必須經過編譯才能與 uClibc 一起使用才能正常工作。 截至 2014 年 4 月 9 日，[16] Alpine Linux 切換到 musl，它與 glibc 部分二進制兼容。

Answer 1

它們之間的主要區別在於舊版本的busybox映像靜態鏈接busybox與glibc（當前版本動態鏈接busybox與glibc，因為即使在static配置中使用libnss），而alpine映像動態鏈接到musl libc。

在這里詳細討論用於在這些之間進行選擇的權重因素將是題外話（軟件推薦請求），但有一些關鍵點：

比較 glibc 和 musl libc，有幾個要點（當然還有很多其他因素）：

• glibc 是為性能和可移植性而構建的（通常添加需要大量代碼的特殊情況性能優化）。
• musl libc 是為正確性和大小而不是性能而構建的（它願意稍微慢一點，以擁有更小的代碼大小並在更少的 RAM 中運行）； 面對資源耗盡時，它更積極地報告正確的錯誤（而不是立即退出）。
• glibc 被更廣泛地使用，因此與其實現相悖的錯誤往往會被更快地發現。 通常，當一個人是第一個針對 musl 構建給定軟件的人時，會遇到錯誤（通常在該軟件中，而不是在 musl 中）或維護者明確選擇使用 GNU 擴展而不是堅持 libc 標准的地方.
• glibc 根據 LGPL 條款獲得許可； 只有符合 GPL 條款的軟件才能與其靜態鏈接； 而 musl 是在 MIT 許可下，並且可以在較少的限制下使用。

比較 static 構建與動態構建的優勢：

• 如果您的系統映像只有一個二進制可執行文件（以 C 或其他方式使用 libc 編寫），則 static 構建總是更好，因為它會丟棄該可執行文件實際未使用的庫的任何部分。
• 如果您的系統映像打算添加更多以 C 編寫的二進制文件，則使用動態鏈接將減小整體大小，因為它允許這些二進制文件使用已經存在的 libc。
• 如果您的系統映像打算在不使用 libc 的語言中添加更多二進制文件（Go 和 Rust，f/e 就是這種情況），那么您不會從動態鏈接中受益； 您不需要那里未使用的 libc 部分，因為無論如何您都不會使用它們。

---

老實說，這兩個圖像之間並沒有覆蓋整個可能性矩陣空間。 在某些情況下，它們都不是最優的。 有一個只有busybox靜態鏈接到musl libc 的圖像（如果你要添加的所有內容都是非C 語言），或者一個busybox動態鏈接到glibc 的圖像（如果你是將添加更多需要 libc 且與 musl 不兼容的二進制文件）。

Answer 2

當我第一次問這個問題時，我不確定busybox docker 圖像的用例以及關於busybox dockerfile 的鏈接並不完全正確。 這是正確的 dockerfile 鏈接，它解釋了很多事情。 所以busybox提供了3個不同的版本，建立在glibc 、 musl 、 uclibc

一個更合適的問題是基於musl的 alpine image 和 busybox image build 之間有什么區別？ 我仍然不知道答案，除了更積極地維護 alphine 圖像。

“ 使用 BusyBox Docker 官方圖像的用例和提示”於 2022 年 7 月 14 日發布（非常新），它說“維護 BusyBox 圖像也一直是 Docker 的首要任務。 ”

我仍然希望看到有人可以提供有關在 glibc 或 uclibc 上構建 BusyBox 圖像的用例的答案