图像清单V 2，架构2

预计阅读时间：9分钟

映像清单版本2，架构2

本文档概述了V2映像清单（架构版本2）的格式。V2（模式1）的原始（和临时）映像清单是在v1.3.0版本的Docker守护进程中引入的， 并在架构1清单中进行了指定。定义

第二个模式版本具有两个主要目标。第一种是通过“胖清单”允许多体系结构映像，该“胖清单”引用映像清单以获取特定于平台的映像版本。第二个是通过支持图像模型将Docker引擎移向内容可寻址的图像，在该模型中可以对图像的配置进行哈希处理以生成图像的ID。

媒体类型

此处描述的清单格式及其引用的资源使用以下媒体类型：

• application/vnd.docker.distribution.manifest.v1+json：schema1（现有清单格式）
• application/vnd.docker.distribution.manifest.v2+json：新的图像清单格式（schemaVersion = 2）
• application/vnd.docker.distribution.manifest.list.v2+json：清单清单，又称“脂肪清单”
• application/vnd.docker.container.image.v1+json：容器配置JSON
• application/vnd.docker.image.rootfs.diff.tar.gzip：“图层”，作为压缩的tar
• application/vnd.docker.image.rootfs.foreign.diff.tar.gzip：“图层”，作为绝对不应推送的压缩焦油
• application/vnd.docker.plugin.v1+json：插件配置JSON

清单清单

清单清单是“胖清单”，它指向一个或多个平台的特定图像清单。它的使用是可选的，并且相对较少的图像将使用这些清单之一。客户端将基于HTTP响应中返回的Content-Type将清单列表与图像清单区分开。

清单清单字段说明

• schemaVersion 整型

  该字段将图像清单架构版本指定为整数。该模式使用version 2。

• mediaType 细绳

  清单清单的MIME类型。应该设置为 application/vnd.docker.distribution.manifest.list.v2+json。

• manifests 大批

  清单清单包含特定平台的清单清单。

  清单清单中对象的字段是：

  • mediaType 细绳

    被引用对象的MIME类型。通常是 application/vnd.docker.distribution.manifest.v2+json，但application/vnd.docker.distribution.manifest.v1+json如果清单列表引用了旧的schema-1清单，也可能是。

  • size 整型

    对象的大小（以字节为单位）。此字段存在，以便客户端在验证之前具有预期的内容大小。如果检索到的内容的长度与指定的长度不匹配，则不应信任该内容。

  • digest 细绳

    内容的摘要，由Registry V2 HTTP API Specification定义 。

  • platform 目的

    平台对象描述清单中的图像运行所在的平台。有效的操作系统和架构值的完整列表中所列的围棋语言的文档$GOOS和 $GOARCH

    • architecture 细绳

      架构字段指定CPU架构，例如 amd64或ppc64le。

    • os 细绳

      os字段指定操作系统，例如 linux或windows。

    • os.version 细绳

      可选的os.version字段指定操作系统版本，例如10.0.10586。

    • os.features 大批

      可选的os.features字段指定一个字符串数组，每个字符串列出所需的OS功能（例如Windows win32k）。

    • variant 细绳

      可选变量字段指定CPU的变量，例如armv6l，指定ARM CPU的特定CPU变量。

    • features 大批

      可选功能字段指定一个字符串数组，每个字符串列出所需的CPU功能（例如sse4或aes）。

清单清单示例

该示例显示了一个简单的清单清单，该清单指向两个平台的图像清单：

{
  "schemaVersion": 2,
  "mediaType": "application/vnd.docker.distribution.manifest.list.v2+json",
  "manifests": [
    {
      "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
      "size": 7143,
      "digest": "sha256:e692418e4cbaf90ca69d05a66403747baa33ee08806650b51fab815ad7fc331f",
      "platform": {
        "architecture": "ppc64le",
        "os": "linux",
      }
    },
    {
      "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
      "size": 7682,
      "digest": "sha256:5b0bcabd1ed22e9fb1310cf6c2dec7cdef19f0ad69efa1f392e94a4333501270",
      "platform": {
        "architecture": "amd64",
        "os": "linux",
        "features": [
          "sse4"
        ]
      }
    }
  ]
}

图像清单

图像清单提供了容器图像的配置和一组图层。它是schema-1清单的直接替代。

