高速にコンテナを起動できるイメージフォーマット

Copyright©2017 NTT Corp. All Rights Reserved.
⽇本電信電話(株)
ソフトウェアイノベーションセンタ
須⽥瑛⼤
<suda.akihiro@lab.ntt.co.jp>
⾼速にコンテナを起動できる
イメージフォーマット
BDI研究会 (2017/8/1)
スライド: https://www.slideshare.net/AkihiroSuda

2
• GitHub: @AkihiroSuda / Twitter: @_AkihiroSuda_
• コンテナ関連OSSのメンテナ(所謂コミッタ)
• Docker Moby Core メンテナ
• BuildKit イニシャルメンテナ (github.com/moby/buildkit)
• 次世代 `docker build` (DockerfileをDAG化し並⾏実⾏)
• またの機会にこちらについても詳しく..
⾃⼰紹介
2017年4⽉，DockerプロジェクトはMobyプロジェクトに移⾏した．
Mobyプロジェクトの成果物を元として，Docker製品が開発されている．
: ≒ :
RHEL Fedora

3
• `docker pull` し終わる前に`docker run`可能になるような
イメージフォーマットを提案
• 例えば Docker公式のOpenJDKイメージは全体で672MBある
が7MB pullした時点でsh起動可能になる
• 88MBでJRE，137MBでJDK
• その他，重複除去などの利点もあり
• OCI標準仕様との互換性を重視
お話しする内容

4
• Dockerとは
• Docker・OCIイメージの構成・問題
• 提案するイメージフォーマット
• 今後の技術的・コミュニティ的な取り組み⽅針
• デモ (時間があれば)
アウトライン

5
Dockerとは
• いわゆるコンテナ型仮想化基盤
• 仮想マシンより軽い
• イメージの作成・共有が簡単
• 昔のjailなどとの⼤きな違い
• 分散実⾏にも対応
• 標準: Swarm-mode / 3rd party: Kubernetes など
FROM ubuntu:17.04
RUN apt-get install foobar
COPY foobar.conf /etc
Dockerfileをコミットする
イメージがビルドされる
クラスタにデプロイできる

6
• Linuxカーネルが備えるcgroups・namespaceと，Copy-on-Write
(CoW)ファイルシステムとを組み合わせて実装されている
• AUFS, OverlayFS, BtrFS, ZFSに対応．DeviceMapperでのCoWにも対応．
• 対応しているディストリビューションや，安定性などの特性が違う
• Dockerfileの1⾏毎にCoWレイヤーが⽣成される
• イメージサイズは⼩さく抑えるのが鉄則 (VMとは使い勝⼿が違う)
• ⼩さいイメージを多数組み合わせて，マイクロサービス化する
• とは⾔っても，現実にはなかなか⼩さくしにくいものである
• ⼩さくしやすくする試みとしては，OracleのMicrocontainer (Smith)などが最近出てきている
Dockerとは
FROM ubuntu:17.04
mount –t overlay –o lowerdir=0,upperdir=1 ..

7
• DockerのCoWレイヤは，AUFSレイヤを固めたtarファイルとしてイメー
ジ化される
• 実際のCoWファイルシステムがOverlayFSでもDeviceMapperでも，AUFSレイヤー
のtarとして表現される
• QCOW2など，ハイパーバイザ⽤のブロックレベルのCoW技術とは対照的
Docker・OCIイメージの構成
後で説明します
TAR
TAR
FROM ubuntu:17.04
ベースレイヤは普通のtar
• 追加・変更されたファイル
• 削除されたファイルの情報
(whiteoutファイル)
TAR
/bin/bash
/bin/ls ...
/usr/bin/foobar
/usr/lib/libfoobar.so ...
/etc/foobar.conf

