Docker コンテナのレイヤー構造について

Docker コンテナのレイヤー構造をざっくりと理解する。その過程で Docker のイメージ構造(Image Manifest V 2, Schema 2)もながめる。

イメージ構造

Docker のイメージ構造は Image Manifest V 2, Schema 2 に定義されている。

イメージは主に 3 種類のファイルから構成されている。

manifest
- 後述する config や layers の位置が記載されたもの。
config
- コンテナ実行に必要な情報が記載されたファイル。例えばコンテナ実行時の Cmd は何、とか、WorkDir は何、とか、hostname は何、とか。
layer
- (tar.gz アーカイブされた)ファイル。レイヤーの実体っぽいもの。

Docker Registry HTTP API V2を利用し、各レイヤーのデータを取得して中身をのぞいてみる。なお、データ構造とイメージのファイル構造はあまり関係がないので、HTTP による取得方法はまあそういうもんかで流してください。

はじめに、先ほどのイメージを Dockerhub に push する。

# docker tag 42d7a98af75f kimullaa/sample:latest
# docker push kimullaa/sample:latest
# docker rmi -f $(docker images -aq)

manifest

manifest を取得してみる。config と layers のポインタになっているのが分かる。

# token=$(curl "https://auth.docker.io/token?service=registry.docker.io&scope=repository:kimullaa/sample:pull" | jq -r '.token')
# curl -s -H 'Accept: application/vnd.docker.distribution.manifest.v2+json' -H "Authorization: Bearer $token" "https://registry-1.docker.io/v2/kimullaa/sample/manifests/latest" | jq
{
  "schemaVersion": 2,
  "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
  "config": {
    "mediaType": "application/vnd.docker.container.image.v1+json",
    "size": 1849,
    "digest": "sha256:42d7a98af75fe404665d7c4fb12dca643c7246cdefab2f6124a7e5c6082b4505"
  },
  "layers": [
    {
      "mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
      "size": 2811969,
      "digest": "sha256:540db60ca9383eac9e418f78490994d0af424aab7bf6d0e47ac8ed4e2e9bcbba"
    },
    {
      "mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
      "size": 109,
      "digest": "sha256:c3f2e40648c0e80cf46a41c0d5af743b1528c02af35445ed4add23f7f69b7347"
    },
    {
      "mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
      "size": 97,
      "digest": "sha256:4ea489072183231ead86738894a2977745afd7103169f9c328417087062b6dfd"
    }
  ]
}

config

config を取得してみる。こちらも実行時に必要な情報が入ってそうなことが分かる。なお、このファイルの構造は moby/moby spec/v1.2.md で定義されているっぽい。

# token=$(curl "https://auth.docker.io/token?service=registry.docker.io&scope=repository:kimullaa/sample:pull" | jq -r '.token')
# curl -s -L -H 'Accept: application/vnd.docker.container.image.v1+json' -H "Authorization: Bearer $token" "https://registry-1.docker.io/v2/kimullaa/sample/blobs/sha256:42d7a98af75fe404665d7c4fb12dca643c7246cd
efab2f6124a7e5c6082b4505" | jq
{
  "architecture": "amd64",
  "config": {
    "Hostname": "",
    "Domainname": "",
    "User": "",
    "AttachStdin": false,
    "AttachStdout": false,
    "AttachStderr": false,
    "Tty": false,
    "OpenStdin": false,
    "StdinOnce": false,
    "Env": [
      "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
    ],
    "Cmd": [
      "/bin/sh"
    ],
    "Image": "sha256:6ad08ed3b839dd3a96463078a6397f639c6bd07809a2edcd39ca121f696fdf87",
    "Volumes": null,
    "WorkingDir": "",
    "Entrypoint": null,
    "OnBuild": null,
    "Labels": null
  },
  "container": "37ed66a952a20943294885caecbbfd357c1980f00de5b057d78e93b654dc6d4d",
  "container_config": {
    "Hostname": "",
    "Domainname": "",
    "User": "",
    "AttachStdin": false,
    "AttachStdout": false,
    "AttachStderr": false,
    "Tty": false,
    "OpenStdin": false,
    "StdinOnce": false,
    "Env": [
      "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
    ],
    "Cmd": [
      "/bin/sh",
      "-c",
      "touch banana.txt /"
    ],
    "Image": "sha256:6ad08ed3b839dd3a96463078a6397f639c6bd07809a2edcd39ca121f696fdf87",
    "Volumes": null,
    "WorkingDir": "",
    "Entrypoint": null,
    "OnBuild": null,
    "Labels": null
  },
  "created": "2021-06-07T01:07:31.224378431Z",
  "docker_version": "20.10.2",
  "history": [
    {
      "created": "2021-04-14T19:19:39.267885491Z",
      "created_by": "/bin/sh -c #(nop) ADD file:8ec69d882e7f29f0652d537557160e638168550f738d0d49f90a7ef96bf31787 in / "
    },
    {
      "created": "2021-04-14T19:19:39.643236135Z",
      "created_by": "/bin/sh -c #(nop)  CMD [\"/bin/sh\"]",
      "empty_layer": true
    },
    {
      "created": "2021-06-07T01:07:28.009923628Z",
      "created_by": "/bin/sh -c #(nop) COPY file:4610a3197c00b0b8e77052a7da9ec139f7ea4c2bc5729dc4216ae30c25d0a50c in / "
    },
    {
      "created": "2021-06-07T01:07:31.224378431Z",
      "created_by": "/bin/sh -c touch banana.txt /"
    }
  ],
  "os": "linux",
  "rootfs": {
    "type": "layers",
    "diff_ids": [
      "sha256:b2d5eeeaba3a22b9b8aa97261957974a6bd65274ebd43e1d81d0a7b8b752b116",
      "sha256:641288b48190f3b6cab0f777036c0b8346b6abd2c7ff8bf71b4b7c3cebfd5a11",
      "sha256:a51ef6f18be9d4eff3c77e16f184e348cd61a637b6bddc2c2e9f25540c4989fe"
    ]
  }
}

