Question

我的Dockerfile第一步：

FROM python:3.6.10@sha256:6cd232ed00e729b4d4d3aa57c1764dddfab70f616042b7f36536e2c3d70c4c11

目标是to "lock" or "pin" the version of the image。

一段时间以来，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中运行构建，因此问题似乎出在该插件超时后清理构建代理。从文档中，您可以看到various settings to tune this builder：

podRetention 控制保留从属Pod的行为。可以是'never（）'，'onFailure（）'，'always（）'或'default（）'-如果为空默认为在Col27=TRUE通过之后删除广告连播。

activeDeadlineSeconds 如果将Col28=8设置为'never（）'或'onFailure（）'，则超过该期限后会删除pod。

idleMinutes 允许Pod保持活动状态以便重用，直到从上一步开始经过配置的分钟数为止在上面执行。

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

Answer 2

摘要有两种：注册表中图像清单的摘要和本地图像的JSON配置摘要，其中还包含图像内容的摘要。

第一个摘要：python:3.6.10@sha256:6cd232ed00e729b4d4d3aa57c1764dddfab70f616042b7f36536e2c3d70c4c11 是Docker Hub中清单清单的摘要。

摘要不可更改。

如果两个不同的事物产生相同的摘要值-则哈希函数（在这种情况下使用sha256）将被破坏，无法再使用。参见collision.

就您而言，由于某种原因，它不再找到缓存的图像。它再次下载了同一张图片。

最后（---> 114ae8bdb954）的结果摘要是该图像（图像ID）的结果配置摘要。

您可以确认下载了正确的清单：

docker inspect 114ae8bdb954

其中包括：

"RepoDigests": [
            "python@sha256:6cd232ed00e729b4d4d3aa57c1764dddfab70f616042b7f36536e2c3d70c4c11"
        ],

由于两种情况下的图像ID均相同，因此我认为没有什么要修复的。但是，如果总是发生这种情况，缓存就会出现一些问题。

编辑缓存：如果在docker-in-docker方案中完成此操作-如果在父Docker构建阶段之前发生了某些变化，它将始终再次重建该映像。

有关图像ID的更多信息：https://windsock.io/explaining-docker-image-ids/

Docker下载更新的映像以进行缓存摘要

2 个答案: