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

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
デモ (時間があれば)

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

Recommended

More Related Content

What's hot

What's hot (20)

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

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

More from Akihiro Suda

More from Akihiro Suda (20)

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