ちなみに、config の情報をもとにコンテナの実行に必要なファイル(oci runtime の config.json)を作成するが、実装上は OCI の出してる image-spec の構造体に変換されていた(というか OCI の application/vnd.oci.image.config.v1+json と application/vnd.docker.container.image.v1+json が同一の処理になっていた)。
参考 containerd/containerd WithImageConfigArgs()

OCI の image-spec は、Image Manifest V 2, Schema 2をベースに策定されたようなので、このファイルについてはそのまま採用されたものと思われる。
参考 OCI Image Support Comes to Open Source Docker Registry

layer

layer を取得してみる。tar.gz を解凍すると、それぞれのレイヤーに必要なファイルが突っ込まれていることが分かる。これらの各レイヤーのイメージをユニオンファイルシステムで重ねて、ファイルシステムを実現しているっぽい(なお tar を単純に解凍するだけではなく、ストレージドライバがもろもろ処理をするっぽい。例えばファイルの削除を表す whiteout file を tar.gz 内の .wh. ごとに作成したりする)。

# token=$(curl "https://auth.docker.io/token?service=registry.docker.io&scope=repository:kimullaa/sample:pull" | jq -r '.token')
# curl -L -H 'Accept: application/vnd.docker.image.rootfs.diff.tar.gzip' -H "Authorization: Bearer $token" "https://registry-1.docker.io/v2/kimullaa/sample/blobs/sha256:540db60ca9383eac9e418f78490994d0af424aab7bf6d0e47ac8ed4e2e9bcbba" -o layer1.tar.gz
# curl -L -H 'Accept: application/vnd.docker.image.rootfs.diff.tar.gzip' -H "Authorization: Bearer $token" "https://registry-1.docker.io/v2/kimullaa/sample/blobs/sha256:c3f2e40648c0e80cf46a41c0d5af743b1528c02af35445ed4add23f7f69b7347" -o layer2.tar.gz
# curl -L -H 'Accept: application/vnd.docker.image.rootfs.diff.tar.gzip' -H "Authorization: Bearer $token" "https://registry-1.docker.io/v2/kimullaa/sample/blobs/sha256:4ea489072183231ead86738894a2977745afd7103169f9c328417087062b6dfd" -o layer3.tar.gz

# mkdir layer{1..3}
# tar -xf layer1.tar.gz -C layer1
# tar -xf layer2.tar.gz -C layer2
# tar -xf layer3.tar.gz -C layer3

# ls layer1
bin  dev  etc  home  lib  media  mnt  opt  proc  root  run  sbin  srv  sys  tmp  usr  var

# cat layer1/etc/os-release
NAME="Alpine Linux"
ID=alpine
VERSION_ID=3.13.5
PRETTY_NAME="Alpine Linux v3.13"
HOME_URL="https://alpinelinux.org/"
BUG_REPORT_URL="https://bugs.alpinelinux.org/"

# ls layer{2..3}
layer2:
apple.txt

layer3:
banana.txt

ちなみに URL で指定した sha256:xxx という値は、ファイルを検証可能にするための仕組みらしい。
参考 Digest Parameter

URL で指定した sha256:xxx と、ダウンロードしたファイルの sha256 が一致すれば、問題なくダウンロードできたと判断できる。試しにダウンロードしたファイルに sha256sum を実行すると、URL で指定した値と一致した。

# sha256sum layer1.tar.gz
540db60ca9383eac9e418f78490994d0af424aab7bf6d0e47ac8ed4e2e9bcbba  layer1.tar.gz

# sha256sum layer2.tar.gz
c3f2e40648c0e80cf46a41c0d5af743b1528c02af35445ed4add23f7f69b7347  layer2.tar.gz

# sha256sum layer3.tar.gz
4ea489072183231ead86738894a2977745afd7103169f9c328417087062b6dfd  layer3.tar.gz

ちなみにx2、レイヤーのダウンロードを sha256 で指定するということは、レイヤーに含まれるファイルが一緒なら、異なるイメージだとしても同じ sha256 になり、同じ URL からダウンロードされる。ということは docker registry が持っておく tar.gz は 1 つで済むので、すごいディスクイメージの節約になりそう。

ちなみにx3、FROM で指定した alpine:latest という情報はコンテナのレイヤー構造に含まれていないので、ということは、FROM で指定したベースイメージが更新されても、docker build しないと反映されなさそう。ビルドを自動化する作り込みが必要な様子。
参考 Dockerfile をベースイメージの更新に自動で追従させる - 詩と創作・思索のひろば
参考 Docker Hubの自作イメージを自動アップデートしてリリースする - Qiita

Docker コンテナのレイヤー構造について

概要

イメージ構造

manifest

config

layer