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

Question

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

当我检查他们的码头文件时，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 更好或反之亦然的答案或软件推荐。

我的 alpine docker遇到间歇性DNS 查找失败的情况，如此处musl-libc - Alpine 的最大弱点和此处Alpine 是否在 Kubernetes 中存在已知的 DNS 问题？说。这是我提出问题的原因之一。

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] Alpine 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 可能属于这种情况），那么您不会从动态链接中受益；你不需要 libc 中未使用的部分，因为无论如何你都不会使用它们。

老实说，这两个图像本身并没有覆盖整个可能性矩阵空间；在某些情况下，它们都不是最佳的。拥有一个仅包含 busybox静态链接到 musl libc 的映像（如果您要添加的所有内容都是非 C 语言），或者一个包含 busybox动态链接到 glibc 的映像（如果您是将添加更多需要 libc 并且与 musl 不兼容的二进制文件）。