image所包含的内容以及格式都是有标准的,由Open Containers Initiative(OCI)负责维护,地址为image-spec,本文将对该标准做一个简单的解释。

image包含的内容

一个image由manifestimage index(可选)、filesystem layersconfiguration四部分组成。

关系图

先来看看构成image的四部分的关系图:
+———————————-+
| Image Index(optional) |
+———————————-+
|
| 1..

+———————————+
| Image Manifest |
+———————————+
|
1..1 | 1..

+———————-+———————+
| |
↓ ↓
+———————+ +—————————-+
| Image Config | | Filesystem Layers |
+———————+ +—————————-+

  • Image Index和Manifest的关系是”1..*”,表示它们是一对多的关系
  • Image Manifest和Config的关系是”1..1”,表示它们是一对一的关系
  • Image Manifest和Filesystem Layers是一对多的关系

下面分别介绍它们各自都包含了哪些内容。

Filesystem Layers

Filesystem Layer包含了文件系统的信息,即该image包含了哪些文件/目录,以及它们的属性和数据。

包含的内容

每个filesystem layer都包含了在上一个layer上的改动情况,主要包含三方面的内容:

  • 变化类型:是增加、修改还是删除了文件
  • 文件类型:每个变化发生在哪种文件类型上
  • 文件属性:文件的修改时间、用户ID、组ID、RWX权限等

比如在某一层增加了一个文件,那么这一层所包含的内容就是增加的这个文件的数据以及它的属性,具体的细节请参考标准文档

打包格式

最终每个layer都会打包成一个文件,这个文件的格式可以是tar和tar+gzip两种中的一种。
对于这两种不同类型的文件格式,标准定义了两个新的media types,分别是application/vnd.oci.image.layer.v1.tar和application/vnd.oci.image.layer.v1.tar+gzip。
同时标准还定义了application/vnd.oci.image.layer.nondistributable.v1.tar和application/vnd.oci.image.layer.nondistributable.v1.tar+gzip这两种对应于nondistributable的格式,其实这两种格式和前两种格式包含的内容是一样的,只是用不同的类型名称来区分它们的用途,对于名称中有nondistributable的layer,标准要求这种类型的layer不能上传,只能下载。
做过web开发的程序员对media type应该比较熟悉,简单点说,就是当客户端用http协议下载一个文件的时候,需要在http的首部带上Accept字段,告诉服务器端它支持哪些类型的文件,服务器返回文件的时候,需要在http的首部带上Content-Type字段,告诉客户端返回文件的类型,如Accept: text/html,application/xml和Content-Type: text/html。

Image Config

image config就是一个json文件,它的media type是application/vnd.oci.image.config.v1+json,这个json文件包含了对这个image的描述。先看看官方网站给的例子:

  1. {
  2. "created": "2015-10-31T22:22:56.015925234Z",
  3. "author": "Alyssa P. Hacker <alyspdev@example.com>",
  4. "architecture": "amd64",
  5. "os": "linux",
  6. "config": {
  7. "User": "alice",
  8. "ExposedPorts": {
  9. "8080/tcp": {}
  10. },
  11. "Env": [
  12. "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin",
  13. "FOO=oci_is_a",
  14. "BAR=well_written_spec"
  15. ],
  16. "Entrypoint": [
  17. "/bin/my-app-binary"
  18. ],
  19. "Cmd": [
  20. "--foreground",
  21. "--config",
  22. "/etc/my-app.d/default.cfg"
  23. ],
  24. "Volumes": {
  25. "/var/job-result-data": {},
  26. "/var/log/my-app-logs": {}
  27. },
  28. "WorkingDir": "/home/alice",
  29. "Labels": {
  30. "com.example.project.git.url": "https://example.com/project.git",
  31. "com.example.project.git.commit": "45a939b2999782a3f005621a8d0f29aa387e1d6b"
  32. }
  33. },
  34. "rootfs": {
  35. "diff_ids": [
  36. "sha256:c6f988f4874bb0add23a778f753c65efe992244e148a1d2ec2a8b664fb66bbd1",
  37. "sha256:5f70bf18a086007016e948b04aed3b82103a36bea41755b6cddfaf10ace3c6ef"
  38. ],
  39. "type": "layers"
  40. },
  41. "history": [
  42. {
  43. "created": "2015-10-31T22:22:54.690851953Z",
  44. "created_by": "/bin/sh -c #(nop) ADD file:a3bc1e842b69636f9df5256c49c5374fb4eef1e281fe3f282c65fb853ee171c5 in /"
  45. },
  46. {
  47. "created": "2015-10-31T22:22:55.613815829Z",
  48. "created_by": "/bin/sh -c #(nop) CMD [\"sh\"]",
  49. "empty_layer": true
  50. }
  51. ]
  52. }

