关于这个主题的唯一doc似乎假设我已经知道清单是什么，它解决了什么问题，以及它如何适应docker生态系统。在阅读了文档之后，我仍然不确定清单是如何实际运作的。
我的私人GCR包含清单文件 - 并非真正了解其用途。 docker hub是否也使用清单文件？我可以看到它们包含每层的图层和哈希，但我还不清楚docker如何生成/使用它们。
容器清单的目的是什么？
答案 0 :(得分：14)
清单类型实际上是命名/标记图像的JSON表示描述。此描述（清单）旨在供容器运行时使用，如Docker引擎。
声称拥有Docker distribution v2 API / v2.2图像规范支持的任何注册表或运行时都将与各种清单类型进行交互以找出：
Dockerfile中表示）。如上所述，与注册表通信的客户端（例如docker pull实现）将通过Docker v2 API进行交互，以首先获取特定图像/标记的清单，然后确定要下载的内容除了能够基于此图像运行容器。 v2清单格式没有编码到其中的签名，但使用notary server等工具的外部验证可用于验证内容的相同内容上的外部签名以获得完整的加密信任。 Docker称之为“＃Docker Content Trust＆＃34;但在与注册表交谈时不需要它，在与图像注册表交谈时也不是API流程的一部分。
v2.2规范中有关清单的一个额外细节：不仅有标准的清单类型，还有清单列表类型，它允许注册表代表对多个平台的支持（CPU或操作）系统变体）在单个＆＃34; image:tag＆＃34;参考。清单列表只有一个平台条目列表，其中包含现有清单的重定向器，以便引擎可以检索该特定平台/体系结构组合的正确组件。在DockerHub中，所有官方图像现在都是清单列表，允许使用相同的图像name:tag组合支持许多平台。我有一个工具，可以查询注册表中的条目，并显示它们是否是清单列表，还转储清单的内容 - 清单列表和＆＃34;常规＆＃34;体现。您可以在manifest-tool GitHub repository了解更多信息。
来自this talk on containerd design的幻灯片12还有一个很好的图形表示，表明清单列表如何链接到清单，表示特定平台的图像配置和图层。
答案 1 :(得分：4)
image是 JSON清单和单个图层文件的组合。拉动图像的过程围绕检索这两个组件。所以当你拉一个图像文件：
获取清单：
GET /v2/<name>/manifests/<reference>
当清单在手时，客户端必须验证签名以确保名称和图层有效。
然后，客户端将使用摘要下载各个层。图层以blobs注册表API的形式存储在V2中，并以其摘要为关键字。