还在用 Alpine 作为你 Docker 的 Python 开发基础镜像?其实 Ubuntu 更好一点
这篇文章的观点认为 alpine 存在不少缺陷
1
abowloflrf 2020-09-06 01:25:39 +08:00
Python 在安装依赖的时候经常会对各种库有要求,甚至有的还会需要有 gcc,所以 Python 的基础镜像不用 alpine 没问题。但是对 Go 来说,CGO 关掉多步构建把最终的二进制放到一个 alpine 里还是很方便的。
|
2
Osk 2020-09-06 01:32:52 +08:00
好像万年前就提到过 c 库不一样导致的各种问题,所以选择用 alpine 之前必须考虑好会不会有坑。
我用 alpine 跑一个 go 程序,基本不受 c 库的影响,不会选择 ubuntu 等发行版,因为我在垃圾硬件上跑虚拟化(不是容器),alpine 是很棒的选择。 不说别的,印象中 alpine 使用 busybox 作 init system,比其它用 systemd 的那一大坨舒心多了。 |
3
Trim21 2020-09-06 01:41:35 +08:00 via Android
其实 FROM python:3.7-slim 也算是 Debian
|
5
Trim21 2020-09-06 01:43:55 +08:00 via Android
之前还见到有人格式化时间的时候因为 musl 跟 glibc 实现不一样而格式化结果不一样…
|
6
xiadong1994 2020-09-06 01:46:45 +08:00 via iPhone
alpine 不是用来部署的吗……
|
7
secondwtq 2020-09-06 02:06:00 +08:00 5
musl 有推广开的必要,不然就相当于很多程序依赖 glibc 的特定实现。
当然自己用不用是另一个问题。 |
8
cheng6563 2020-09-06 02:46:25 +08:00 via Android
实际上经常要进容器用 curl 或 telnet 什么的检查服务状态,alpine 还是太不好用了
|
9
halfcrazy 2020-09-06 03:20:09 +08:00
DNS a/aaaa 查询容易出现问题
|
10
jim9606 2020-09-06 07:43:17 +08:00
这篇文章有一个问题,通常情况下为了缩小最终镜像体积,会使用多阶段构建,临时容器中编译二进制库后复制进最终运行镜像中,可以除去占用大量空间的编译依赖、源码、中间产物。
alpine 更多的问题还是在 musl 上,要是用到了针对 glibc 编译的闭源库就没法用,以及 c 库的一些行为差异。 |
11
gimp 2020-09-06 08:06:00 +08:00
基于 Ubuntu 更好一点儿,没必要非要追求镜像特别小的体积,另外 Python 本身就是用到什么包安什么,用 Ubuntu 省心很多。
|
12
yzwduck 2020-09-06 08:15:41 +08:00 via Android
这篇文章还有一个问题,明明 AlpineLinux 官方 Community 仓库里提供了 py3-matplotlib 和 py3-pandas 之类常见的软件包,却偏偏还要用 pip 源代码编译。
|
13
whileFalse 2020-09-06 09:29:54 +08:00
哈,我倒是遇到过一个事儿,alpine 中的某个 linux 命令的实现和标准行为不一致,导致特定情况下出问题。
|
14
arischow 2020-09-06 10:05:46 +08:00 via iPhone
我觉得要我另外去了解 Alpine 很麻烦。而且用了 multi-stage build 的话,上一阶段用的 debian buster 构造出来的 pip wheels 不可能让 alpine 使用到
|
15
monsterxx03 2020-09-06 11:42:03 +08:00 via Android
依赖复杂点的项目基于 ubuntu slim 和 alpine 构建,最后你会发现大小没差多少
|
16
find456789 2020-09-06 13:25:31 +08:00
多阶段构建 了解一下?, 用 ubuntu 构建, 用 alpine 部署
|
17
blless 2020-09-06 14:19:07 +08:00
用 Go 编译基本没问题,但是遇到问题想进容器安装一些常用工具的时候 反而麻烦了。想了想反正也不缺那么点空间,后面都用 debian 做基础镜像了
|
18
Jirajine 2020-09-06 14:28:46 +08:00 via Android
@blless 反了吧,一般发行版的基础镜像啥工具都没有,临时测试 ping 之类的都得现装,而 alpine 是 busybox 的,常用工具基本上都不缺。
|
19
blless 2020-09-06 14:41:39 +08:00
@Jirajine 就是想装一些扩展工具啊,比如查看网络状态之类的工具,流量路由啥的 都是临时调试根据需要来的,正常没问题谁会想进容器敲命令啊。就算装正常的工具或者库,apline 要把 musl 相关库装完也没那么小了。
|
20
dcalsky 2020-09-06 15:08:04 +08:00
确实用 alpine+python 不见得体积会变比 slim 版本的小,毕竟还要各种 apk add
|
21
Jirajine 2020-09-06 15:37:04 +08:00 via Android
@blless 我到不是说大小,而是临时进容器里面的 shell 调试的时候 alpine 体验明显要比其他发行版好,busybox 自带的工具比其他发行版多,额外安装其他工具 apk 的速度也比 apt 快。
|
22
tt0411 2020-09-06 19:39:38 +08:00
用好镜像分层的特性, 镜像的大小不是什么大问题; 但如果用高度精简的基础镜像, 在排查问题时会因为缺这缺那非常痛苦
|
23
hronro 2020-09-06 20:05:27 +08:00 via iPhone
性能上来说,至少在 musl 自己的 benchmark 里性能在某些方面还是领先于 glibc 的: https://www.etalabs.net/compare_libcs.html,所以真要拿性能说事,你只有拿你自己最终的程序实际去测,看网上的文章是没用的。
其他方面,如果你对你程序的依赖掌控的比较清楚,用 Alpine 还是没啥问题的,毕竟谁不喜欢更小的镜像呢 |
24
ipwx 2020-09-06 20:21:31 +08:00
@yzwduck 那个啥,我看你是没见过(比如,真实情况的小版本号忘记了) pandas 0.19.2 不能用 0.19.3 能用的那种代码。。。 从源里面装你根本无法精确控制版本号啊
|
25
loading 2020-09-06 20:46:09 +08:00 via Android
看到回复这么少我就放心了,建议用更具争议的话题,这样流量更大些。
|