如何优化 gcloud builds 的 Python 依赖缓存以避免重复安装

gcloud builds submit 默认不复用 docker 层缓存，导致每次构建都重装 pip 包；启用 kaniko 缓存并合理分层 copy，可显著提升构建速度与可复现性。

如果你用过 Google Cloud Build，尤其是通过 gcloud builds submit 命令，大概率遇到过这个烦人的问题：明明本地构建飞快，一到云端就慢如蜗牛，每次都要从头安装所有 Python 包。这感觉就像每次开车前都得重新造一遍轮子，效率低下不说，还白白浪费构建时间。

问题的根源，其实不在你的 Dockerfile 写得不好。即便你严格遵循了最佳实践——先 COPY requirements.txt，再 RUN pip install——在 Cloud Build 的默认模式下，这些优化也几乎形同虚设。因为默认的构建器不具备跨构建会话的持久化缓存能力，它不会继承任何之前的 Docker 层缓存。所以，每一次提交，都意味着一次从零开始的重建。

那么，有没有办法让云端构建也“聪明”起来，记住已经安装过的依赖呢？答案是肯定的，关键在于启用 Google 官方支持的 Kaniko 缓存模式。

启用 Kaniko：两步开启云端缓存

Kaniko 是一个专门为容器化和无守护进程环境设计的镜像构建工具。它的一个核心优势，就是能够将构建过程中产生的中间层（比如安装好的 site-packages）推送到远程仓库（如 GCR 或 Artifact Registry），并在后续构建中根据哈希值复用，只要源文件没变。

配置起来非常简单，只需两条命令（全局生效，一次设置即可）：

gcloud config set builds/use_kaniko True
gcloud config set builds/kaniko_cache_ttl 8

这里，kaniko_cache_ttl 8 设定了缓存的有效期为 8 小时。你可以根据团队的发布频率灵活调整：如果 CI 构建非常频繁，可以设为 4 小时；如果是夜间批量构建，设为 24 小时甚至更长也无妨。

重构 Dockerfile：适配缓存逻辑

光启用 Kaniko 还不够，你的 Dockerfile 结构必须与之配合。核心原则是：将所有会影响依赖安装结果的文件，在 RUN pip install 命令之前就 COPY 进镜像，并且确保这一层不会混入经常变动的应用源码。

举个例子，如果你的项目需要编译 Cython 扩展，理想的 Dockerfile 结构应该是这样的：

FROM python:3.12-slim
ENV APP_HOME /app
WORKDIR $APP_HOME

# ✅ 关键：仅 COPY 依赖声明和构建脚本（不变或低频变更）
COPY requirements.txt setup_pyd.py CoreLoop.pyx ./

# 安装 Python 包（此层将被 Kaniko 缓存）
RUN pip install --no-cache-dir -r requirements.txt

# 编译 Cython（同样进入缓存层，只要 .pyx 或 setup.py 不变）
RUN python setup_pyd.py build_ext --inplace \
    --include-dir=/usr/local/lib/python3.12/site-packages/numpy/core/include

# ❌ 此后才 COPY 全量应用代码（高频变更，不破坏上游缓存）
COPY . .

CMD ["python", "main.py"]

这样分层之后，只要 requirements.txt、setup_pyd.py 和 .pyx 文件内容不变，Kaniko 就会直接复用之前构建好的、包含所有依赖的镜像层。频繁更改的应用源码放在最后 COPY，就不会触发依赖层的重建。

实践中的注意事项

为了确保缓存机制稳定可靠，还有几个细节需要留意：

• 使用 --no-cache-dir：在 pip install 时显式添加这个参数是个好习惯。它可以避免 pip 自身的临时缓存干扰 Kaniko 对层哈希值的计算。
• 锁定依赖版本：确保 requirements.txt 里使用固定版本（例如 requests==2.31.0），而不是浮动版本（如 requests>=2.30）。否则，即使文件内容没变，pip 也可能安装更新的包，导致缓存失效。
• 关于 Artifact Registry：如果使用 Artifact Registry 而非默认的 GCR，Kaniko 支持通过 --cache 参数指定高级缓存仓库。不过，对于大多数场景，上面提到的 gcloud config 配置方式已经足够。
• 首次构建：启用缓存后的第一次构建，仍然需要完整安装所有依赖。但从第二次开始，只要依赖文件未变，构建速度通常能有 60% 以上的提升，效果立竿见影。

说到底，gcloud builds 默认的“重复安装”行为并非缺陷，而是一种设计上的保守选择。通过主动启用 Kaniko 缓存，并精心设计 Dockerfile 的分层策略，你完全可以在云原生构建流水线中，获得媲美本地开发的高效体验。这不仅提升了速度，也增强了构建过程的可复现性，何乐而不为呢？