这里只介绍几个比较重要的属性,其它的请参考标准文档

  • architecture:CPU架构类型,现在大部分都是amd64,不过arm64估计会慢慢多起来
  • os:操作系统,本人只用过linux
  • config:当根据这个image启动container时,config里面的配置就是运行container时的默认参数,在后续介绍runtime的时候再仔细介绍每一项的意义
  • rootfs:指定了image所包含的filesystem layers,type的值必须是layers,diff_ids包含了layer的列表(顺序排列),每一个sha256就是每层layer对应tar包的sha256码

    Image Manifest

    manifest也是一个json文件,media type为application/vnd.oci.image.manifest.v1+json,这个文件包含了对前面filesystem layers和image config的描述,一看官方网站给出的示例就明白了:
    manifest文件中config的sha256就是image的ID,即上面image config文件的sha256值,这里是b5b2b2c507a0944348e0303114d8d93aaaa081732b86451d9bce1f432a537bc7

    1. {
    2. "schemaVersion": 2,
    3. "config": {
    4. "mediaType": "application/vnd.oci.image.config.v1+json",
    5. "size": 7023,
    6. "digest": "sha256:b5b2b2c507a0944348e0303114d8d93aaaa081732b86451d9bce1f432a537bc7"
    7. },
    8. "layers": [
    9. {
    10. "mediaType": "application/vnd.oci.image.layer.v1.tar+gzip",
    11. "size": 32654,
    12. "digest": "sha256:e692418e4cbaf90ca69d05a66403747baa33ee08806650b51fab815ad7fc331f"
    13. },
    14. {
    15. "mediaType": "application/vnd.oci.image.layer.v1.tar+gzip",
    16. "size": 16724,
    17. "digest": "sha256:3c3a4604a545cdc127456d94e421cd355bca5b528f4a9c1905b15da2eb4a4c6b"
    18. },
    19. {
    20. "mediaType": "application/vnd.oci.image.layer.v1.tar+gzip",
    21. "size": 73109,
    22. "digest": "sha256:ec4b8955958665577945c89419d1af06b5f7636b4ac3da7f12184802ad867736"
    23. }
    24. ],
    25. "annotations": {
    26. "com.example.key1": "value1",
    27. "com.example.key2": "value2"
    28. }
    29. }
  • config里面包含了对image config文件的描述,有media type,文件大小,以及sha256码

  • layers包含了对每一个layer的描述,和对config文件的描述一样,也包含了media type,文件大小,以及sha256码

这里layer的sha256和image config文件中的diff_ids有可能不一样,比如这里的layer文件格式是tar+gzip,那么这里的sha256就是tar+gzip包的sha256码,而diff_ids是tar+gzip解压后tar文件的sha256码

Image Index(可选)

