Question

我使用Docker 1.8.3。 /var/lib/docker/repositories-aufs存储与# docker images的输出匹配的本地图像信息。 /var/lib/docker/graph/<image GUID>维护每个图像的元数据等。

json包含有关图片的元数据。

layersize表示图层的大小。

什么是tar-data.json.gz和v1Compatibility？

# ll /var/lib/docker/graph/ca0ef69
drwx------   2 root root  4096 10月 29 12:08 ./
drwx------ 150 root root 20480 11月  1 12:29 ../
-rw-------   1 root root  1384 10月 29 12:06 json
-rw-------   1 root root     1 10月 29 12:06 layersize
-rw-------   1 root root    82 10月 29 12:06 tar-data.json.gz
-rw-------   1 root root  1384 10月 29 12:08 v1Compatibility

Answer 1

tar-data.json.gz存储图像层：
这似乎是PR 14067在docker 1.8中引入的。

此拉取请求引入了一个库（vbatts / tar-split），用于内联反汇编TAR压缩文件。
  反汇编不会进行任何提取，但会保留存档中的标头和填充的原始字节，并推迟提取。这样，验证和提取仍然是一个锁步过程。

对于此功能之后的docker pull，docker load或docker commit，将为图像层存储一个新的状态文件（例如/var/lib/docker/graph/<ID>/tar-data.json.gz）。

对于没有此新状态文件的现有映像，docker save或docker push生成的tar存档将回退到传统的graphdriver.Diff。

此功能的好处是，不是希望生成的graph.TarLayer是确定性的，而是将从原始存档的原始字节重新组装tar存档。

目前存在的问题是，从像Docker中心这样的仓库中提取的图像，然后推送到本地注册表可能会有新的摘要。

v1compatibility在docker 1.3（commit 15d5c7f）中引入，但仅用于commit 745820f中的docker 1.8（manifest.go）

// History stores unstructured v1 compatibility information
type History struct {
    // V1Compatibility is the raw v1 compatibility information
    V1Compatibility string `json:"v1Compatibility"`
}

真正在commit 504e67b中的docker 1.9（graph/graph.go）中使用，其中v1Compatibility JSON数据关联将清单中的图像存储到磁盘中。然后graph/pull_v2.go，在尝试重复使用代码时，可以检查其兼容性您可以在graph/pull_v2_test.go中看到它。

/ var / lib / docker / graph / <img guid=""/>中的tar-data.json.gz是什么

1 个答案: