我想将其用作我的基础容器镜像。但我发现，当我使用 安装应用程序时，debian:bookworm容器镜像（根据）增长得非常快。diveapt-get
免责声明：这些“基准”结果是在我的计算机上重复运行几次后得出的平均值，但我认为大致可以代表问题。
比较单个应用程序
FROM debian:bookworm-slim
RUN apt-get update && apt-get install -y --no-install-recommends nginx
FROM alpine:3.18.2
RUN apk add --no-cache nginx
结果是：
| 根据 | 构建时间 | 尺寸 |
|---|---|---|
| 高山 | 2.3秒 | 9.2 兆 |
| debian-slim | 5.1秒 | 132 兆 |
debian-slim因为速度较慢，所以需要更长的时间apt-get update，但是对于单个应用程序来说，基础图像差异是显著的。
与多个应用程序进行比较
FROM debian:bookworm-slim
RUN apt-get update && apt-get install -y --no-install-recommends nginx curl wget git iputils-ping rsync unzip && \
apt-get clean && \
rm -rf /var/cache/apt/archives /var/lib/apt/lists/*
FROM alpine:3.18.2
RUN apk add --no-cache nginx curl wget git iputils-ping rsync unzip
| 根据 | 构建时间 | 尺寸 |
|---|---|---|
| 高山 | 3.2秒 | 23 兆 |
| debian-slim | 9.0秒 | 201 兆 |
Alpine 增加了 0.9 秒，增加了 13.8 MB。Debian 增加了 3.9 秒，增加了 69 MB。
文件列表
使用docker run --rm -it <tag> du -h > debian.txt
高山：https://pastebin.com/mHTHDFwW Debian-Slim：https://pastebin.com/wTpuYGDD
perl大约 50 MB 似乎与？有关。
极端情况示例
我有一个包含许多构建工具（Java、Go、NodeJS 等）的图像，这显然会很重，但我仍然惊讶于它竟然有 7.1 GB。但这可能不是 debian/apt 的错。运行它就pip3 install ansible增加了 565 MB，其中 222 MB 是用于fortinet（我想很少有人使用），所以我想教训是使用包管理器时要小心，不要使用宽泛的nginx或ansible，而要使用更具体/明确的包。
问题
为什么 Debian 体积变大了这么多，而应用程序安装速度却慢了很多？这对于大型容器镜像尤其重要，因为两者之间的差异可能是 100 MB 而不是 1 GB。
从我在网上读到的内容来看，Alpine 更前沿，可与 Arch 媲美，具有社区级软件包，而 Debian 软件包更值得信赖。对于企业用途，在安全至关重要的环境中，使用 Debian 软件包似乎很有必要，但也很难证明如此大的图像是合理的。Alpine 是否值得企业使用？（理想情况下，所有二进制文件都是可复制的，并由开发人员签名，因此独立构建将是值得信赖的，但我知道我们离这个目标还很远？）。
有什么办法可以减少 Debian 的大小/构建时间吗？一种选择是手动安装二进制文件。apt-get update在构建服务器上使用 apt-proxy 可以加快速度吗？
一种解释可能是，alpine 图像具有许多内置依赖项（busybox？），而debian/debian-slim需要添加它们？