docker集线器图像caching似乎没有工作
我们在circleci上有一个持续的整合stream程，
- 从caching目录加载repo / image：mytag1，以便能够使用caching图层
- 构build一个新版本：docker build -t repoimage：mytag2
- 使用docker save将新版本保存到caching目录
- 运行testing
- 推到docker集线器：docker推回购/图像：mytag2
问题是在第5步。推动步骤每次需要5分钟。 如果我理解正确，docker hub是为了caching图层，所以如果没有更新，我们不必重新推送像基本图像和依赖关系的东西。
我连续运行了两次构build，并且在被推送的层的散列中看到了很多交叉。 而不是“图像已经存在”，我看到“图像成功推送”。
这里是build 1的docker push的输出， 这里是build 2
如果您对这两个文件进行比较，则会看到每个构build中只有两个不同的层：
< ca44fed88be6: Buffering to Disk < ca44fed88be6: Image successfully pushed < 5dbd19bfac8a: Buffering to Disk < 5dbd19bfac8a: Image successfully pushed --- > 9136b10cfb72: Buffering to Disk > 9136b10cfb72: Image successfully pushed > 0388311b6857: Buffering to Disk > 0388311b6857: Image successfully pushed 那么为什么每次都要重新推送所有的图像呢？
使用不同的标签会创build一个不同的图像，当被推送时，不能依赖caching。
例如两个命令：
$ docker commit -m "thing" -a "me" db65bf421f96 me/thing:v1 $ docker commit -m "thing" -a "me" db65bf421f96 me/thing:v2
尽pipe它们是从相同的图像（db65bf421f96）创build的，但完全可以产生明显的图像。 在推送时，dockerhub必须将它们视为完全独立的图像，如下所示：
$ docker images REPOSITORY TAG IMAGE ID me/thing v2 f14aa8ac6bae me/thing v1 c7d72ccc1d71
图像ID是唯一的，因此即使只有标签不同，图像也是唯一的。
你可以说“docker工人应该认识到他们是有点相同的”，因此把他们当作可以清除的。 但是它还没有。
在你的例子中唯一让我感到意外的是你有任何重复的图像ID。
在“构build你自己的图像”中的docker工人可以find权威的（如果不那么解释） 文档 。
这个过程应该像你描述的那样工作。 事实上，我们正在以这种方式构build我们所有的图像，没有任何问题。 通常最顶层只有一些变化，只有那些被推送到registry – 否则图像层的整个概念将是无用的。
看这里的例子。 只有最上面两层发生了变化，被推到:latest :4.0.2根本没有推。 我们使用git标签来标记图像，而对于一些项目，我们甚至使用git describe标记图像 – 以获得回滚function，以防万一。
您也可以从GitHub获得项目源代码来尝试。
关于设置的一些注意事项：我们正在使用一个自定义的GitLab CI，它带有一个自定义的运行器，它在Docker 1.9.1的独立主机上运行docker和docker-compose ，但这应该没有什么区别。
在registry版本中可能也有差异，我有这种感觉（但我不是100％肯定的），DockerHub上的一些旧版本仍然在registryv1上运行，新版本在v2上仍然运行 – 所以您可以尝试创build一个新的回购并看看问题是否仍然存在。
请注意，上述标签的行为只适用于推送相同图像名称的情况，如果您使用其他名称推送相同的图像层，则始终需要推送所有图层，尽pipe所有图层都应该已经存在registry，所以我想repo/image:mytag1和repoimage:mytag2实际上去repo/image和缺less的斜线只是一个错字。
另一个原因可能是你的图像是在Circle CI上的不同主机上build立的，但是你也应该得到不同的图层ID，所以我认为这不太可能。
我build议手动构build一个图像，并尝试重现问题或联系Circle CI关于这个问题。