Docker 下载更新的镜像以用于所谓的缓存摘要

Question

我的Dockerfile第一步是：

FROM python:3.6.10@sha256:6cd232ed00e729b4d4d3aa57c1764dddfab70f616042b7f36536e2c3d70c4c11

这样做的目的是“锁定”或“固定”图像的版本。

一段时间，docker build正确使用了缓存版本：

Step 1/2 : FROM python:3.6.10@sha256:6cd232ed00e729b4d4d3aa57c1764dddfab70f616042b7f36536e2c3d70c4c11
 ---> 114ae8bdb954

但过了一段时间，它决定“下载更新的图像”：

Step 1/2 : FROM python:3.6.10@sha256:6cd232ed00e729b4d4d3aa57c1764dddfab70f616042b7f36536e2c3d70c4c11
sha256:6cd232ed00e729b4d4d3aa57c1764dddfab70f616042b7f36536e2c3d70c4c11: Pulling from library/python
7e2b2a5af8f6: Pulling fs layer
09b6f03ffac4: Pulling fs layer
dc3f0c679f0f: Pulling fs layer
fd4b47407fc3: Pulling fs layer
bb7b28578995: Pulling fs layer
6ebea4a9a306: Pulling fs layer
22a2327cd1ca: Pulling fs layer
bfbf91c84bbe: Pulling fs layer
f6b29b259c5c: Pulling fs layer
09b6f03ffac4: Verifying Checksum
09b6f03ffac4: Download complete
dc3f0c679f0f: Download complete
7e2b2a5af8f6: Verifying Checksum
7e2b2a5af8f6: Download complete
6ebea4a9a306: Verifying Checksum
6ebea4a9a306: Download complete
fd4b47407fc3: Verifying Checksum
fd4b47407fc3: Download complete
bfbf91c84bbe: Verifying Checksum
bfbf91c84bbe: Download complete
f6b29b259c5c: Verifying Checksum
f6b29b259c5c: Download complete
22a2327cd1ca: Verifying Checksum
22a2327cd1ca: Download complete
bb7b28578995: Verifying Checksum
bb7b28578995: Download complete
7e2b2a5af8f6: Pull complete
09b6f03ffac4: Pull complete
dc3f0c679f0f: Pull complete
fd4b47407fc3: Pull complete
bb7b28578995: Pull complete
6ebea4a9a306: Pull complete
22a2327cd1ca: Pull complete
bfbf91c84bbe: Pull complete
f6b29b259c5c: Pull complete
Digest: sha256:6cd232ed00e729b4d4d3aa57c1764dddfab70f616042b7f36536e2c3d70c4c11
Status: Downloaded newer image for python@sha256:6cd232ed00e729b4d4d3aa57c1764dddfab70f616042b7f36536e2c3d70c4c11
 ---> 114ae8bdb954

即使此步骤的最终哈希值是相同的：

 ---> 114ae8bdb954

据我了解，摘要 ( sha256:...) 是不可变的。
那么它们到底是可变的吗？
或者缓存的版本是否以某种方式被删除了？
这是怎么回事？我该如何解决？

Answer 1

鉴于这种情况不会在每次运行时发生，并且如果您在本地测试也可能不会发生，因此问题似乎不在于您的 Dockerfile 或 FROM 行。Docker 不会自动清理缓存，因此您需要调查哪些外部进程正在删除缓存。由于您使用 kubernetes 插件在 Jenkins 中运行构建，因此问题似乎是由该插件在超时后清理构建代理造成的。从文档中，您可以看到调整此构建器的各种设置：

• podRetention控制保留从属 Pod 的行为。可以是“never()”、“onFailure()”、“always()”或“default()” - 如果为空，则默认在activeDeadlineSeconds过去后删除 pod。
• activeDeadlineSeconds如果podRetention设置为“never()”或“onFailure()”，则在超过此截止日期后删除 pod。
• idleMinutes允许 Pod 保持活动状态以供重用，直到自执行最后一步以来经过配置的分钟数。

解决临时构建代理问题的一种方法是使用命令--cache-from中的选项docker build。使用经典构建（与 buildkit 相比），您需要首先在本地拉取此映像。该图像将来自以前的构建，并且您可以使用多个图像作为缓存，这对于多阶段构建特别有用，因为您需要为每个阶段提取缓存。该标志告诉 docker 信任从注册表中提取的映像，因为通常只有本地构建的映像才是可信的（存在有人可能注入恶意映像的风险，该恶意映像声称已在流行映像中运行步骤，但在该层的 tar 中包含恶意软件） 。