你的 Python 镜像还好吗？

Posted 2023-03-18

参考技术A 随着 k8s 集群规模变大，以及弹性扩容的触发，导致 harbor 仓库的瓶颈问题逐渐暴露出来，目前也做了一些优化措施：

在做镜像优化的时候，发现之前我们的 python 提速方案还有一些瑕疵，所以有了这里的分析。
在 Python 项目构建 Docker 镜像时，经常遇到项目源码才几百 KB，但是安装的依赖能高达数百 MB，甚至 GB，这不仅使镜像体积变的很大，而且因为网络安装依赖包导致严重拖慢构建速度。

注意：这里仅关系依赖问题，所以忽略源码部分

示例 1：

相当糟糕，依赖安装了 713MB，花了 5 分钟，太慢了。

基于刚才已经构建过的依赖镜像，再次去构建时间工作的镜像
示例 2：

为什么这里再次安装 requirements.txt，直接删掉该步骤不就好了吗？
实际情况下，研发人员可能会在仓库中修改 requirements.txt，如果这里不再次安装下，最终发版可能就要提示缺少包而报错了。这里再次安装下依赖，就是防止该问题。

再次构建，相当好，8 秒，再次安装的依赖层 0B（我们这里没有模拟研发人员修改 requirements.txt 的情况），我们取得了巨大的进步。

这个词有点像电影里的镜头，以示例 2 中的 Dockerfile 再次构建：
示例 3：

问题来了，随着岁月的流逝，构建时间怎么变成了 2 分钟，再次安装的依赖层 173MB（我们这里没有模拟研发人员修改 requirements.txt 的情况）

原来安装依赖的时候除了上面 requirements.txt 中写好的依赖，还有一些没有出现在 requirements.txt 中的依赖，而这些依赖的版本如 grpcio>=1.8.6 会随着时间的推移，而产生不同的版本
...
Requirement already satisfied: grpcio>=1.8.6 in /usr/local/lib/python3.6/site-packages (from tensorflow==2.0.0b1->-r /code/requirements.txt (line 9)) (1.34.1)
Requirement already satisfied: wheel>=0.26 in /usr/local/lib/python3.6/site-packages (from tensorflow==2.0.0b1->-r /code/requirements.txt (line 9)) (0.33.4)
...