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

at0kjp5o  于 2023-03-17  发布在  Docker
关注(0)|答案(2)|浏览(174)

alpine docker映像与busybox docker映像有何区别?
当我检查他们的dockfile时,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 libcbusybox构建的。
那么到底有什么区别呢?
我也很好奇,许多docker图像,(nodejs/nginx/php仅举几个例子)提供基于alpine的图像,而不是基于busybox的图像。这是为什么?那么busybox图像的用例是什么?我需要强调的是,我并不是在寻找关于为什么A比B好或B比A好的答案或软件推荐。
我的alpine docker遇到了间歇性的DNS查找故障,就像musl-libc - Alpine's Greatest WeaknessDoes 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] Alpine Linux切换到与glibc部分二进制兼容的musl。

g6ll5ycj

g6ll5ycj1#

这两个版本的关键区别在于,旧版本的busybox映像 * 静态 * 链接busybox和glibc(当前版本动态链接busybox和glibc,因为即使在静态配置中也使用libnss),而alpine映像 * 动态 * 链接musl libc。
详细讨论用于在这些请求之间进行选择的加权因子可能与此处的主题无关(软件推荐请求),但有一些关键点:
比较glibc和musl libc,有几点值得注意(当然也有很多其他因素):

  • glibc是为在大小上提高性能和可移植性而构建的(通常添加占用大量代码的特殊情况性能优化)。
  • musl libc是为正确性和大小而构建的,而不是性能(它愿意稍微慢一点,以具有更小的代码大小并在更少的RAM中运行);而且在面对资源耗尽时,它更积极地报告正确的错误(而不是立即退出)。
  • glibc被广泛使用,所以它的实现中出现的bug会被更快地捕捉到.通常,当一个人是第一个用musl来构建一个给定的软件时,他会遇到bug(通常是在那个软件中,而不是在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不兼容)。

osh3o9ms

osh3o9ms2#

当我第一次问这个问题的时候,我并不确定busybox docker图像的使用情况,我关于busybox docker文件的链接也不完全正确。这是正确的docker文件链接,它解释了很多事情。所以busybox提供了3个不同的版本,构建在glibcmusluclibc

一个更恰当的问题是alpine image和busybox image在musl上的区别是什么?我仍然不知道答案,除了alpine image被更积极地维护。
Use Cases and Tips for Using the BusyBox Docker Official Image“于2022年7月14日发布(非常新),它说“维护BusyBox映像也一直是Docker的优先事项。
我仍然希望看到有人可以提供关于在glibc或uclibc上构建BusyBox映像的用例的答案
---更新---
正如这里讨论package manager for docker container running image busybox:uclibc“任何基于Busybox的东西都没有包管理器。它是一个带有一堆符号链接的二进制文件,向其中添加软件的方法是编写C代码并重新编译。”这里Package manager for Busybox也解释了,busybox没有包管理器,这可能是大多数人使用alpine的原因。
至于我随机遇到的DNS故障,我发现Why I Will Never Use Alpine Linux Ever Again解释得很好
musl(按设计)不支持DNS-over-TCP...最糟糕的是,当一些外部网络更改导致某些特定域的解析需要超过单个UDP数据包中可用的512字节时,这可能会随机出现。
最后,这个DNS问题并没有表现在Docker容器中。它只能发生在Kubernetes... Kubernetes文档声称DNS问题只与“Alpine 3. 3版或更早版本”相关,但我在Alpine 3. 16上遇到了上述问题,所以图。

相关问题