alpine docker image 和 busybox docker image 有什么区别？

Question

alpine docker 图像和busybox docker 图像有什么区别？

当我检查他们的停靠文件时，alpine is like this（适用于 Alpine v3.12 - 3.12.7）

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

busybox is like this

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 更好或反之亦然或软件推荐的答案。

我的 alpine docker 遇到了间歇性 DNS 查找失败，就像这里的 musl-libc - Alpine's Greatest Weakness 和这里的 Does Alpine have known DNS issue within Kubernetes? 所说的那样。这是我提出问题的原因之一。

PS，https://musl.libc.org/ 说“musl 是基于 Linux 系统调用 API 构建的 C 标准库的实现”，https://en.wikipedia.org/wiki/Alpine_Linux 也提到了

它以前使用 uClibc 作为其 C 标准库，而不是 最常用的传统 GNU C 库 (glibc)。虽然它是 更轻巧，它确实有一个显着的缺点是 二进制与 glibc 不兼容。因此，必须编译所有软件 与 uClibc 一起使用才能正常工作。截至 2014 年 4 月 9 日，[16] 阿尔派 Linux 切换到 musl，它部分二进制兼容 glibc。

Answer 1

它们之间的主要区别在于，旧版本的busybox 图像静态将busybox 与glibc 链接（当前版本动态链接busybox 与glibc，因为即使在静态配置中也使用libnss），而alpine 图像动态链接到 musl libc。

在这里详细讨论用于在这些之间进行选择的权重因素将是题外话（软件推荐请求），但有一些关键点：

比较 glibc 和 musl libc，有几个要点（当然还有很多其他因素）：

• glibc 专为提高性能和可移植性而设计（通常会添加需要大量代码的特殊情况下的性能优化）。
• musl libc 是为正确性和大小而不是性能而构建的（它愿意稍微慢一些，以拥有更小的代码大小并在更少的 RAM 中运行）；面对资源耗尽时，它更积极地提供正确的错误报告（而不是立即退出）。
• glibc 的使用范围更广，因此对其实现表现出的错误往往会被更快地发现。通常，当一个人是第一个针对 musl 构建给定软件的人时，会遇到错误（通常在该软件中，而不是在 musl 中）或维护者明确选择使用 GNU 扩展而不是坚持 libc 标准的地方.
• glibc 根据 LGPL 条款获得许可；只有符合 GPL 条款的软件才能与其静态链接；而 musl 是在 MIT 许可下，并且可以在较少的限制下使用。

比较静态构建与动态构建的优势：

• 如果您的系统映像只有一个二进制可执行文件（用 C 编写或使用 libc 编写），则静态构建总是更好，因为它会丢弃该可执行文件实际未使用的库中的任何部分.
• 如果您的系统映像打算添加更多用 C 编写的二进制文件，则使用动态链接将减小整体大小，因为它允许这些二进制文件使用已经存在的 libc。
• 如果您的系统映像打算在不使用 libc 的语言中添加更多二进制文件（Go 和 Rust 可能就是这种情况，f/e），那么您不要' t 受益于动态链接；您不需要那里未使用的 libc 部分，因为无论如何您都不会使用它们。

---

老实说，这两个图像之间并没有覆盖整个可能性矩阵空间；在某些情况下，它们都不是最优的。有一个只有busybox的图像是有价值的，它静态链接到musl libc（如果你要添加的所有东西都是非C语言），或者一个带有busybox的图像动态地链接到 glibc（如果您要添加更多需要 libc 且与 musl 不兼容的二进制文件）。