Docker映像缓存何时失效？ [英] When does Docker image cache invalidation occur?

问题描述

也许我的Google Foo不够强大，但是我找不到关于缓存中的Docker映像何时失效的确切列表。具体来说，我至少对以下情况感兴趣：

Maybe my Google Foo is not strong enough, but I can't find a definite list about when Docker images in the cache are invalidated. Specifically, I'm interested at least in these scenarios:

• 由于 mtime更改与校验和更改 。什么时候适用？它可以处理不同的源路径（例如，存储库在不同目录中的克隆）吗？


• 由于更新后的基本映像而无效。届时（安全性）更新例如Debian冒犯了我？


• 是否存在任何显式API ，持续集成工具可以用来告诉Docker哪些缓存映像可以重复使用，哪些不能重复使用？ （例如，由于 wget foo.com/latest.gz ）？

• Invalidation because of mtime changes vs checksum changes. Which applies when? Can it deal with different source paths (e.g. clones of the repository in different directories)?
• Invalidation because of updated base images. At which point will (security) updates of e.g. Debian bubble down to me?
• Are there any explicit APIs that a continuous integration tool can use to tell Docker which cached images can be reused and which can't (for example because of a wget foo.com/latest.gz)?

推荐答案

从Docker 1.8开始，Docker不再使用 mtime 来使缓存无效（此请求请求中的此更改＃12031 ）。

As of Docker 1.8, Docker no longer uses mtime to invalidate the cache (this changed in this pull request #12031).

构建映像时;

• 对于本地内容（ ADD myfiles / somewhere / COPY myfiles / somewhere ），docker使用校验和更改使缓存无效


• 远程内容（ ADD http://example.com / foobar / somewhere ）总是被下载，但基于校验和的更改构建缓存无效


• RUN 指令（例如 wget foo.com/latest.gz）永远不会使缓存无效，除非更改了指令；也就是说，缓存基于指令中的文本。如果您想要可复制的版本，请确保这些URL指向特定版本（ wget http://example.com/package-major.minor.patch.gz)
  

• For local content (ADD myfiles /somewhere / COPY myfiles /somewhere), docker uses checksum changes to invalidate the cache
• Remote content (ADD http://example.com/foobar /somewhere), is always downloaded, but the build-cache is invalidated based on checksum changes
• RUN instructions (such as wget foo.com/latest.gz) will never invalidate the cache, unless the instruction is changed; i.e., the cache is based on the text in the instruction. If you want reproducible builds, make sure these URLs point to a specific version (wget http://example.com/package-major.minor.patch.gz)

Docker 1.9引入了对构建时参数，它使您可以传递可在Dockerfile中使用的变量，从而无需编辑Dockerfile即可中断缓存或安装该软件包的其他版本。

Docker 1.9 introduced support for build-time arguments, which enable you to pass variables that can be used inside the Dockerfile so that you don't have to edit the Dockerfile to break the cache, or install a different version of the package.

例如

FROM foobar
ARG MAJOR=1
ARG MINOR=0
ARG PATCH=0
ADD http://example.com/package-$MAJOR.$MINOR.$PATCH.gz /

将添加 http://example.com/package-1.0.0.gz 默认情况下，但是，传递主要，次要或补丁构建时间参数可以覆盖要下载的版本，并且将使缓存无效；

Will add http://example.com/package-1.0.0.gz by default, however, passing a "major", "minor" or "patch" build-time parameter can override the version to download, and will invalidate the cache;

docker build --build-arg MINOR=2 .                                           Sat Jan 16 13:22:40 2016
Sending build context to Docker daemon 2.048 kB
Step 1 : FROM ubuntu
 ---> 1c9b046c2850
Step 2 : ARG MAJOR=1
 ---> Using cache
 ---> a149d88772ba
Step 3 : ARG MINOR=0
 ---> Using cache
 ---> e3dae0189ffd
Step 4 : ARG PATCH=0
 ---> Using cache
 ---> 678d7ae33054
Step 5 : ADD http://example.com/package-$MAJOR.$MINOR.$PATCH.gz /
Get http://example.com/package-1.2.0.gz: dial tcp 127.0.0.1:80: getsockopt: connection refused

有关构建缓存的更多信息，请阅读文档中的构建缓存部分。 / p>

For more information about the build-cache, read the build-cache section in the documentation.

此时（安全性）将更新例如Debian冒泡给我？

At which point will (security) updates of e.g. Debian bubble down to me?

Docker会不自动下载更新的图像，或更新您的图像基于它们。但是，如果您 docker pull yourbaseimage ，并且下载了新的映像，则基于该映像的构建缓存将无效，因此下一个构建将 not 使用缓存。

Docker will not automatically download updated images, or update your images that are based on them. However, if you docker pull yourbaseimage, and a newer image is downloaded, then the build-cache for images based on that is invalidated, so the next build will not use the cache.

对于Docker集线器上的自动构建，如果基于以下情况，您可以确保自动重建映像：映像已更新，请参见有关自动构建的文档

For automated builds on Docker hub, you can make sure that images are automatic rebuilt if the base-image is updated, see the documentation on automated builds

这篇关于Docker映像缓存何时失效？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！