alpine 的争议

Python 在安装依赖的时候经常会对各种库有要求，甚至有的还会需要有 gcc，所以 Python 的基础镜像不用 alpine 没问题。但是对 Go 来说，CGO 关掉多步构建把最终的二进制放到一个 alpine 里还是很方便的。

好像万年前就提到过 c 库不一样导致的各种问题，所以选择用 alpine 之前必须考虑好会不会有坑。


我用 alpine 跑一个 go 程序，基本不受 c 库的影响，不会选择 ubuntu 等发行版，因为我在垃圾硬件上跑虚拟化（不是容器），alpine 是很棒的选择。
不说别的，印象中 alpine 使用 busybox 作 init system，比其它用 systemd 的那一大坨舒心多了。

其实 FROM python:3.7-slim 也算是 Debian

@Trim21 其实 FROM python:3.7-slim 用的是 Debian…

之前还见到有人格式化时间的时候因为 musl 跟 glibc 实现不一样而格式化结果不一样…

alpine 不是用来部署的吗……

musl 有推广开的必要，不然就相当于很多程序依赖 glibc 的特定实现。
当然自己用不用是另一个问题。

实际上经常要进容器用 curl 或 telnet 什么的检查服务状态，alpine 还是太不好用了

DNS a/aaaa 查询容易出现问题

这篇文章有一个问题，通常情况下为了缩小最终镜像体积，会使用多阶段构建，临时容器中编译二进制库后复制进最终运行镜像中，可以除去占用大量空间的编译依赖、源码、中间产物。

alpine 更多的问题还是在 musl 上，要是用到了针对 glibc 编译的闭源库就没法用，以及 c 库的一些行为差异。

基于 Ubuntu 更好一点儿，没必要非要追求镜像特别小的体积，另外 Python 本身就是用到什么包安什么，用 Ubuntu 省心很多。

这篇文章还有一个问题，明明 AlpineLinux 官方 Community 仓库里提供了 py3-matplotlib 和 py3-pandas 之类常见的软件包，却偏偏还要用 pip 源代码编译。

哈，我倒是遇到过一个事儿，alpine 中的某个 linux 命令的实现和标准行为不一致，导致特定情况下出问题。

我觉得要我另外去了解 Alpine 很麻烦。而且用了 multi-stage build 的话，上一阶段用的 debian buster 构造出来的 pip wheels 不可能让 alpine 使用到

依赖复杂点的项目基于 ubuntu slim 和 alpine 构建，最后你会发现大小没差多少

多阶段构建 了解一下？， 用 ubuntu 构建， 用 alpine 部署

用 Go 编译基本没问题，但是遇到问题想进容器安装一些常用工具的时候 反而麻烦了。想了想反正也不缺那么点空间，后面都用 debian 做基础镜像了

@blless 反了吧，一般发行版的基础镜像啥工具都没有，临时测试 ping 之类的都得现装，而 alpine 是 busybox 的，常用工具基本上都不缺。

@Jirajine 就是想装一些扩展工具啊，比如查看网络状态之类的工具，流量路由啥的 都是临时调试根据需要来的，正常没问题谁会想进容器敲命令啊。就算装正常的工具或者库，apline 要把 musl 相关库装完也没那么小了。

确实用 alpine+python 不见得体积会变比 slim 版本的小，毕竟还要各种 apk add

@blless 我到不是说大小，而是临时进容器里面的 shell 调试的时候 alpine 体验明显要比其他发行版好，busybox 自带的工具比其他发行版多，额外安装其他工具 apk 的速度也比 apt 快。

用好镜像分层的特性, 镜像的大小不是什么大问题; 但如果用高度精简的基础镜像, 在排查问题时会因为缺这缺那非常痛苦

性能上来说，至少在 musl 自己的 benchmark 里性能在某些方面还是领先于 glibc 的： https://www.etalabs.net/compare_libcs.html，所以真要拿性能说事，你只有拿你自己最终的程序实际去测，看网上的文章是没用的。
其他方面，如果你对你程序的依赖掌控的比较清楚，用 Alpine 还是没啥问题的，毕竟谁不喜欢更小的镜像呢

@yzwduck 那个啥，我看你是没见过（比如，真实情况的小版本号忘记了） pandas 0.19.2 不能用 0.19.3 能用的那种代码。。。 从源里面装你根本无法精确控制版本号啊

看到回复这么少我就放心了，建议用更具争议的话题，这样流量更大些。