image index也是个json文件,media type是application/vnd.oci.image.index.v1+json。
其实到manifest为止,已经有了整个image的完整描述,为什么还需要image index这个文件呢?主要原因是manifest描述的image只能支持一个平台,也没法支持多个tag,加上index文件的目的就是让这个image能支持多个平台和多tag。
image index是v1.0.0-rc5才加进来的一个文件,还不稳定,后面可能还会修改,并且docker现在也不支持该文件,这里看看官方给的示例,先了解一下:

  1. {
  2. "schemaVersion": 2,
  3. "manifests": [
  4. {
  5. "mediaType": "application/vnd.oci.image.manifest.v1+json",
  6. "size": 7143,
  7. "digest": "sha256:e692418e4cbaf90ca69d05a66403747baa33ee08806650b51fab815ad7fc331f",
  8. "platform": {
  9. "architecture": "ppc64le",
  10. "os": "linux"
  11. }
  12. },
  13. {
  14. "mediaType": "application/vnd.oci.image.manifest.v1+json",
  15. "size": 7682,
  16. "digest": "sha256:5b0bcabd1ed22e9fb1310cf6c2dec7cdef19f0ad69efa1f392e94a4333501270",
  17. "platform": {
  18. "architecture": "amd64",
  19. "os": "linux",
  20. "os.features": [
  21. "sse4"
  22. ]
  23. }
  24. }
  25. ],
  26. "annotations": {
  27. "com.example.key1": "value1",
  28. "com.example.key2": "value2"
  29. }
  30. }

index文件包含了对image中所有manifest的描述,相当于一个manifest列表,包括每个manifest的media type,文件大小,sha256码,支持的平台以及平台特殊的配置。
比如ubuntu想让它的image支持amd64和arm64平台,于是它在两个平台上都编译好相应的包,然后将两个平台的layer都放到这个image的filesystem layers里面,然后写两个config文件和两个manifest文件,再加上这样一个描述不同平台manifest的index文件,就可以让这个image支持两个平台了,两个平台的用户可以使用同样的命令得到自己平台想要的那些layer。
image index最新的标准里面并没有涉及到tag,不过估计后续会加上。

image layout

上面介绍了image所包含的内容,在开始介绍layout之前,先来回顾一下上一篇介绍hello-world时提到的从register服务器拉image的过程:

  • 首先获取image的manifests
  • 根据manifests文件中config的sha256码,得到image config文件
  • 遍历manifests里面的所有layer,根据其sha256码在本地找,如果找到对应的layer,则跳过,否则从服务器取相应layer的压缩包
  • 等上面的所有步骤完成后,就会拼出完整的image

从上面的过程中可以看出,我们从服务器上取image的时候不需要知道image manifests和config文件的名字,也不需要知道layer压缩包的名字。
那么image从服务器拉下来后,在本地应该怎么存储呢?文件名称和目录结构应该是怎样的呢?OCI也有相应的标准,名字叫image layout,有了这样的标准之后,我们就可以将整个image打成一个包,方便的在不同机器,不同容器平台之间导入导出。
不过遗憾的是,OCI的这个标准还在变化中,根据github上所看到的,v1.0.0-rc5在v1.0.0-rc4上就有较大的修改,并且现在docker也不支持该标准。
docker对OCI image layout的支持还在开发中,相关动态请关注:Support OCI image layout in docker save/load
这里我们看看v1.0.0-rc4的格式,下面是hello-world image的目录结构,了解一下:
dev@debian:~/images/hello-world$ tree
.
├── blobs
│ └── sha256
│ ├── 636fcf0bc8246e08d2df4771dc764d35ea50428b8dfaa904773b0707cb4f6303
│ ├── 7520415ce76232cdd62ecc345cea5ea44f5b6b144dc62351f2cd2b08382532a3
│ └── 9b8e3ce88f3a2aaa478cfe613632f38d27be5eddaa002a719fa1bfa9ff4f7f63
├── oci-layout
└── refs
└── latest

oci-layout

包含image标准的版本信息
dev@debian:~/images/hello-world$ cat ./oci-layout| jq .
{
“imageLayoutVersion”: “1.0.0”
}

refs

