关于这个主题的唯一doc似乎假设我已经知道清单是什么,它解决的问题,以及它如何适应docker生态系统.在阅读了文档后,我仍然不确定清单是如何实际工作的.
我的私人GCR包含清单文件 – 并不真正了解它们的用途. docker hub是否也使用清单文件?我可以看到它们包含每层的图层和哈希,但我仍然不清楚docker如何生成/使用它们.
容器清单的目的是什么?
声称拥有Docker distribution v2 API / v2.2映像规范支持的任何注册表或运行时都将与各种清单类型进行交互以找出:
>为容器构建根文件系统需要哪些实际的文件系统内容(层),以及..
>知道如何使用此图像运行容器所需的任何特定图像配置.例如,启动容器时要运行的命令之类的信息(可能在用于构建映像的Dockerfile中表示).
作为前面提到的答案,与注册表通信的客户端(例如docker pull实现)将通过Docker v2 API进行交互,首先获取特定图像/标记的清单,然后确定要下载的内容除了能够基于此图像运行容器. v2清单格式没有编码到其中的签名,但使用诸如notary server之类的工具的外部验证可用于验证内容的相同“blob”/散列上的外部签名以获得完整的加密信任. Docker称之为“Docker内容信任”,但在与注册表通信时不需要它,在与图像注册表通信时也不是API流的一部分.
关于v2.2规范中清单的另一个细节:不仅有标准清单类型,还有清单列表类型,允许注册表在单个“image:tag”下表示对多个平台(cpu或操作系统变体)的支持“参考.清单列表只有一个平台条目列表,其中包含现有清单的重定向器,以便引擎可以检索该特定平台/体系结构组合的正确组件.在今天的DockerHub中,所有官方图像现在都是清单列表,允许使用相同的图像名称支持许多平台:标记组合.我有一个工具,可以查询注册表中的条目,并显示它们是否是清单列表,还转储清单的内容 – 清单列表和“常规”清单.您可以在manifest-tool GitHub repository阅读更多内容.
来自this talk on containerd design的幻灯片12还具有关于清单列表如何链接到清单的良好图形表示,其表示特定平台的图像配置和层.