高山docker镜像和busybox docker镜像有什么区别? [英] What is the difference between alpine docker image and busybox docker image?

问题描述

高山docker 图片和当我检查他们的停靠文件时，高山就是这样(适用于Alpine v3.12-3.12.7)

When I check their dockfiles, alpine is like this (for 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 am also curious that many docker images, (nodejs/nginx/php just name a few) provide images based on alpine but not on busybox. Why is that ? What is use case for busybox image then ? I need to emphasize that I am not looking for an answer about why A is better than B or vise versa or software recommendation.

我的阿尔卑斯码头工人遇到间歇性的 DNS查找失败，如此处 Alpine知道Kubernetes内部的DNS问题吗?说.这是我问问题的原因之一.

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? said. That is one of reasons I asked my question.

PS， https://musl.libc.org/说"musl是对在Linux系统调用API之上构建的C标准库"和提到的https://en.wikipedia.org/wiki/Alpine_Linux

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]高山Linux切换到musl，它与Linux部分兼容glibc.

It previously used uClibc as its C standard library instead of the traditional GNU C Library (glibc) most commonly used. Although it is more lightweight, it does have the significant drawback of being binary incompatible with glibc. Thus, all software must be compiled for use with uClibc to work properly. As of 9 April 2014,[16] Alpine Linux switched to musl, which is partially binary compatible with glibc.

推荐答案

这两者之间的主要区别在于， busybox 图像静态的较早版本将glibc链接到busybox(当前版本甚至由于在静态配置中也使用libnss而动态地将busybox链接到glibc)，而 alpine 图像动态地链接到musl libc.

The key difference between these is that older versions of the busybox image statically linked busybox against glibc (current versions dynamically link busybox against glibc due to use of libnss even in static configuration), whereas the alpine image dynamically links against musl libc.

进入用于在这些详细信息之间进行选择的权重因子将不在这里(软件推荐请求)，但有一些关键点:

Going into the weighting factors used to choose between these in detail would be off-topic here (software recommendation requests), but some key points:

将glibc与musl libc进行比较，有几个要点(尽管当然还有许多其他因素):

Comparing glibc against musl libc, a few salient points (though there are certainly many other factors as well):

• glibc专为提高性能和可移植性(通常会添加需要大量代码的特殊情况下的性能优化)而构建.
• musl libc是为提高正确性和大小而不是性能而构建的(拥有较小的代码大小并在较少的RAM中运行会更慢一些)；面对资源枯竭，拥有正确的错误报告(而不是立即退出)要更具侵略性.
• glibc的使用更加广泛，因此，针对其实现而表现出的错误往往会更快地被发现.通常，当一个人是第一个针对musl开发给定软件的人时，会遇到bug(通常是在该软件中，而不是在musl中)或维护者明确选择使用GNU扩展而不遵循libc标准的地方.
• glibc是根据LGPL条款获得许可的；只有GPL兼容条款下的软件才能与它静态链接；而musl受MIT许可，并且使用时受到的限制较少.

比较静态版本与动态版本的优点:

Comparing the advantages of a static build against a dynamic build:

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

• If your system image will only have a single binary executable (written in C or otherwise using a libc), a static build is always better, as it discards any parts of your libraries that aren't actually used by that one executable.
• If your system image is intended to have more binaries added that are written in C, using dynamic linking will keep the overall size down, since it allows those binaries to use the libc that's already there.
• If your system image is intended to have more binaries added in a language that doesn't use libc (this can be the case for Go and Rust, f/e), then you don't benefit from dynamic linking; you don't need the unused parts of libc there because you won't be using them anyhow.

老实说，这两个图像之间没有覆盖可能的整个矩阵空间.在某些情况下，它们都不是最佳选择.具有仅带有静态链接到musl libc的busybox的图像(如果您要添加的所有内容均使用非C语言)或具有带有动态链接到glibc(如果您要添加更多需要libc且与musl不兼容的二进制文件).

Honestly, these two images don't between themselves cover the whole matrix space of possibilities; there are situations where neither of them is optimal. There would be value to having an image with only busybox that statically links against musl libc (if everything you're going to add is in a non-C language), or an image with busybox that dynamically links against glibc (if you're going to add more binaries that need libc and aren't compatible with musl).

这篇关于高山docker镜像和busybox docker镜像有什么区别?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！