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

问题描述：

由于我的基本Python镜像在随机时间内观察缓存半身像，当我在生产服务器上通过Jenkins构建但未在本地机器上构建时，这有点奇怪。这种破坏发生在随机的时间，并非总是如此。我还没有找到一个模式。我的搬运工文件的基础镜像导致通过Jenkine管道在我的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管道内的一个脚本正在运行清理脚本删除这些基本图像的pt。

您提供的命令不会替换python图像。您在构建服务器上运行了哪些其他命令来清理或更新图像？你可以在构建运行之前验证python图像是否存在，并且与之前的运行相同？ – BMitch

另外，您是否有以前运行的日志显示图像摘要？你能确认图像SHA256是一样的吗？ –

@BMitch还有其他命令，但它们只是在构建命令之前克隆bitbucket回购。我无法验证它的特定版本，因为我使用“docker system prune”清理了服务器。如果下一次发生，我会做。建设76,78,79一切正常。但是，它现在确实发生了。 – utengr

答

码头缓存依赖于服务器上现有的图层以及正在运行相同命令的缓存图层。从您提供的命令中，您没有将--pull传递给构建命令，因此它不是上游更改为python图像的结果。剩下的两个可能的原因是：

很可能您已经删除了先前的构建和可能的基础映像。这发生在docker rmi，docker image prune或docker system prune命令。
您可能已经更新了构建服务器上的python图像。您提供的日志不会显示此内容，但是我会将其保留以防其他缓存区域大小不显示“拉出”输出。在这种情况下，由于python：2.7标签现在指向一个新的图像ID，所以另一个构建或外部进程可能会提取一个新的python副本：2.7，这将会使该构建的缓存失效。你会在你的日志中看到这个新的ID。

我现在运行Docker系统修剪。我认为它只会删除不必要的图像/容器。我在面对这个问题后甚至测试过它。我运行码头系统修剪，然后尝试另一个没有破解缓存的生成。 – utengr

如果您的标签以某种方式被删除或指向具有不同图层组的图像，“docker system prune”将删除此缓存。如果你使用'docker system prune -a'，这将删除图像，即使它被标记。 – BMitch

几天后，我再次尝试了几次更改，并再次下载了一个新的Python基本镜像，重复其余的docker命令。用日志更新了问题。我确信这次没有运行泊坞窗系统修剪或泊坞窗图像修剪。 – utengr

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

相关推荐