很多官方 docker 镜像都出了基于 alpine 的版本，相较于正常的版本， alpine 版会有什么坑吗？

单独的服务有优势，但是如果在一台机子上部署 N 个服务的话，alpine 便没有优势

另外，如果涉及编译的话，alpine 用的是 musl libc，这一点要注意

相比于 alpine，你提到的那些系统有更加丰富的软件库、系统各种特性用法的普及度更高，在已有镜像基础上去安装新的程序成本更低。

拿来单独当服务器也挺好玩的版本，真的很快，还默认源里就有 ss，就是目前还不能支持 virtualbox

```
postgres:<version>-alpine
This image is based on the popular Alpine Linux project, available in the alpine official image. Alpine Linux is much smaller than most distribution base images (~5MB), and thus leads to much slimmer images in general.

This variant is highly recommended when final image size being as small as possible is desired. The main caveat to note is that it does use musl libc instead of glibc and friends, so certain software might run into issues depending on the depth of their libc requirements. However, most software doesn't have an issue with this, so this variant is usually a very safe choice. See this Hacker News comment thread for more discussion of the issues that might arise and some pro/con comparisons of using Alpine-based images.

To minimize image size, it's uncommon for additional related tools (such as git or bash) to be included in Alpine-based images. Using this image as a base, add the things you need in your own Dockerfile (see the alpine image description for examples of how to install packages if you are unfamiliar).
```

早前很多镜像都有这么一段说明，但是后来发现没什么问题，越来越多的镜像已经去掉这一段了。

docker 镜像是共享的，
也就是所有底层是 ubuntu1804 的 nginx、php 镜像共用一个 ubuntu1804，单个看着空间占用大，但是平均起来并没有多少。
所以只要还有一个依赖于 ubuntu，那么其他的即使换成 alpine 并不会减小总空间占用，还会增加 alpine 的占用，意义就不是很大了。

alpine 没用过几次，ubuntu 的库还是比 alpine 齐全，资料也好查。

glibc 换成了 musl 要注意

@gamexg 额，也就是说如果有多个容器，使用了同样的镜像，或者使用了不同的景象但是 FROM 是一样的，这时不会占用额外的空间，他们是共享这些镜像里的文件的。但是如果某个容器“不小心”动了里面的文件，会不会影响其他的后果。我准备先试一下

@VD
@jonsun30 这个我知道，像有些镜像就没有 alpine 版本，比如 MySQL。但是在作为镜像使用者的时候，我们也许不会太过于关注这两个 C 库的区别的，比如：gLibc 和 muslLibC 的 nginx 或 OpenJDK 有啥差别么

直接使用的话其实没啥区别，区别只在于你要使用它作为自己的镜像的 From 的时候，alpine 版本可能无法提供你所需要的东西

@qwerthhusn 不会有其他后果。因为 Docker 的文件系统是一层层叠起来的，每一层都是只读的。

https://medium.com/@nagarwal/docker-containers-filesystem-demystified-b6ed8112a04a

目前碰到一个坑，就是没有内置信任的 https 根证书

@mchl 不太清楚什么意思？？ https://hackernoon.com/alpine-docker-image-with-secured-communication-ssl-tls-go-restful-api-128eb6b54f1f

FROM alpine:latest
RUN apk update && apk add ca-certificates && rm -rf /var/cache/apk/*
COPY ./mycert.crt /usr/local/share/ca-certificates/mycert.crt
RUN update-ca-certificates

我把公司的 k8s 环境中 200+Pod 全都换成了 alpine，跑到现在已经半年了，除了验证码不显示等几个小小坑，其余的坑没有遇到过，同时减少了 docker 仓库和 K8S Node 中的容量占用 总体看起来很值~

我觉得如果是 python 就没太大必要用了，因为很可能要装一大堆依赖，不但浪费时间，也可能有不可预见的问题，因为 musl，最重要的是得到的镜像大小并没有差别很大

apline 的 musl 在 /etc/resolv.conf 里不支持全部 option set, 对 dns 有特殊要求的可能有问题.

还有 apline 里面是 busybox, 有些程序如果用 shell 调用一些系统命令, 可能参数不一样会出错(比如 fluentd 的某个版本调用 gzip)

> 但是如果多个镜像（包括每个镜像运行的多个容器）使用了同一个基础镜像，是不会花费额外的空间的
> 也就是所有底层是 ubuntu1804 的 nginx、php 镜像共用一个 ubuntu1804

理想情况是这样
实际上 docker hub 的每个镜像的 FROM ubuntu:latest 未必是同一个，几十个 ubuntu:latest 和几十个 alpine:latest 可能会有不小差距
每个 image 都自己从头 build 且统一更新的可以忽略这点

感觉没啥意义，如果有得选我肯定不愿意用。

楼上有朋友说了，是 glibc，所以好多通用软件没法直接用。比如 jdk，当时被坑了一晚上。找了 zulu 专门对 apline 编译过的 openjdk。虽然 alpine 的源里就有。当时没配置好网络，没法用 apk 安装

缺 glibc 主要坑就是效率问题。

alpine 源里东西很全，几乎所有常用的都有，坑我没遇到过，自带 vi，源小装包快优势太多

@Imr docker run --rm -it alpine vi 确实是的

alpine 最大的缺点就是 glibc，很多第三方库必须得有 glibc 才能用
alpine 的第二大缺点是一但装上 glibc 以后，瞬间就变大好多，短小精悍的优势荡然无存

没有 glibc 和 https 的证书，所以每次都是 alpine 然后我手动装 glibc 和 ca-certificate

@momocraft 这样说也是，像那些官方的镜像，很多都是几十分钟前编译的（编译频率很高），虽然软件版本号没有变化，但是基础镜像的 HASH 值都变化了，估计缓存也很难命中了

对于自己的服务环境，没任何卵用，镜像本来就是分层对比拉取的，装机环节就可以直接提前 pull 基础镜像，而且内部环境基本不存在所谓的小镜像加速这种伪需求，dragonfly 自身也能加速某个 layer，根本不用不着这么多花里胡哨的，又不是做 IOT

我之前遇到一个 postgres 的坑，alphine 的 postgres 对中文支持不全。后面数据库的镜像一律 base Ubuntu，其他的继续用 alphine。