当前位置: 首页 > 知识库问答 >
问题:

Docker是否构建--实际上没有缓存下载并刷新基本映像?

史弘致
2023-03-14

docker是否构建--无缓存刷新更新的远程基本映像?文档似乎没有具体说明。

共有3个答案

西门梓
2023-03-14

--没有缓存会在不使用缓存的情况下重建图像,因此它本质上是一个干净的构建。

根据帮助docker build--help--no cache在构建映像时不要使用cache

杜楚
2023-03-14

docker build(docker构建)--没有缓存将在不重用缓存层的情况下重建整个映像,但它不会从远程存储库中提取最新的基本映像。它将只使用本地存储的图像。

常睿范
2023-03-14

“无缓存”选项将在不使用本地缓存层的情况下重建图像。但是,如果已提取的基本映像存在于生成主机上,则“发件人”行将重用该基本映像(发件人行本身可能不会被缓存,但它提取的映像会被缓存)。如果要再次拉取基础图像,可以使用build命令的“拉”(pull)选项。例如。

$ docker build --no-cache --pull -t new-image-name:latest .

要查看build命令采用的所有选项,可以运行

$ docker build --help

或参见https://docs.docker.com/engine/reference/commandline/build/

以下是一个如何自己测试此行为的示例

$ # very simple Dockerfile
$ cat df.test
FROM busybox:latest
RUN echo hello >test.txt

$ # pull an older version of busybox
$ docker pull busybox:1.29.2
1.29.2: Pulling from library/busybox
8c5a7da1afbc: Pull complete
Digest: sha256:cb63aa0641a885f54de20f61d152187419e8f6b159ed11a251a09d115fdff9bd
Status: Downloaded newer image for busybox:1.29.2

$ # retag that locally as latest
$ docker tag busybox:1.29.2 busybox:latest

$ # run the build, note the image id at the end of each build step
$ DOCKER_BUILDKIT=0 docker build --no-cache -f df.test .
Sending build context to Docker daemon  23.04kB
Step 1/2 : FROM busybox:latest
 ---> e1ddd7948a1c
Step 2/2 : RUN echo hello >test.txt
 ---> Running in dba83fef49f9
Removing intermediate container dba83fef49f9
 ---> 1f824ff05612
Successfully built 1f824ff05612

$ # rerun the build, note step 1 keeps the same id and never pulled a new latest
$ DOCKER_BUILDKIT=0 docker build --no-cache -f df.test .
Sending build context to Docker daemon  23.04kB
Step 1/2 : FROM busybox:latest
 ---> e1ddd7948a1c
Step 2/2 : RUN echo hello >test.txt
 ---> Running in 73df884b0f48
Removing intermediate container 73df884b0f48
 ---> e5870de6c24f
Successfully built e5870de6c24f

$ # run with --pull and see docker update the latest image, new container id from step 1
$ DOCKER_BUILDKIT=0 docker build --no-cache --pull -f df.test .
Sending build context to Docker daemon  23.04kB
Step 1/2 : FROM busybox:latest
latest: Pulling from library/busybox
Digest: sha256:2a03a6059f21e150ae84b0973863609494aad70f0a80eaeb64bddd8d92465812
Status: Downloaded newer image for busybox:latest
 ---> 59788edf1f3e
Step 2/2 : RUN echo hello >test.txt
 ---> Running in 7204116ecbf4
Removing intermediate container 7204116ecbf4
 ---> 2c6d8c48661b
Successfully built 2c6d8c48661b

$ # one last run now that busybox:latest is updated shows the pull has nothing to do
$ DOCKER_BUILDKIT=0 docker build --no-cache --pull -f df.test .
Sending build context to Docker daemon  23.04kB
Step 1/2 : FROM busybox:latest
latest: Pulling from library/busybox
Digest: sha256:2a03a6059f21e150ae84b0973863609494aad70f0a80eaeb64bddd8d92465812
Status: Image is up to date for busybox:latest
 ---> 59788edf1f3e
Step 2/2 : RUN echo hello >test.txt
 ---> Running in f37e19024e99
Removing intermediate container f37e19024e99
 ---> 044a5d4011c4
Successfully built 044a5d4011c4
 类似资料:
  • 问题内容: docker是否建立–no-cache刷新 更新的 远程基本映像?文档似乎没有指定。 问题答案: 该选项将重建图像,而无需使用本地缓存的图层。但是,该行将重用已经拉出的基础映像(如果它已存在于构建主机上)(from行本身可能不会被缓存,但是它拉出的映像是已缓存的)。如果要再次拉出基础映像,可以使用build命令的选项。例如 要查看build命令采用的所有选项,可以运行 或参阅https

  • 我想将某些 Docker 映像设为公共(当前为私有)。所以,基本上我希望从GCR下载大厅构建(私有存储库,然后上传到dockerhub(公共存储库) 我目前的做法是在docker容器中使用

  • 问题内容: 我尝试在主机上创建几个不同的目录,以尝试了解Docker,以使dockerfile井井有条。我刚运行的Dockerfile如下所示: 我的实际转速仅为1 GB。但是,当我尝试这样做时,我将向Docker守护进程3.5 GB发送构建上下文。当您继续构建Docker映像时,还有其他我不知道的事情吗?当我在主机上的其他目录中构建更多映像时,是否正在累积内存? 问题答案: Docker客户端将

  • 存在可以强制构建仅在特定JDK版本上运行的maven强制执行器插件。 我想知道有没有什么实际的理由?我们已经构建了配置来指定源和目标版本。据我所知,这已经足够了,因为Java是向后兼容的。例如,它在gradle中的外观: maven就是这样的: 如果你看到任何需要jdk确切版本的理由,请你也写下来。 UPD。问题更多的是,编译版本8的java源/目标项目和JDK的8、9、10或11是否有任何实际差

  • 问题内容: 在i386 linux上。如果可能,最好在c /(c / posix std libs)/ proc中。如果没有,那么任何程序集或第三方库都可以做到这一点? 编辑:我正在尝试开发测试内核模块是否清除缓存行或整个处理器(与wbinvd())。程序以root身份运行,但我希望尽可能保留在用户空间中。 问题答案: 高速缓存一致性系统会尽最大努力向您隐藏此类信息。我认为您将不得不通过使用性能计

  • 问题内容: 我正在尝试为Ruby项目构建Docker映像。问题在于该项目具有一些gem依赖项,需要构建本机扩展。我的理解是,我有两种选择: 从已经安装了构建工具的基础映像开始。 使用没有构建工具的基础映像,并在运行之前在Dockerfile中安装构建工具。 在主机上预编译本机扩展,将gem供应商化,然后简单地将生成的包复制到映像中。 1和2似乎要求生成的映像包含构建本机扩展所需的构建工具。出于安全