Docker 容器镜像 alpine VS Ubuntu 的竞争

[programV2]

<div class="markdown_body">
最下面的链接 是三年前 reddit 论坛有讨论将 alpine 作为基础镜像, 如今已经实现被推荐作为 Docker 官方基础镜像。。想请教各位：
1 、回帖中提到的那些 alpine 的缺陷是否已解决？ 比如它的 musl libc 是不是还会有很多坑?
2 、现在 alpine 还有哪些库没有，但是也没办法自己手动编译安装的?
3,你们在构建 docker 基础镜像的话会如何选择?


https://www.reddit.com/r/docker/comments/b6gk1x/why_use_ubuntu_as_base_image_when_alpine_exists/

谢谢🙏
</div>

我发了这个帖子 /t/815453 之后就被限制登录，然后隔了快半个月重新更换的密码才能登的上，然后发现自己 at 别人, 别人都没有提示。这是被降权了吧？ 哪位还没被降权的好心人能帮我 at 一下 @ livid 帮我翻案⋯⋯谢谢🙏

[programV2]

谢谢

[Tink]

这几天正好在用 mqtt ，所以需要在 docker 里构建 mosquito ，alpine 和 ubuntu 都试了，alpine 很奇怪的是，verbose 模式下拿不到任何 log ，也不知道是我没搞对还是咋回事，就很难受

[LokiSharp]

用 Debian 还挺好的

[cokyhe]

项目能用 alpine 就用 alpine ，不行就改 ubuntu ，不和自己过不去

[programV2]

@cokyhe 大佬 请问你优先用 alpine 如何避开 musl 的问题?

[liuxu]

1. 一把年纪了，是该自己学会 google 了
2. 都能编译
3. 常用 alpine ，目前制作 docker image 最小方案有 2 种，一种是在 gentoo 下用 kubler 这类交叉编译工具制作目标系统 tar 包然后生成 docker image ；还有一种方式就是通过 alpine ，我实际测试来看 alpine 有时候比 gentoo 下自己制作的包还要小，而且编译时间 10 倍缩减


@Tink 日常通用方式是 ln -sf /proc/$$/fd/1 verbose.log ，然后进程输入日志到这个文件，还有问题的话看看配置是不是弄错了

[billzhuang]

我最近钟意 google 的 distroless

[bao3]

无论用哪个系统做底包，它们都是工具，哪个顺手你就用哪个。因噎废食就搞反了

[afirefish]

debian 11 ，虽然没有 alpine ，但是包比较全，没有太多坑。

[SmiteChow]

当然是 Ubuntu ，你就缺那点空间还是网速？

[hwdef]

能用 alpine 的就用 alpine ，如果用到了 musl ，就换 ubuntu.

[programV2]

@hwdef 关键是你不知道用到的哪个依赖包可能有用到 MUSL ? 想要排错都很困难。

[programV2]

@liuxu 谢谢大佬回复。 请问
1 ，你在实际使用中没有碰到 musl 带来的问题吗？
2 ，Ubuntu 的库是不是比 alpine 要全一些?

[joesonw]

https://github.com/GoogleContainerTools/distroless google 推荐的基础镜像

[liuxu]

@programV2

1. 没有
2. alpine 和其他系统最大的不同是系统命令用的 busybox ，没有杂七杂八的 lib, include ，很干净

[liuxu]

@programV2 还有一点，默认官方库只有 main ，其实还可以添加 testing ，根据我使用 swoole 来看，实际上 testing 只是帮你手动编译了而已

[programV2]

@joesonw 这个很少看到有人用啊。请问你使用过体验怎么样？

[programV2]

@liuxu 谢谢大佬。我贴一段论坛很多人提到的问题，想听听您的看法。： "Musl has different malloc, different libm, different pthreads. These things all will impact performance in some way (maybe better, maybe worse), and will hit implementation bugs in libraries at some point because someone coded too specifically against glibc. This + development time tradeoff risk doesn’t seem worthwhile, especially in data science where many libraries are needed and the library quality varies so wildly and often aren’t even portable beyond one specific version of one specific Linux distribution"
@liuxu
@liuxu

[liuxu]

@programV2

首先要说一下你的账号被降权了，你 at 人实际上别人是没有提醒的，我是重新点回了这个帖子看到你 at 我的楼层才回复你的

musl 可能是有兼容问题，但是你确定你会遇到么，实际上就算你用 glibc ，也是有 bug 的，但你遇到过么。
目前从 docker hub 看，基本上所有常用的服务类基础软件都会有基于 alpine 的镜像，nginx,php,mysql,redis ，既然都在基于 alpine 做镜像，你在担心什么

[jellyspot]

alpine 就一个 dns 问题，好多新手都能整蒙，因为大家用的其他系统，都是 glibc 的，但是 alpine 是 musl

[programV2]

@jellyspot 请问 DNS 是什么问题？只知道 glibc 与 musl 差异挺大的
@jellyspot

[12101111]

musl 没有 nss, 直接用 resolve.conf 配置 DNS

如果想用 musl, 那么不要妄想 cp 一个 glibc 的 elf 文件就能跑, 不可能的, alpine 软件仓库没有的 C/C++库要自己编译.

我的桌面系统用的是 Gentoo musl, 没见过哪个 C/C++包是彻底编译不了的, 改一改都能编译

[pckillers]

为啥我用的公用镜像不是 alpine 就是 Debian 。 从没见过用 Ubuntu 的啊？

[krcalc]

还有 distroless

[corvofeng]

个人意见, 我有两个选择点:

1. 旧项目保持原状,
2. 针对新项目, 编译型语言 Golang 就用 alpine, 镜像体积能保持很小, 真的清爽(K8s 好多镜像都直接用 scratch, 但是调试时麻烦, 这种库是给很多人用的, 所以会考虑压缩体积). 要是像 Python 这种用 debian 就行了, 反正要安装很多包, 有的还要 gcc 编译, 镜像的体积根本小不了

平时工作不用 C++/Java, 要是给我的话, 估计它两都是分步构建+debian 做基础镜像. 既然使用了分步构建, 每个镜像差别不会很大, 真正 pull 的层也不多. 另外的话从开发者心理上讲 debian 稳一点, 更接近普通 Linux 环境.

[hutoer]

使用 docker 好多年了，从最初的 CentOS 、Fedora 到 alpine 再到 debian ，综合（体积、第三库、折腾情况）来说 debian 最好

[nanmu42]

如果是 Go 项目，没有 cgo 的情况下甚至可以二段 build ，第二段用 from scratch ，不用底包。
例子：

https://gist.github.com/nanmu42/90bf2d3870b64aec20b68ec3c104a610

[chenzheyu]

alpine 挺精简的，业务也没有遇到问题，就是编译 grpc 的时候会有 linux header 的缺失。不过无伤大雅。体积是真的小啊！

[programV2]

@hutoer
@corvofeng 谢谢🙏。请问如果说用 Debian 做基础镜像 是因为他的库比较全，那用 Ubuntu 库 应该是最全的吧?

[programV2]

我发了这个帖子 https://www.v2ex.com/t/815453 之后就被限制登录，然后隔了快半个月重新更换的密码才能登的上，然后发现自己 at 别人, 别人都没有提示。这是被降权了吧？ 哪位还没被降权的好心人能帮我 at 一下 @ livid 帮我翻案⋯⋯谢谢🙏
@liuxu

[corvofeng]

@programV2 Debian 是很多库官方提供的镜像，比如 Python ，Ubuntu 作为官方镜像比较少

[programV2]

https://bean.m.jd.com/bean/signIndex.action