alpine 的争议

[plko345]

还在用 Alpine 作为你 Docker 的 Python 开发基础镜像？其实 Ubuntu 更好一点

这篇文章的观点认为 alpine 存在不少缺陷

[abowloflrf]

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

[Osk]

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


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

[Trim21]

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

[Trim21]

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

[Trim21]

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

[xiadong1994]

alpine 不是用来部署的吗……

[secondwtq]

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

[cheng6563]

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

[halfcrazy]

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

[jim9606]

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

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

[gimp]

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

[yzwduck]

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

[whileFalse]

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

[arischow]

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

[monsterxx03]

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

[find456789]

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

[blless]

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

[Jirajine]

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

[blless]

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

[dcalsky]

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