Docker图像caching失效何时发生？
也许我的Google Foo不够强大，但是我无法find关于caching中的Docker镜像何时失效的明确列表。 具体而言，我至less在这些情况下感兴趣：
- 由于mtime更改与校验和更改而失效。 哪个适用时？ 它可以处理不同的源代码path（例如，在不同目录中的存储库的克隆）？
- 因更新的基础图像而失效。 在什么时候（安全）更新Debian的泡沫到我这里？
- 是否有任何显式的API ，持续集成工具可以用来告诉Docker哪些caching的图像可以被重用，哪些不能（例如因为
wget foo.com/latest.gz）？
从Docker 1.8开始，Docker不再使用mtime来使caching无效（在此请求＃12031中已更改）。
build立图像时
- 对于本地内容（
ADD myfiles /somewhere/COPY myfiles /somewhere），docker使用校验和更改来使caching无效 - 总是下载远程内容（
ADD http://example.com/foobar /somewhere），但基于校验和更改构buildcaching失效 -
RUN指令（如wget foo.com/latest.gz）不会使caching失效，除非指令被改变; 即，高速caching基于指令中的文本。 如果您想要可重复的构build，请确保这些URL指向特定的版本（wget http://example.com/package-major.minor.patch.gz）
Docker 1.9引入了对构build时参数的支持，使您能够传递可在Dockerfile中使用的variables，以便不必编辑Dockerfile来中断caching或安装不同版本的包。
例如
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 ，但是传递“major”，“minor”或“patch”构build时间参数会覆盖要下载的版本，并且会使caching;
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
有关构buildcaching的更多信息，请阅读文档中的构buildcaching部分 。
在什么时候（安全）更新Debian的泡沫到我这里？
Docker 不会自动下载更新的图像，或更新基于它们的图像。 但是，如果您的docker pull yourbaseimage ，并下载了一个较新的图像，则基于此的图像的构buildcaching将失效，因此下一个构build将不使用caching。
为了在Docker集线器上自动构build ，可以确保在更新基础映像时自动重build映像，请参阅有关自动构build的文档