这是一个创建于 1550 天前的主题，其中的信息可能已经有所发展或是发生改变。
还在用 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
看到回复这么少我就放心了，建议用更具争议的话题，这样流量更大些。
|
Select Language