8
• TARファイルや，環境変数のJSONなどが，merkle tree構造を持つblob
ストアに格納される
• ⼀般にDocker Registryを⽤いて配信する．(バックエンドはS3やSwiftなど)
{
"schemaVersion": 2,
"manifests": [
{
"mediaType": "application/vnd.oci.image.manifest.v1+json",
"size": 7143,
"digest":
"sha256:e692418e4cbaf90ca69d05a66403747baa33ee08806650b51fab815ad7fc331f"
}
}
/index.json
/blobs/sha256/e692418e...
... (次スライド)
JSON
JSON

9
{
"schemaVersion": 2,
"config": {
"mediaType": "application/vnd.oci.image.config.v1+json",
"size": 7023,
"digest": "sha256:b5b2b2c507a0944348e0303114d8d93aaaa081732b86451d9bce1f432a537bc7"
},
"layers": [
{
"mediaType": "application/vnd.oci.image.layer.v1.tar+gzip",
"size": 33554432,
"digest": "sha256:61be55a8e2f6b4e172338bddf184d6dbee29c98853e0a0485ecee7f27b9af0b4"
},
{
"size": 1073741824,
"digest": "sha256:3c3a4604a545cdc127456d94e421cd355bca5b528f4a9c1905b15da2eb4a4c6b"
},
{
"size": 73109,
"digest": "sha256:ec4b8955958665577945c89419d1af06b5f7636b4ac3da7f12184802ad867736"
}
]
}
/blobs/sha256/b5b2b2c5...
(環境変数などのJSON)
/blobs/sha256/61be55a8...
(ベースレイヤのtar)
/blobs/sha256/3c3a4604...
(差分レイヤのtar)
/blobs/sha256/ec4b8955...
(更なる差分レイヤのtar)
TAR
TAR
TAR
JSON
JSON

10
• merkle tree構造を持っているので，manifestのSHA256値を指定すれば，
確実に環境を再現できる
(`docker pull foobar@sha256:e692418e..`)
/index.json
/blobs/sha256/b5b2b2c5...
/blobs/sha256/61be55a8...
/blobs/sha256/3c3a4604...
/blobs/sha256/ec4b8955...
Index
Manifest
環境変数などのconfig
AUFSレイヤのtar群
merkle tree

11
• 2017年7⽉，Linux Foundation傘下のOpen Containers Initiative
によりOCIイメージ仕様の策定完了
• CoreOS陣営が提案していたappc・ACIもOCIに合流した
• データ構造はDockerイメージと類似しており，⾼い互換性を持つが，
Docker Registry HTTP APIに依存しなくなった．
HTTP, NFS, IPFSなど，ディレクトリ的なセマンティックを持つ任意のプ
ロトコルで配信可能．
• 個⼈的にはIPFSなどP2Pを⽤いたイメージ配信に期待
• Dockerでも，近々正式に実装予定．
• ※混同に注意: Dockerfileの構⽂・命令が標準化されたわけではない
OCIイメージ≒Dockerイメージ

12
• tar = Tape ARchiverが現れたのは1979年 (UNIX 7th Edition)
• 磁気テープ前提のフォーマットのため，本来はDocker・OCIのユースケース
に合っていない
Docker・OCIイメージの問題
1970年代のUNIXがターゲットとしていた
PDP-11 ミニコンピュータ &
磁気テープドライブ
https://en.wikipedia.org/wiki/PDP-11

13
• tar内のファイルの⼀覧がわからない
⇒テープ全体を読み終わるまでmountできない
• ファイルがどのオフセットにあるかわからない
(tarとは別に索引を作成したとしても，
tarがgzipなどで圧縮されていると，
どのみちseekできない)
問題1: 「テープ」全体を⾛査しないとメタデータを取得できない
メタデータ0
ファイル0
メタデータ1
ファイル2
メタデータ{n-1}
ファイル{n-1}
終端 zero (1024B)
...
ファイル名や
パーミッションなど
ファイル内容

14
問題1: 「テープ」全体を⾛査しないとメタデータを取得できない
この問題が解決できれば，メタデータだけpullした時点でmount(2)しておき，
ファイル本体はread(2)が発⽣した時点でlazyにpullできるようになる!
• 巨⼤なコンテナイメージを多数のノードに配信する場合，起動時間短縮・ネッ
トワーク負荷軽減できて嬉しい
ユースケース
• ⼤量のHTMLや画像ファイルを含むWebアプリケーション
• 様々なビッグデータとコードとをひとまとめにしたイメージ
• 論⽂を`docker run foo@sha256:deadbeef..` 1発で確実に再現できる世界
になると嬉しい
• 巨⼤なOS (GNOME・KDE⼊りの仮想デスクトップ環境や，Windowsなど)
• 巨⼤な⾔語ランタイム (Java，.NETなど)
• 複数のソフトウェアを結合試験する環境など

15
• 1つのレジストリで，複数の似たようなイメージを配信することを考える
• バージョン違い
• アーキテクチャ違い
• 設定違いなど
• 同じファイルを多数含むtarであっても，別々のblobになるため，ストレ
ージが無駄になる
問題2: blobの重複を除去できない
FROM ubuntu:17.04
RUN apt-get install foo
FROM ubuntu:17.04
RUN apt-get install foo bar
FROM debian:9
FROM ubuntu:17.04
RUN echo … > /etc/apt/source.list
同じファイルを多数含んでいるが別物

16
• 巨⼤なtarレイヤのblobは，複数のrangeに分けて，複数のコネクション
を使って並列にpullしたい
• 複数のサーバを利⽤できる場合，短時間でのpull完了が⾒込まれる
• しかし任意のプロトコルで可能なわけではない
• HTTP/1.1 Range Requestsは RFC7233 にてOPTIONALとされている
問題3: ⼀般に，単⼀レイヤを分割して並列にpullできない
Range 0-1023 Range 1024-2047

17
1. 「テープ」全体を⾛査しないとメタデータを取得できない
2. 重複除去できない
3. ⼀般に，単⼀レイヤを分割して並列にpullできない
Docker・OCIイメージの問題まとめ

18
提案するイメージフォーマット
FILEgrain(仮称) https://github.com/AkihiroSuda/filegrain

19
• 単⼀のtar blobを，ファイル毎に別個のblobに崩す
• 各ファイルのSHA256ダイジェストをメタデータに記載しcontent-addressableにする
• メタデータのblobさえpullすれば，getdents(2)やstat(2)できるので，
イメージ全体をpullせず，mount(2)・コンテナ起動可能
• read(2)が発⽣した段階で初めて，lazyにpullすればよい
提案するイメージフォーマットの概略
メタデータ0
ファイル0
メタデータ1
ファイル2
ファイル{n-1}
終端 zero (1024B)
...
メタデータ0 ファイル0
メタデータ1
ファイル2
メタデータ{n-1} ファイル{n-1}
...
TAR
continuity ファイル名，パーミッション，
SHA256ダイジェストなど
content-addressable

20
• メタデータはcontinuityで表現する
• continuity.. containerdコミュニティで提案されている，ファイルシステ
ムメタデータ記述フォーマット
(https://github.com/containerd/continuity)
• ファイル名，パーミッション，xattr(7)，ダイジェスト値などをProtocolBuffers形式で
シリアライズする
• 次世代containerd(下位ランタイム)のテストで使われているほか，
Docker・Mobyでもイメージ検証に使う案がある (moby-core#32153)
• 類似フォーマットにBSDのmtree(8)がある
• 将来的にcontainerdに統合したいので，containerdコミュニティ系のcontinuityにした
• containerdコミュニティについては最後の⽅のスライドで説明
(Docker・Kubernetes共通の次世代ランタイム)
メタデータのフォーマット

21
• 単⼀のOCIイメージ中に，普通のOCIマニフェストと，提案フォーマットのマ
ニフェストの両⽅を格納できる
• ⇒提案フォーマットに対応・未対応のソフトウェアを容易に共存させることができる
OCIイメージとの互換性を重視
/index.json
/blobs/sha256/e692...
/blobs/sha256/b5b2... /blobs/sha256/61be...
/blobs/sha256/3c3a...
/blobs/sha256/ec4b...
Index
OCI Manifest
環境変数などのconfig (共通)
AUFSレイヤのtar群
/blobs/sha256/a8e3...
提案フォーマットのManifest
/blobs/sha256/de81...
continuity
/blobs/sha256/583f...
/blobs/sha256/3af1...
/blobs/sha256/5c2a...
/blobs/sha256/39c1...
/blobs/sha256/12ea... ばらされたファイル群(⼤量)
`docker pull foo:v1-filegrain` `docker pull foo:v1`
{"v1-filegrain": "sha256:a8e3..", "v1":"sha256:e692.."}

22
• 普通のOCIのtarレイヤに，提案フォーマットのレイヤを重ね合わせること
ができるので，⽋点を補い合うことができる
• 細かい⼤量のファイルは普通のtarにまとめるほうが，I/Oが1回で済むし，圧縮率向上
も期待できるので，速い場合もある
OCIイメージとの互換性を重視
{
...
"layers": [
{
"size": 33554432,
"digest": "sha256:e692..."
},
{
"mediaType": "application/vnd.continuity.layer.v0+pb",
"size": 16724,
"digest": "sha256:a18b..."
}
]
}
TAR
continuity
頻繁に使うファイルや，
細かいファイルは
普通のOCIのレイヤ
(pullし終わるまでコンテナ
を起動できない)
かさばるファイルは提案フォーマットのレイヤ
(lazyにpullできるが細かいファイルに不向き)

23
問題1.「テープ」全体を⾛査しないとメタデータを取得できない
⇒ continuityのblobだけpullすればメタデータを取得できる．
ファイル本体をpullする前にmount・コンテナ起動可能．
問題2. 重複除去できない
⇒ ファイルを細かいblobにばらしたので，同じファイルを含むレイヤは⾃
ずと重複除去される
問題3. ⼀般に，単⼀レイヤを分割して並列にpullできない
⇒ ファイルを細かいblobにばらしたので，並列にpullできる
Docker・OCIイメージの問題を解決できる

24
1. blob数の肥⼤化
• イメージをファイルシステム上に配置する場合，/blobs/sha256 ディレクトリに⼤
量のファイルが出来るため，readdir(3) が遅くなりがち
• /blobs/sha256/deadbeef..を/blobs/sha256/de/deadbeef..のように"sharding"する
テクニックは不可 (OCIとの互換性のため)
2. RPCオーバヘッド増⼤
• 細かいファイルは単⼀のtarにまとめてpullするほうがRPCが少なくて済む
3. イメージによっては圧縮率低下
• 似たようなファイルを多数含むレイヤは，従来通り，単⼀のtarにまとめると⾼い圧
縮率が期待される
ただし，前述の通り，従来のOCIレイヤとの重ね合わせでカバー可能
提案フォーマットの⽋点

25
没案: 外部ストアを併⽤する
⇒特定のプロトコルに依存するし，OCIのmerkle treeを使えなくなること
があり，環境再現性・セキュリティ⾯での懸念があるため，没
なぜ他の⽅法にしないか
類似研究:
Harter, Tyler, et al. "Slacker: Fast Distribution with Lazy Docker Containers." FAST. 2016.
• NFS上のext4イメージをループバックマウントし，ブロック粒度でのlazy-pull，重複除去を実現
Lestaris, George. "Alternatives to layer-based image distribution: using CERN filesystem for
images." Container Camp UK. 2016.
Blomer, Jakob, et al. "A Novel Approach for Distributing and Managing Container Images:
Integrating CernVM File System and Mesos." MesosCon NA. 2016.
• CernVM-FSを⽤いて，ファイル粒度でのlazy-pull，重複除去を実現
• CernVM-FSもmerkle treeを持っているが，OCIのmerkle treeに接ぎ⽊するには⼀⼿間要りそう
IPFS(P2Pでcontent-addressableなファイルシステム)の使⽤も考えたが，特定プロトコルに依存したく
なかったので没
※提案フォーマットはHTTPでもNFSでもCernVM-FSでもIPFSでも，任意のプロトコルで配信可能

26
没案2: tarを先頭からseekしていけばよいのではないか?
⇒没
• 圧縮されたtarではseek不可能
• ⾮圧縮tarでもプロトコルによってはseekできない
• メタデータ全体をとるためのリクエストが多発
メタデータ0
ファイル0
メタデータ1
ファイル2
ファイル{n-1}
終端 zero (1024B)
...
ファイル本体を読み⾶ばしてseekし
メタデータだけ先に集める?
TAR

27
没案3: tarの代わりにzip(など)にすればよいのではないか?
⇒プロトコルによってはseekできないし，zipはメタデータのサポートが弱
いので没
ZIP
予備メタデータ0
圧縮済ファイル0
予備メタデータ1
圧縮済ファイル2
予備メタデータ{n-1}
圧縮済ファイル{n-1}
...
フッタ
メタデータ0
メタデータ1
...
メタデータだけまとめて先にpullできる?

28
評価

29
• read-onlyなFUSEファイルシステムとして実装
• 将来的にもread-onlyのままのつもり
• コンテナはVMとは違い，immutableにするのが鉄則．/tmp, /runとパーシステントボ
リューム以外への書き込みは⾏うべきではない．
• /tmpや/runは⼀般にtmpfsを別途マウントする
• パーシステントボリュームは，ホスト側のext4やXFSをbind-mountする
• 実際，OverlayFSやAUFSも書き込み操作のサポートは限定的
(https://github.com/AkihiroSuda/docker-issues)
• 1つのファイルに対してROなfdとRWなfdを両⽅openし，書き込むと，ROな⽅が意図しない
結果を返す．(yumなど実際のアプリケーションに影響するが，バグではなくoverlayの仕様)
• 今のところ，Dockerは任意にmountされたrootfsを使えないので，
Dockerそのものには統合できていない．runc (Docker, containerdの下
位ランタイム)を⽤いて評価した．
実装

30
評価に⽤いたイメージ
イメージ説明 rootfs
(tar+gzip展開後)
openjdk:8
sha256:5da842d59f76009fa27ffde06888ebd
560c7ad17607d7cd1e52fc0757c9a45fb
Debian 9.1, OpenJDK 8u141 671.7MB
kdeneon/all
sha256:e3e7f216a5f8f1fdcff4eab8807d7af
cd291c050099ab3e8a8355b7b28a19247
Ubuntu 16.04, KDE Plasma 5.10,
Firefox 54など
4.8GB
kaggle/python
sha256:335103c998aea22a5608c2eeca7dcf1
09e0828ed233b75f5098182c5b058fe98
Debian 8.5, 様々な機械学習フレー
ムワーク, NLTKデータセット(⾃然
⾔語関連)など
8.3GB
※詳細な再現⼿順は https://github.com/AkihiroSuda/filegrain/issues/17 に掲載．

31
• openjdk:8 (総blob容量 = 671.7MB + メタ 5.4MB)
• マウント: 5.4MB ( 2 blobs)
• イメージ本体のblobではなく，メタデータ(manifestとcontinuity)の読み込み
• `sh`: 累計 7.3MB ( 8 blobs)
• `java –version`: 累計 88.2MB ( 30 blobs)
• `javac HelloWorld.java`: 累計137.3MB ( 50 blobs)
• kdeneon/all (4.8GB + 34.5MB)
• `sh`: 累計36.7MB ( 8 blobs)
• `startkde`: 累計742.7MB (4,267 blobs)
• `firefox`: 累計866.6MB (4,506 blobs)
※各コマンドは続けて起動
評価: コンテナ起動に必要なblob量 (無圧縮)
1/5
1/5 以下

32
• kaggle/python (8.3GB + 38.2MB)
• `sh`: 累計 40.1MB ( 8 blobs)
• `ipython –c ʻecho(“hello”)ʼ`: 累計 75.4MB (1033 blobs)
• `ipython –c ʻimport nltkʼ`: 累計352.0MiB (2799 blobs)
評価: コンテナ起動に必要なblob量 (無圧縮)
1/24 以下

33
評価: 圧縮率
イメージ rootfs 従来のtarをまと
めてgzip -9
提案フォーマット
+各blobを個別
にgzip -9
openjdk:8 671.7MB 261.3MB 260.7MB
(-645,604B)
kdeneon/all 4.8GB 2.1GB 2.1GB
(-489,361B)
kaggle/python 8.3GB 3.6GB 3.6GB
(+4,345,701B)
今回試験したイメージでは圧縮率の違いは誤差の範囲
(似たようなblobが多いイメージでは圧縮率は悪くなりそう)

34
評価: 重複除去
kdeneon/all
(4.8GB)
kaggle/python
(8.3GB)
75.4MB の重複を除去できる
(互いに全然関係なさそうなイメージだが，
Debian系に共通のファイルがあるため重複blobがある)

35
評価: FUSEのオーバヘッド
0.1
1
10
100
1回⽬ 2回⽬ 3回⽬ 4回⽬ 5回⽬ 6回⽬ 7回⽬ 8回⽬ 9回⽬ 10回⽬
openjdkの/usr以下をtarで固めるのに要する秒数
従来のDocker (overlay2) 提案フォーマットのFUSE(read-only)
Docker 17.06 / Fedora 26 / 2 vCPUs, 2GB RAM, 2GB swap (VMware Fusion, MacBook Pro 2016)

36
0.1
1
10
100
1回⽬ 2回⽬ 3回⽬ 4回⽬ 5回⽬ 6回⽬ 7回⽬ 8回⽬ 9回⽬ 10回⽬
提案⼿法ではコンテナ起動後，readが発⽣して初めてblobをpullする．
そのため初回データにはpullの時間を含む．
(今回はlocalhostがリモートなのでネットワークのオーバヘッドは含まない).
※従来Dockerの⽅は，イメージをpullしてからコンテナ起動するので
pullの時間は含んでいない．

37
0.1
1
10
100
1回⽬ 2回⽬ 3回⽬ 4回⽬ 5回⽬ 6回⽬ 7回⽬ 8回⽬ 9回⽬ 10回⽬
カーネルのキャッシュが効いて速くなる
実装上の何らかの理由で
カーネルのキャッシュが効いていない?
(read-onlyなので原理的には簡単なはず．楽観的．)

38
• PullのためのRPCの数が増えることのオーバヘッド
• プロトコルに依存する
• TODO: Docker Registry APIのクライアントを実装し評価する．
• 現在のPOCはローカルディレクトリをレジストリ代わりにしている．
評価: その他

39
今後の⽅針

40
• ファイルより細かい粒度への対応
• ⼤きいファイルはchunk毎にSHA256ダイジェストを計算し，continuityとはまた別
のフォーマットとして保存しておけばよい (continuity#85)
• コンテナ起動時にすぐ必要となりそうなファイルを検出し，予め1つのtar
にまとめておく
• pushする前に1回コンテナを起動し，FUSEの呼び出しをトレースしておけばよい
今後の技術的な⽅針

41
• 現在，Dockerは多数の”LEGOブロック”へ分解・再編成されつつある最中
• ガバナンスの明確化
• 拡張モジュール開発の容易化
コミュニティ的な取り組み⽅針
Docker CLI
Moby Core (dockerd)
containerd
runc
BuildKit (buildd) SwarmKit (swarmd)
CLI (これだけはDocker社がコミット権独占)
各モジュールのAPIを統合
分散実⾏Dockerfile的なDAGを実⾏
cgroups, namespace
OCIイメージ・CoW FSなど
⾚枠内はKubernetesとも共通する (今後，Dockerの代わりのランタイムとして選択可能になる)
提案フォーマットをcontainerd周辺に導⼊することを⽬指す
(DockerやKubernetesの拡張機能として簡単に使えるようにする)

42
まとめ

43
• `docker pull` し終わる前に`docker run`可能になるような
イメージフォーマットを提案
• https://github.com/AkihiroSuda/filegrain
• 例えば Docker公式のOpenJDKイメージは全体で672MBある
が7MB pullした時点でsh起動可能になる
• 88MBでJRE，137MBでJDK
• その他，重複除去などの利点もあり
• OCI標準仕様との互換性を重視
まとめ

44
デモ (時間があれば)

高速にコンテナを起動できるイメージフォーマット

More Related Content

What's hot

Similar to 高速にコンテナを起動できるイメージフォーマット

More from Akihiro Suda

高速にコンテナを起動できるイメージフォーマット