Contenu connexe
Similaire à 高速にコンテナを起動できるイメージフォーマット (20)
Plus de Akihiro Suda (20)
高速にコンテナを起動できるイメージフォーマット
- 1. Copyright©2017 NTT Corp. All Rights Reserved.
⽇本電信電話(株)
ソフトウェアイノベーションセンタ
須⽥ 瑛⼤
<suda.akihiro@lab.ntt.co.jp>
⾼速にコンテナを起動できる
イメージフォーマット
BDI研究会 (2017/8/1)
スライド: https://www.slideshare.net/AkihiroSuda
- 2. 2
Copyright©2017 NTT Corp. All Rights Reserved.
• 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. 3
Copyright©2017 NTT Corp. All Rights Reserved.
• `docker pull` し終わる前に`docker run`可能になるような
イメージフォーマットを提案
• 例えば Docker公式のOpenJDKイメージは全体で672MBある
が7MB pullした時点でsh起動可能になる
• 88MBでJRE,137MBでJDK
• その他,重複除去などの利点もあり
• OCI標準仕様との互換性を重視
お話しする内容
- 4. 4
Copyright©2017 NTT Corp. All Rights Reserved.
• Dockerとは
• Docker・OCIイメージの構成・問題
• 提案するイメージフォーマット
• 今後の技術的・コミュニティ的な取り組み⽅針
• デモ (時間があれば)
アウトライン
- 5. 5
Copyright©2017 NTT Corp. All Rights Reserved.
Dockerとは
• いわゆるコンテナ型仮想化基盤
• 仮想マシンより軽い
• イメージの作成・共有が簡単
• 昔のjailなどとの⼤きな違い
• 分散実⾏にも対応
• 標準: Swarm-mode / 3rd party: Kubernetes など
FROM ubuntu:17.04
RUN apt-get install foobar
COPY foobar.conf /etc
Dockerfileをコミットする
イメージがビルドされる
クラスタにデプロイできる
- 6. 6
Copyright©2017 NTT Corp. All Rights Reserved.
• 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
RUN apt-get install foobar
COPY foobar.conf /etc
mount –t overlay –o lowerdir=0,upperdir=1 ..
mount –t overlay –o lowerdir=1,upperdir=2 ..
- 7. 7
Copyright©2017 NTT Corp. All Rights Reserved.
• DockerのCoWレイヤは,AUFSレイヤを固めたtarファイルとしてイメー
ジ化される
• 実際のCoWファイルシステムがOverlayFSでもDeviceMapperでも,AUFSレイヤー
のtarとして表現される
• QCOW2など,ハイパーバイザ⽤のブロックレベルのCoW技術とは対照的
Docker・OCIイメージの構成
後で説明します
TAR
TAR
FROM ubuntu:17.04
RUN apt-get install foobar
COPY foobar.conf /etc
mount –t overlay –o lowerdir=0,upperdir=1 ..
mount –t overlay –o lowerdir=1,upperdir=2 ..
ベースレイヤは普通のtar
• 追加・変更されたファイル
• 削除されたファイルの情報
(whiteoutファイル)
TAR
/bin/bash
/bin/ls ...
/usr/bin/foobar
/usr/lib/libfoobar.so ...
/etc/foobar.conf
- 8. 8
Copyright©2017 NTT Corp. All Rights Reserved.
• TARファイルや,環境変数のJSONなどが,merkle tree構造を持つblob
ストアに格納される
• ⼀般にDocker Registryを⽤いて配信する.(バックエンドはS3やSwiftなど)
Docker・OCIイメージの構成
{
"schemaVersion": 2,
"manifests": [
{
"mediaType": "application/vnd.oci.image.manifest.v1+json",
"size": 7143,
"digest":
"sha256:e692418e4cbaf90ca69d05a66403747baa33ee08806650b51fab815ad7fc331f"
}
}
/index.json
/blobs/sha256/e692418e...
... (次スライド)
JSON
JSON
- 9. 9
Copyright©2017 NTT Corp. All Rights Reserved.
/blobs/sha256/e692418e...
{
"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"
},
{
"mediaType": "application/vnd.oci.image.layer.v1.tar+gzip",
"size": 1073741824,
"digest": "sha256:3c3a4604a545cdc127456d94e421cd355bca5b528f4a9c1905b15da2eb4a4c6b"
},
{
"mediaType": "application/vnd.oci.image.layer.v1.tar+gzip",
"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. 10
Copyright©2017 NTT Corp. All Rights Reserved.
• merkle tree構造を持っているので,manifestのSHA256値を指定すれば,
確実に環境を再現できる
(`docker pull foobar@sha256:e692418e..`)
Docker・OCIイメージの構成
/index.json
/blobs/sha256/e692418e...
/blobs/sha256/b5b2b2c5...
/blobs/sha256/61be55a8...
/blobs/sha256/3c3a4604...
/blobs/sha256/ec4b8955...
Index
Manifest
環境変数などのconfig
AUFSレイヤのtar群
merkle tree
- 11. 11
Copyright©2017 NTT Corp. All Rights Reserved.
• 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. 12
Copyright©2017 NTT Corp. All Rights Reserved.
• tar = Tape ARchiverが現れたのは1979年 (UNIX 7th Edition)
• 磁気テープ前提のフォーマットのため,本来はDocker・OCIのユースケース
に合っていない
Docker・OCIイメージの問題
1970年代のUNIXがターゲットとしていた
PDP-11 ミニコンピュータ &
磁気テープドライブ
https://en.wikipedia.org/wiki/PDP-11
- 13. 13
Copyright©2017 NTT Corp. All Rights Reserved.
• tar内のファイルの⼀覧がわからない
⇒テープ全体を読み終わるまでmountできない
• ファイルがどのオフセットにあるかわからない
(tarとは別に索引を作成したとしても,
tarがgzipなどで圧縮されていると,
どのみちseekできない)
問題1: 「テープ」全体を⾛査しないとメタデータを取得できない
メタデータ0
ファイル0
メタデータ1
ファイル2
メタデータ{n-1}
ファイル{n-1}
終端 zero (1024B)
...
ファイル名や
パーミッションなど
ファイル内容
- 14. 14
Copyright©2017 NTT Corp. All Rights Reserved.
問題1: 「テープ」全体を⾛査しないとメタデータを取得できない
この問題が解決できれば,メタデータだけpullした時点でmount(2)しておき,
ファイル本体はread(2)が発⽣した時点でlazyにpullできるようになる!
• 巨⼤なコンテナイメージを多数のノードに配信する場合,起動時間短縮・ネッ
トワーク負荷軽減できて嬉しい
ユースケース
• ⼤量のHTMLや画像ファイルを含むWebアプリケーション
• 様々なビッグデータとコードとをひとまとめにしたイメージ
• 論⽂を`docker run foo@sha256:deadbeef..` 1発で確実に再現できる世界
になると嬉しい
• 巨⼤なOS (GNOME・KDE⼊りの仮想デスクトップ環境や,Windowsなど)
• 巨⼤な⾔語ランタイム (Java,.NETなど)
• 複数のソフトウェアを結合試験する環境 など
- 15. 15
Copyright©2017 NTT Corp. All Rights Reserved.
• 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
RUN apt-get install foo
FROM ubuntu:17.04
RUN echo … > /etc/apt/source.list
RUN apt-get install foo
同じファイルを多数含んでいるが別物
- 16. 16
Copyright©2017 NTT Corp. All Rights Reserved.
• 巨⼤なtarレイヤのblobは,複数のrangeに分けて,複数のコネクション
を使って並列にpullしたい
• 複数のサーバを利⽤できる場合,短時間でのpull完了が⾒込まれる
• しかし任意のプロトコルで可能なわけではない
• HTTP/1.1 Range Requestsは RFC7233 にてOPTIONALとされている
問題3: ⼀般に,単⼀レイヤを分割して並列にpullできない
Range 0-1023 Range 1024-2047
- 17. 17
Copyright©2017 NTT Corp. All Rights Reserved.
1. 「テープ」全体を⾛査しないとメタデータを取得できない
2. 重複除去できない
3. ⼀般に,単⼀レイヤを分割して並列にpullできない
Docker・OCIイメージの問題 まとめ
- 19. 19
Copyright©2017 NTT Corp. All Rights Reserved.
• 単⼀の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}
ファイル{n-1}
終端 zero (1024B)
...
メタデータ0 ファイル0
メタデータ1
ファイル2
メタデータ{n-1} ファイル{n-1}
...
TAR
continuity ファイル名,パーミッション,
SHA256ダイジェストなど
content-addressable
- 20. 20
Copyright©2017 NTT Corp. All Rights Reserved.
• メタデータは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. 21
Copyright©2017 NTT Corp. All Rights Reserved.
• 単⼀の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. 22
Copyright©2017 NTT Corp. All Rights Reserved.
• 普通のOCIのtarレイヤに,提案フォーマットのレイヤを重ね合わせること
ができるので,⽋点を補い合うことができる
• 細かい⼤量のファイルは普通のtarにまとめるほうが,I/Oが1回で済むし,圧縮率向上
も期待できるので,速い場合もある
OCIイメージとの互換性を重視
{
...
"layers": [
{
"mediaType": "application/vnd.oci.image.layer.v1.tar+gzip",
"size": 33554432,
"digest": "sha256:e692..."
},
{
"mediaType": "application/vnd.continuity.layer.v0+pb",
"size": 16724,
"digest": "sha256:a18b..."
}
]
}
TAR
continuity
頻繁に使うファイルや,
細かいファイルは
普通のOCIのレイヤ
(pullし終わるまでコンテナ
を起動できない)
かさばるファイルは提案フォーマットのレイヤ
(lazyにpullできるが細かいファイルに不向き)
- 23. 23
Copyright©2017 NTT Corp. All Rights Reserved.
問題1.「テープ」全体を⾛査しないとメタデータを取得できない
⇒ continuityのblobだけpullすればメタデータを取得できる.
ファイル本体をpullする前にmount・コンテナ起動可能.
問題2. 重複除去できない
⇒ ファイルを細かいblobにばらしたので,同じファイルを含むレイヤは⾃
ずと重複除去される
問題3. ⼀般に,単⼀レイヤを分割して並列にpullできない
⇒ ファイルを細かいblobにばらしたので,並列にpullできる
Docker・OCIイメージの問題を解決できる
- 24. 24
Copyright©2017 NTT Corp. All Rights Reserved.
1. blob数の肥⼤化
• イメージをファイルシステム上に配置する場合,/blobs/sha256 ディレクトリに⼤
量のファイルが出来るため,readdir(3) が遅くなりがち
• /blobs/sha256/deadbeef..を/blobs/sha256/de/deadbeef..のように"sharding"する
テクニックは不可 (OCIとの互換性のため)
2. RPCオーバヘッド増⼤
• 細かいファイルは単⼀のtarにまとめてpullするほうがRPCが少なくて済む
3. イメージによっては圧縮率低下
• 似たようなファイルを多数含むレイヤは,従来通り,単⼀のtarにまとめると⾼い圧
縮率が期待される
ただし,前述の通り,従来のOCIレイヤとの重ね合わせでカバー可能
提案フォーマットの⽋点
- 25. 25
Copyright©2017 NTT Corp. All Rights Reserved.
没案: 外部ストアを併⽤する
⇒特定のプロトコルに依存するし,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. 26
Copyright©2017 NTT Corp. All Rights Reserved.
没案2: tarを先頭からseekしていけばよいのではないか?
⇒没
• 圧縮されたtarではseek不可能
• ⾮圧縮tarでもプロトコルによってはseekできない
• メタデータ全体をとるためのリクエストが多発
なぜ他の⽅法にしないか
メタデータ0
ファイル0
メタデータ1
ファイル2
メタデータ{n-1}
ファイル{n-1}
終端 zero (1024B)
...
ファイル本体を読み⾶ばしてseekし
メタデータだけ先に集める?
TAR
- 27. 27
Copyright©2017 NTT Corp. All Rights Reserved.
没案3: tarの代わりにzip(など)にすればよいのではないか?
⇒プロトコルによってはseekできないし,zipはメタデータのサポートが弱
いので没
なぜ他の⽅法にしないか
ZIP
予備メタデータ0
圧縮済ファイル0
予備メタデータ1
圧縮済ファイル2
予備メタデータ{n-1}
圧縮済ファイル{n-1}
...
フッタ
メタデータ0
メタデータ1
...
メタデータ{n-1}
メタデータだけまとめて先にpullできる?
- 29. 29
Copyright©2017 NTT Corp. All Rights Reserved.
• 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. 30
Copyright©2017 NTT Corp. All Rights Reserved.
評価に⽤いたイメージ
イメージ 説明 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. 31
Copyright©2017 NTT Corp. All Rights Reserved.
• 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)
• マウント: 34.5MB ( 2 blobs)
• `sh`: 累計36.7MB ( 8 blobs)
• `startkde`: 累計742.7MB (4,267 blobs)
• `firefox`: 累計866.6MB (4,506 blobs)
※各コマンドは続けて起動
評価: コンテナ起動に必要なblob量 (無圧縮)
1/5
1/5 以下
- 32. 32
Copyright©2017 NTT Corp. All Rights Reserved.
• kaggle/python (8.3GB + 38.2MB)
• マウント: 38.2MB ( 2 blobs)
• `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. 33
Copyright©2017 NTT Corp. All Rights Reserved.
評価: 圧縮率
イメージ 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. 34
Copyright©2017 NTT Corp. All Rights Reserved.
評価: 重複除去
kdeneon/all
(4.8GB)
kaggle/python
(8.3GB)
75.4MB の重複を除去できる
(互いに全然関係なさそうなイメージだが,
Debian系に共通のファイルがあるため重複blobがある)
- 35. 35
Copyright©2017 NTT Corp. All Rights Reserved.
評価: 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. 36
Copyright©2017 NTT Corp. All Rights Reserved.
評価: FUSEのオーバヘッド
0.1
1
10
100
1回⽬ 2回⽬ 3回⽬ 4回⽬ 5回⽬ 6回⽬ 7回⽬ 8回⽬ 9回⽬ 10回⽬
openjdkの/usr以下をtarで固めるのに要する秒数
従来のDocker (overlay2) 提案フォーマットのFUSE(read-only)
提案⼿法ではコンテナ起動後,readが発⽣して初めてblobをpullする.
そのため初回データにはpullの時間を含む.
(今回はlocalhostがリモートなのでネットワークのオーバヘッドは含まない).
※従来Dockerの⽅は,イメージをpullしてからコンテナ起動するので
pullの時間は含んでいない.
- 37. 37
Copyright©2017 NTT Corp. All Rights Reserved.
評価: FUSEのオーバヘッド
0.1
1
10
100
1回⽬ 2回⽬ 3回⽬ 4回⽬ 5回⽬ 6回⽬ 7回⽬ 8回⽬ 9回⽬ 10回⽬
openjdkの/usr以下をtarで固めるのに要する秒数
従来のDocker (overlay2) 提案フォーマットのFUSE(read-only)
カーネルのキャッシュが効いて速くなる
実装上の何らかの理由で
カーネルのキャッシュが効いていない?
(read-onlyなので原理的には簡単なはず.楽観的.)
- 38. 38
Copyright©2017 NTT Corp. All Rights Reserved.
• PullのためのRPCの数が増えることのオーバヘッド
• プロトコルに依存する
• TODO: Docker Registry APIのクライアントを実装し評価する.
• 現在のPOCはローカルディレクトリをレジストリ代わりにしている.
評価: その他
- 40. 40
Copyright©2017 NTT Corp. All Rights Reserved.
• ファイルより細かい粒度への対応
• ⼤きいファイルはchunk毎にSHA256ダイジェストを計算し,continuityとはまた別
のフォーマットとして保存しておけばよい (continuity#85)
• コンテナ起動時にすぐ必要となりそうなファイルを検出し,予め1つのtar
にまとめておく
• pushする前に1回コンテナを起動し,FUSEの呼び出しをトレースしておけばよい
今後の技術的な⽅針
- 41. 41
Copyright©2017 NTT Corp. All Rights Reserved.
• 現在,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の拡張機能として簡単に使えるようにする)
- 43. 43
Copyright©2017 NTT Corp. All Rights Reserved.
• `docker pull` し終わる前に`docker run`可能になるような
イメージフォーマットを提案
• https://github.com/AkihiroSuda/filegrain
• 例えば Docker公式のOpenJDKイメージは全体で672MBある
が7MB pullした時点でsh起動可能になる
• 88MBでJRE,137MBでJDK
• その他,重複除去などの利点もあり
• OCI標準仕様との互換性を重視
まとめ