docker - Docker镜像层: `ADD file: in/`是什么意思？

Question

在Docker Hub镜像中，存在针对每个镜像层运行的命令的列表。这是golang example。
一些应用程序还在GitHub中提供了其 Dockerfile 。这是golang example。
根据Docker Hub镜像层，ADD file:4b03b5f551e3fbdf47ec609712007327828f7530cc3455c43bbcdcaf449a75a9 in /是第一个命令。图像层不包含任何“FROM”命令，而且ADD definition似乎也不足够。
所以这是问题:

ADD file:<HASH> in /是什么意思？这是什么格式？

有什么我可以使用哈希向上跟踪的方法吗？我想哈希表示FROM图像，但是似乎没有API。

为什么无法使用ADD file:<HASH> in /语法构建dockerfile？有什么办法可以使用这种语法构建图像，还是可以在两种格式之间进行转换？

Answer 1

该Docker Hub历史 View 未显示实际的Dockerfile;相反，它显示的是本质上从图像的docker history中提取的内容。这不会保留您要查找的特定详细信息:它不会记住基础图像的名称，也不会记住获得ADD或COPY的事物的构建上下文文件名。
通过GitHub和Docker Hub链接， golang:*-buster Dockerfile构建为FROM buildpack-deps:...-scm； buildpack-deps:buster-scm 是FROM buildpack-deps:buster-curl; that是FROM debian:buster;并带有a very simple Dockerfile(在此处完整引用):

FROM scratch
ADD rootfs.tar.xz /
CMD ["bash"]

FROM scratch从一个完全空白的图像开始；这是Docker镜像树的基础(告诉 docker history和类似工具停止运行的原因)。 ADD行解压缩Debian系统镜像的tar文件。
如果您查看 docker history或引用的Docker Hub历史记录 View ，则应该能够看到这些相同的步骤。 ADD file:4b0... in /对应于 ADD rootfs.tar.gz /，第二行是 CMD ["bash"]。它不会被Dockerfile或镜像分割，并且不会保存 ADD中的原始文件名。 (如果没有 rootfs.tar.gz的内容，您无论如何都无法复制图像，因此了解其文件名只是一点帮助，但并非必不可少。) ADD file:hash in /path语法不是标准的Dockerfile语法(特别是 in这个词不是它的一部分)。我不确定是否存在将主机文件或URL转换为哈希的可靠方法，但是构建图像并查看其 docker history会告诉您(假设您已完全匹配文件元数据)。没有办法返回到原始文件名或语法，而且绝对没有办法回到文件内容。