图像清单字段说明

• schemaVersion 整型

  该字段将图像清单架构版本指定为整数。此架构使用version 2。

• mediaType 细绳

  清单的MIME类型。应该设置为 application/vnd.docker.distribution.manifest.v2+json。

• config 目的

  config字段通过摘要引用容器的配置对象。此配置项是运行时用于设置容器的JSON Blob。此新模式使用此配置的调整版本，以允许守护程序端进行图像内容寻址。

  配置对象的字段是：

  • mediaType 细绳

    被引用对象的MIME类型。通常应该如此 application/vnd.docker.container.image.v1+json。

  • size 整型

    对象的大小（以字节为单位）。此字段存在，以便客户端在验证之前具有预期的内容大小。如果检索到的内容的长度与指定的长度不匹配，则不应信任该内容。

  • digest 细绳

    内容的摘要，由Registry V2 HTTP API Specification定义 。

• layers 大批

  图层列表是从基本图像开始排序的（与schema1相反的顺序）。

  图层列表中项目的字段为：

  • mediaType 细绳

    被引用对象的MIME类型。通常应该如此application/vnd.docker.image.rootfs.diff.tar.gzip。application/vnd.docker.image.rootfs.foreign.diff.tar.gzip可以从远程位置拉出类型的图层， 但是绝对不要将其推入。

  • size 整型

    对象的大小（以字节为单位）。此字段存在，以便客户端在验证之前具有预期的内容大小。如果检索到的内容的长度与指定的长度不匹配，则不应信任该内容。

  • digest 细绳

    内容的摘要，由Registry V2 HTTP API Specification定义 。

  • urls 大批

    提供可以从中获取内容的URL列表。内容应根据digest和进行验证size。该字段是可选的，不常见。

示例图片清单

显示图像清单的示例：

{
    "schemaVersion": 2,
    "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
    "config": {
        "mediaType": "application/vnd.docker.container.image.v1+json",
        "size": 7023,
        "digest": "sha256:b5b2b2c507a0944348e0303114d8d93aaaa081732b86451d9bce1f432a537bc7"
    },
    "layers": [
        {
            "mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
            "size": 32654,
            "digest": "sha256:e692418e4cbaf90ca69d05a66403747baa33ee08806650b51fab815ad7fc331f"
        },
        {
            "mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
            "size": 16724,
            "digest": "sha256:3c3a4604a545cdc127456d94e421cd355bca5b528f4a9c1905b15da2eb4a4c6b"
        },
        {
            "mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
            "size": 73109,
            "digest": "sha256:ec4b8955958665577945c89419d1af06b5f7636b4ac3da7f12184802ad867736"
        }
    ]
}

向后兼容

注册表将继续接受旧格式和新格式的清单清单。

推送图像时，支持新清单格式的客户端应首先以新格式构造清单。如果上载此清单失败，可能是因为注册表仅支持旧格式，因此客户端可能会退回到上载旧格式的清单。

提取图像时，客户端会在向端点发出请求时通过在标头中发送application/vnd.docker.distribution.manifest.v2+json和 application/vnd.docker.distribution.manifest.list.v2+json媒体类型来 指示对清单格式新版本的支持 。更新的客户端应检查标头，以查看从端点返回的清单是旧格式，还是新格式的图像清单或清单列表。AcceptmanifestsContent-Type

如果所请求的清单使用新格式，并且Accept标头中不存在适当的媒体类型，则注册表将假定客户端无法按原样处理清单，并即时将其重写为旧格式。如果原本将返回的对象是清单列表，则注册表将查找适用于amd64平台和linux OS的清单，并在必要时将该清单重写为旧格式，然后将结果返回给客户端。如果在清单列表中找不到合适的清单，则注册表将返回404错误。

将清单重写为旧格式的挑战之一是，旧格式涉及清单中每一层的图像配置，但是新格式仅提供一个图像配置。要解决此问题，注册表将为除顶层以外的所有层创建合成图像配置。这些映像配置不会自己生成可运行的映像，而只是用来以兼容的方式填充父链。这些合成配置中的ID将从它们各自的blob的哈希值中得出。当注册表创建旧清单以推送到不支持新格式的注册表时，该注册表将使用与Docker 1.10相同的方案来创建这些配置及其ID。