Python 基本映像通过Jenkine管道在我的docker文件中导致缓存崩溃

当我在生产服务器上通过Jenkins而不是在本地机器上构建时，由于我的基本Python映像，我在随机时间观察缓存崩溃，这有点奇怪。这种破坏是随机发生的，并非总是如此。我还没有找到一个模式

我的docker文件的前几个命令：

FROM python:2.7

RUN mkdir -p /usr/src/app
WORKDIR /usr/src/app

ARG DEBIAN_FRONTEND=noninteractive
RUN apt-get update && apt-get install --assume-yes apt-utils
RUN apt-get update && apt-get install -y curl
RUN apt-get update && apt-get install -y unzip

生成过程的日志生成编号：74，无缓存破坏：

17:11:02 [workspace] Running shell script
17:11:02 + docker build -t ourapi:0.5.3 .
17:11:02 Sending build context to Docker daemon 232.4 kB

17:11:03 Step 1/14 : FROM python:2.7
17:11:03  ---> 26bddf7dbe1b
17:11:03 Step 2/14 : RUN mkdir -p /usr/src/app
17:11:03  ---> Using cache
17:11:03  ---> ec1bf9b7071a
17:11:03 Step 3/14 : WORKDIR /usr/src/app
17:11:03  ---> Using cache
17:11:03  ---> df4b29a9466b

下一个破坏了缓存：

15:28:48 [workspace] Running shell script
15:28:48 + docker build -t ourapi:0.5.8 .
15:28:48 Sending build context to Docker daemon 243.2 kB

15:28:48 Step 1/14 : FROM python:2.7
15:28:50 2.7: Pulling from library/python
15:28:50 aa18ad1a0d33: Already exists
15:28:50 15a33158a136: Already exists
15:28:50 f67323742a64: Already exists
15:28:50 c4b45e832c38: Already exists
15:28:50 b71152c33fd2: Pulling fs layer
15:28:50 299c2fe5f47f: Pulling fs layer
15:28:50 6116a194f6b5: Pulling fs layer
15:28:50 3631cfa2c8cc: Pulling fs layer
15:28:50 3631cfa2c8cc: Waiting
15:28:50 6116a194f6b5: Verifying Checksum
15:28:50 6116a194f6b5: Download complete
15:28:50 b71152c33fd2: Verifying Checksum
15:28:50 b71152c33fd2: Download complete
15:28:51 299c2fe5f47f: Verifying Checksum
15:28:51 299c2fe5f47f: Download complete
15:28:51 b71152c33fd2: Pull complete
15:28:51 3631cfa2c8cc: Download complete
15:28:53 299c2fe5f47f: Pull complete
15:28:53 6116a194f6b5: Pull complete
15:28:53 3631cfa2c8cc: Pull complete
15:28:53 Digest: sha256:0cb0d5aa3cbb61374d83ce324e8ffee86cebc66a94c4d5ab08a67b650538d660
15:28:53 Status: Downloaded newer image for python:2.7
15:28:53  ---> 26bddf7dbe1b

---

更新：这是因为Jenkins管道中的一个脚本正在运行一个清理脚本，该脚本删除了这些基本图像

docker缓存依赖于服务器上现有的上一层以及正在运行相同命令的缓存层。从您提供的命令来看，您没有向build命令传递-pull，因此它不是对python映像进行上游更改的结果。剩下的两个可能原因是：

很可能您已经删除了以前的版本，也可能删除了基础映像。这是通过docker rmi、docker映像修剪或docker系统修剪命令实现的

您可以在构建服务器上更新python映像。您提供的日志没有显示这一点，但我将保留它，以防您的其他缓存Bust没有显示拉取输出。在这种情况下，另一个构建或外部进程可能会提取python:2.7的新副本，这将使该构建的缓存无效，因为python:2.7标记现在指向一个新的映像id。您将在日志中看到这个新id

---

您提供的命令不会替换python映像。在构建服务器上运行哪些其他命令来清理或更新图像？您能否验证python映像在构建运行之前存在并且与之前的运行相同？另外，您是否有显示映像摘要的以前运行的日志？能否确认映像SHA256是相同的？@BMitch还有其他命令，但它们只是在生成命令之前克隆bitbucket repo。由于我使用docker system prune清理了服务器，因此无法针对该特定构建验证它。如果下次发生的话，我会做的。建造76、78、79都很顺利。但是，这种情况偶尔也会发生。@AndyShinn Build 75的值不同于71 lass cache bust，但71和70的值相同，而70也是一个cache bust。在中间，没有缓存崩溃。构建失败，但这不应该导致缓存崩溃。我偶尔会运行Docker system prune。我认为它只会删除不必要的图像/容器。我甚至在面对这个问题后对它进行了测试。我运行了docker system prune，然后尝试了另一个未破坏缓存的构建。如果您的标记以某种方式被删除或指向具有不同层集的图像，docker system prune将删除此缓存。如果您使用docker system prune-a，这将删除图像，即使它已被标记。几天后，我再次尝试了一些更改，它再次下载了一个新的Python基本图像，重复docker命令的其余部分。用日志更新了问题。我确保这次没有运行docker system prune或docker image prune。您的构建服务器上现在有标记为python:2.7的图像吗？在构建开始之前，您有过吗？您现在有一个带有旧python校验和的未标记图像吗？没有，它的Python2的ID为fa8e55b2235d，这与我上一个Python2.7 ID不同。刚才注意到我的一位同事正在python的另一个项目docker文件中使用以下内容：2。好像是在使我的缓存失效。