里面的每个文件就是一个tag(hello-world的image中只有一个latest tag),每个tag都是一个单独的image,相当于一个image的layout包里面可以包含多个有关系的image,文件的内容如下:
dev@debian:~/images/hello-world$ cat ./refs/latest | jq .
{
“mediaType”: “application/vnd.oci.image.manifest.v1+json”,
“digest”: “sha256:9b8e3ce88f3a2aaa478cfe613632f38d27be5eddaa002a719fa1bfa9ff4f7f63”,
“size”: 347
}
其实就是对manifest文件的描述,根据sha256就可以在blobs的目录里面找到相应的manifest文件

blobs

里面包含了具体文件的内容,每个文件名都是其内容的sha256码,根据上面refs文件里面的sha256,就能在这里找到对应的manifest文件的内容,然后根据manifest文件的内容,就能一步一步的往下找到image config文件和filesystem layers文件。
dev@debian:~/images/hello-world$ file ./blobs/sha256/*
./blobs/sha256/636fcf0bc8246e08d2df4771dc764d35ea50428b8dfaa904773b0707cb4f6303: ASCII text, with very long lines, with no line terminators
./blobs/sha256/7520415ce76232cdd62ecc345cea5ea44f5b6b144dc62351f2cd2b08382532a3: gzip compressed data
./blobs/sha256/9b8e3ce88f3a2aaa478cfe613632f38d27be5eddaa002a719fa1bfa9ff4f7f63: ASCII text, with very long lines, with no line terminators

dev@debian:~/images/hello-world$ sha256sum ./blobs/sha256/*
636fcf0bc8246e08d2df4771dc764d35ea50428b8dfaa904773b0707cb4f6303 ./blobs/sha256/636fcf0bc8246e08d2df4771dc764d35ea50428b8dfaa904773b0707cb4f6303
7520415ce76232cdd62ecc345cea5ea44f5b6b144dc62351f2cd2b08382532a3 ./blobs/sha256/7520415ce76232cdd62ecc345cea5ea44f5b6b144dc62351f2cd2b08382532a3
9b8e3ce88f3a2aaa478cfe613632f38d27be5eddaa002a719fa1bfa9ff4f7f63 ./blobs/sha256/9b8e3ce88f3a2aaa478cfe613632f38d27be5eddaa002a719fa1bfa9ff4f7f63

下载image

上面介绍image layout时用到了hello-world的image,它是从哪里来的呢?
为了快速的构建container的rootfs,docker在本地有它自己的一套image管理方式,有自己的layout,并且目前docker save命令也不支持导出OCI格式的image,只能导出docker自己的格式,所以我们只能借助其它的工具得到OCI格式的image。
这里我们用skopeo来演示一下从docker hub上拉取hello-world的image,并把它在本地存成OCI的layout。
这里生成的layout和最新版本的标准有点差别,和v1.0.0-rc4的标准一致,如果你用同样的命令得到不一样的layout,说明skopeo有更新,支持了更新的标准。
#这里的所有命令在debian 8.6的环节上运行通过
#编译安装skopeo
$ git clone https://github.com/projectatomic/skopeo $GOPATH/src/github.com/projectatomic/skopeo
$ sudo apt-get install libgpgme11-dev libdevmapper-dev btrfs-tools go-md2man
$ cd $GOPATH/src/github.com/projectatomic/skopeo
$ make binary-local
$ sudo make install

#下载hello-world的image
$ skopeo copy docker://hello-world oci:hello-world
$ tree hello-world/
hello-world/
├── blobs
│ └── sha256
│ ├── 636fcf0bc8246e08d2df4771dc764d35ea50428b8dfaa904773b0707cb4f6303
│ ├── 7520415ce76232cdd62ecc345cea5ea44f5b6b144dc62351f2cd2b08382532a3
│ └── 9b8e3ce88f3a2aaa478cfe613632f38d27be5eddaa002a719fa1bfa9ff4f7f63
├── oci-layout
└── refs
└── latest