狠狠撸

Copyright?2019 NTT Corp. All Rights Reserved.
OCIv2？！
軽量高速なイケてる次世代イメージ仕様の
最新動向を抑えよう！
2019/7/22(月)
日本電信電話株式会社
ソフトウェアイノベーションセンタ
徳永航平
CloudNative Days Tokyo 2019 [1B4]

2Copyright?2019 NTT Corp. All Rights Reserved.
自己紹介
名前徳永航平
所属 NTT ソフトウェアイノベーションセンタ
興味コンテナランタイム、イメージ

今のランタイム?イメージまわりの様子
目次
1.
2. これからのランタイム?イメージまわりの動向
3. まとめ

コンテナまわりの標準仕様
コンテナイメージの標準
仕様。コンテナに含める
ファイルのレイヤや、メ
タデータの仕様およびそ
のファイルを定義
コンテナのnetwork NS
で作成するインタフェー
ス仕様、それを行うCNI
プラグインの仕様と入出
力パラメータ定義
OCI.” OCI Image Format Specification” https://github.com/opencontainers/image-spec ; OCI.” Open Container Initiative
Runtime Specification”. https://github.com/opencontainers/runtime-spec ; OCI. “Open Container Initiative Distribution
Specification”. https://github.com/opencontainers/distribution-spec
Open Container Initiativeによって議論?策定
OCI Distribution
Specification(v1策定中)
OCI Image Format
Specification
Runtime
コンテナライフサイクル、
ランタイムがサポートす
べき基本操作の仕様、コ
ンテナ生成に必要な情報
の格納方法の定義
OCI Runtime
Specfication

コンテナを取り巻く基礎技術たち
ランタイム管理イメージ
レジストリ
Build Run
Ship
docker pull
docker push
docker rundocker build

嗚呼素晴らしき哉、コンテナ技術（？）
「取り回しやすさ」がウリのコンテナ（以下はその特長の例）
差分をレイヤ状に保
持し、hashベースの
重複排除により軽量
さを意識したイメー
ジフォーマット仕様
クラスタ上で用いる
イメージ群を統一的
に格納でき、バー
ジョン管理も可能な
レジストリ
VMのような隔離環
境を持ちながらも、
VMよりも軽量で高
速に起動。
イメージレジストリランタイム

レイヤ構造で軽量なコンテナイメージ
同じレイヤは共有
? カーネルを含まず、軽量
? イメージ同士で同一のレイヤがある場合、
それは共有された状態で保存される
? つまり重複レイヤを排除できる
? ベースイメージを使い回せる
? キャッシュが活用できる
$ docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
busybox latest db8ee88ad75f 6 hours ago 1.22MB
postgres latest 53912975086f 27 hours ago 312MB
nginx latest 98ebf73aba75 28 hours ago 109MB
httpd latest ee39f68eb241 6 days ago 154MB
redis latest 598a6f110d01 7 days ago 118MB
alpine latest b7b28af77ffe 7 days ago 5.58MB
golang latest f50db16df5da 8 days ago 774MB
couchbase latest b5f87c81aef1 8 days ago 959MB
mongo latest 785c65f61380 2 weeks ago 412MB
traefik latest 18471c10e6e4 7 weeks ago 71.7MB
↓Docker Hubの人気イメージ
軽い

OCIイメージ仕様の概要
? Markle tree構造。
? 各jsonファイル上で子要素となるファイル(blobディレクトリ配下)をハッシュ値で参照
? コンテナのrootfsのレイヤは、blobsディレクトリ内のtarball
? 各ファイル名はハッシュ値であり、同じハッシュ値を持つ（同じ内容の）レイヤ同士は
重複排除され、実体として一つのみが保持されるようになっている。
/index.json
Manifest
(json)
/blobs/sha256/
Manifestファイルで
そのイメージに含まれる
各レイヤファイルの
ハッシュ値が指定される
各ファイル名は
その内容のハッシュ値
実行時の環境変数などの
設定ファイルも含まれる

クラスタにおける統一的なレジストリ
? クラスタ全体の統一的なイメージのソー
スになる
? シンプルなAPI群をもち、イメージのダウ
ンロードやアップロードが可能。
? ハッシュ値をベースにしたコンテンツへ
のアクセス方式により、そのコンテンツ
の正しさを検証することができる。
$ docker pull swarm:latest
latest: Pulling from library/swarm
d85c18077b82: Pull complete
1e6bb16f8cb1: Pull complete
85bac13497d7: Pull complete
Digest: sha256:b866583a3b8791bcd705b7bc0fd94c66b695a1a2dbaeb5f59ed29940e5015dc8
Status: Downloaded newer image for swarm:latest

レジストリ仕様（v1策定中）の概要
? イメージをレジストリにアップロード/ダウンロードするための汎用的なHTTP API群。
? イメージのManifestやファイルシステムを構成するレイヤを取得したり格納したりできる
API群が定められている。
? 各レイヤ群と、イメージはManifestによって紐づけられる。
? 各レイヤはハッシュ値で指定する（content addressabilityを持つ）。
GET /v2/library/busybox/blobs/sha256:ee153a04…
GET /v2/library/busybox/manifests/latest
{...
"fsLayers": [
{
"blobSum": "sha256:a3ed95ca..."
},
{
"blobSum": "sha256:ee153a04..."
}
],...
Manifest取得
レイヤ（tar.gz）取得
レイヤのハッシュ値

高速起動するコンテナ
? カーネルを含まず、その分起動が高速
(環境にもよるが大体数秒)
? イメージサイズが小さい場合、レジス
トリからノードへのイメージpullも高速
? ノード上でイメージをキャッシュして
おけばrootfsの準備も速い
$ time docker run ubuntu:latest echo "Hello, CNDT!"
Unable to find image 'ubuntu:latest' locally
latest: Pulling from library/ubuntu
5b7339215d1d: Pull complete
14ca88e9f672: Pull complete
a31c3b1caad4: Pull complete
b054a26005b7: Pull complete
Digest: sha256:9b1702dcfe32c873a770a32cfd306dd7fc1c4fd134adfb783db68defc8894b3c
Status: Downloaded newer image for ubuntu:latest
Hello, CNDT!
real 0m10.979s
user 0m0.034s
sys 0m0.040s
← pullを含んで10秒くらい

$ tar xf rootfs.tar -C bundle/rootfs/
$ runc spec -b bundle
$ tree bundle/
bundle/
├── config.json
└── rootfs
├── bin
│ ├── bash
...
# runc run -b bundle mycontainer
# cat /etc/os-release
cat /etc/os-release
NAME="Ubuntu“
...
ランタイム仕様の概要
OCI
runtime
Filesystem bundle
rootfsなどをFilesystem bundle
として準備の必要あり
コンテナ操作のコマンド群
? state：状態情報の取得
? create：コンテナの作成
? start：コンテナの開始
? kill：コンテナの終了
? delete：コンテナの削除
作成
? コンテナランタイムに求められるコマンド群の定義とrootfsの準備の仕方、コンテナのラ
イフサイクル等に関する定義
? rootfsは「filesystem bundle」と呼ばれる形式で任意のディレクトリに準備する。その中
にはコンテナのrootfsやコンテナ実行環境の設定ファイルを含める。
Filesystem bundle
の準備
コンテナ実行
コンテナの中

ここまでのまとめ
レイヤベースの軽量
なイメージ、クラス
タ上で統一されたレ
ジストリ、高速な起
動が特徴的。
イメージ、レジスト
リ、ランタイムに仕
様が定められ、競争
と互換性が両立して
いる。
取り回しがしやすい標準仕様が定められている

これからのランタイム?イメージまわりの動向
目次
1.
2.
3. まとめ

最近話題になり始めている課題感
「取り回しやすさ」は今後保てるのか???？！
機械学習や学術分野
など、ユースケース
によってはコンテナ
が大きくなるのを避
けられない場合があ
る。レイヤ同士の重
複排除も効きにくい。
コンテナイメージ以
外にも、コンテナ関
連のデプロイ単位が
様々出現。各種デプ
ロイ関連ファイルを
個別に管理する必要
が出てきている。
コンテナ起動時、コ
ンテナイメージの
pullに時間がかかっ
てしまっている。イ
メージが大きくなる
につれ、その影響は
顕著になるだろう。
イメージ軽く
できない問題
デプロイ単位
ありすぎ問題
pullに時間
かかりすぎ問題

イメージ課題：イメージが軽くできない問題
? 機械学習フレームワーク等、もはや軽くない（数GB級）のイメージも多い。
? 実はレイヤもそんなに重複排除されない（イメージ集合にも依るが）
docker images --format “{{.ID}}” | xargs -I{} docker inspect {} ＼
| jq -r ".[].RootFS.Layers[]" | sort | uniq -c | sort -nr
Docker Hub人気イメージ50個の、各レイヤ出現回数ランキングを調査
? couchbase:6.0.2
? busybox:1.31.0
? postgres:12
? alpine:3.10
? nginx:1.17
? traefik:2.0
? redis:5.0.5
? mongo:3.4-xenial
? httpd:2.4.39
? golang:1.12.7-stretch
? node:8.16.0-jessie
? mysql:8.0.16
? openjdk:8u222
? memcached:1.5.16
? hello-world:latest
? registry:2
? python:3.8.0b2-buster
? haproxy:2.0.2
? debian:bullseye
? docker:19.03.0-rc3
? wordpress:5.2.2-php7.1-apache
? mariadb:10.4.6-bionic
? consul:1.6.0-beta1
? centos:7
? crate:4.0.2
? php:7.1-apache
? maven:3.6.1-jdk-11
? rabbitmq:3.8.0-beta.5
? nextcloud:14.0.13-apache
? elasticsearch:7.0.0
? ruby:2.7.0-preview1-buster
? influxdb:1.5
? adminer:4.7.2
? logstash:7.0.0
? tomcat:9.0.22-jdk11-openjdk
? sonarqube:7.9.1-community
? jenkins:2.60.3
? kibana:7.0.0
? telegraf:1.9
? swarm:1.2.9
? gradle:5.5.1-jdk8
? ghost:2.25.8
? solr:8.1.1
? kong:1.2.1-alpine
? amazonlinux:2
? rethinkdb:2.3.6
? drupal:8.7.4-apache
? vault:1.1.3
? flink:1.7.2-hadoop24-scala_2.11
? ubuntu:18.04
Docker Hubの人気無料イメージ50個でレイヤかぶりがどれだけ発生しているか測定
※かぶっているレイヤは、再利用（重複排除）されるので、全体としてその分、軽くなる
$ docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
nvidia/cuda latest 010a71dc59db 2 weeks ago 2.81GB
pytorch/pytorch latest e19f3b87dbf3 5 months ago 3.41GB
！！

0
1
2
3
4
5
6
7
8
9
10
各レイヤの出現回数
イメージ課題：イメージが軽くできない問題
? 9回出現：3レイヤ
そこそこ軽くなっている。
でももうちょっとレイヤが
かぶってくれてもいい気が
する???
約18.44GB(論理的な合計サイズ)
約13.13GB(実際のサイズ)
※docker system dfより算出
出現回数（回）
出現レイヤ（1本がユニークな1レイヤ）

レジストリ課題：デプロイ単位ありすぎ問題
? Cloud Native関連のデプロイ技術はたくさんある
? それらそれぞれで「レジストリ」的なストアサーバを用意する必要がある
コンテナ。基本的な実行単位。
OCIで標準仕様の定められたレ
ジストリに格納できる。
Kubernetes。yamlファイル群
でKubernetesに指示する。git
リポジトリなどで管理する。
Helm Charts。Kubernetesの
パッケージマネージャ。Tillerに
格納する。
CNAB。分散アプリケーション
のパッケージ仕様。Dockerレジ
ストリに格納可能。
Docker Compose。デプロイに
yamlファイルを使う。gitリポ
ジトリなどで管理する。 and more…

ランタイム課題：pullに時間かかりすぎ問題
コンテナ起動時にはレジストリからのコンテナイメージの取得（pull）が行わ
れるが、これに多くの時間がかかってしまう
runtime
Filesystem bundle
約76.6% 約23.3%
①イメージをpull ②コンテナを実行
各実行フェーズにかかる時間のベンチマーク
[Harter et al. 2016]
(平均20s) (平均6.1s)
Tyler Harter, Brandon Salmon, Rose Liu, Andrea C.
Arpaci-Dusseau, Remzi H. Arpaci-Dusseau. "Slacker: Fast
Distribution with Lazy Docker Containers". 14th USENIX
Conference on File and Storage Technologies (FAST ’16).
February 22–25, 2016, Santa Clara, CA, USA
↓論文から引用

コンテナ仮想化技術低レイヤの最新動向
イメージの肥大を軽減コンテナ起動時のpull高速化
OCIコミュニティを中心
に次世代イメージフォー
マットについて議論され
ている、次世代の軽量な
イメージ仕様。
コンテナ起動時のpullを
高速化する手法として
「lazy-pull」がいろい
ろなプロジェクトで議論、
実装されてきた。
OCIv2 lazypull技術
統一的なレジストリ仕様
OCIコミュニティと、各
レジストリのベンダ中心
に議論されている、「な
んでも入るレジストリ」
に関する仕様。
OCI Artifact Registry

次世代イメージ仕様：OCIv2（議論中）
レイヤ単位ではなく、より粒度の
高い重複排除によりイメージサイ
ズを軽量化。ファイルまたはそれ
よりも小さい単位で重複排除する
意見が多い。既存のバックアップ
ツールの活用も案として出た。
レイヤを構成するtarアーカイブは
主に以下のような欠点がある
? 再現性に乏しい
? 展開の並列化ができない
そこでtarではないアーカイブ形式
を使うことなどが議論されている
より扱いやすいアーカイブ方式データを細切れにして軽量化
rootfsファイル群
のアーカイブ OCIv1 OCIv2
https://github.com/openSUSE/umoci/issues/256
https://groups.google.com/a/opencontainers.org/forum/#!topic/dev/icXssT3zQxE
https://www.cyphar.com/blog/post/20190121-ociv2-images-i-tar
議論模様

レイヤよりも細かい単位で重複排除したい
レイヤ単位の重複排除より細かい粒度での重複排除
イメージ内
イメージ間
イメージ内で全く同じレイヤ
が出現することはほぼ無い
レイヤに含まれるファイル群の
1bitでも違えば違うレイヤ
ファイルより細かい粒度なら
「同じカタマリ」が出やすい
ファイルより細かい粒度なら
1つのイメージ内でも重複排除されうる

OCI Artifact Registry（議論中）
? コンテナレジストリを統一的な「な
んでも」レジストリにする試み。
? 現状のレジストリの汎用性を生かす
方向。
? 格納したいデータのMIME typeを定
義する機能を追加しようとしている
? こうすることで、レジストリか
らデータpullするツール側でそ
のデータをどのように扱うべき
かがわかるようになる。
? KubeCon EU 2019で議論会が開催
された（↓議事録）
? https://hackmd.io/s/S1X6JNnTN
議論模様
https://github.com/AzureCR/distribution-spec/blob/artifact-registry/artifacts.md
https://stevelasker.blog/2019/05/11/authoring-oci-registry-artifacts-quick-guide/
https://hackmd.io/@KLMFwMkYTZ2AiZfPLrMu2g/S1X6JNnTN?type=view

Node
イメージを高速にpullする技術（lazypull）
CernVM-FS Slacker
https://github.com/containerd/containerd/pull/2467
学術分野での実験結果解析用の巨大ソフト
ウェアスタックを共有するためのファイル
システム。lazypull、ファイルレベルでの
重複排除が可能。バックエンドに
「CernVM-FS」の使用。
コンテナにおけるlazypullの先駆け的な研
究。レジストリに加え、独自のNFS基盤を
使用し、イメージフォーマットにも変更を
加えることでlazypullを実現[Tyler et al.
2016]。
https://www.usenix.org/node/194431
独自のNFS基盤を用いるもの（イメージやレジストリの互換性がない）
Node

Registry
イメージを高速にpullする技術（lazypull）
CRFS FILEgrain
https://github.com/golang/go/issues/30829
Go言語コミュニティで使用している
CI/CDのボトルネックとなっていたコンテ
ナの起動時間を改善するため、独自仕様の
コンテナイメージをlazy-pullするファイル
システム「CRFS」を開発。
https://github.com/AkihiroSuda/filegrain
mobyメンテナ須田氏による提案。イメー
ジフォーマットに変更を加え、ランタイム
側にも専用のプラグインを適用することで、
ファイルレベルの重複排除とlazypullを実
現。イメージはOCI仕様に準拠している。
イメージフォーマットで工夫するもの
ファイル単位で
シーク可能なtar.gz
tar.gz
tar.gz
tar.gz
tar.gz
tar.gz
ファイル
Node
Registry
Node ファイル
イメージのblobを
レイヤではなく
ファイル単位にする

これからのランタイム?イメージまわりの動向
目次
1.
2.
3. まとめ

今、何ができるのか
イメージレジストリランタイム
? Dockerfileのベスト
プラクティスに従う。
? レイヤレベルで重複
排除を意識する（無
意味にレイヤの順番
を入れ替えない）
? レジストリにコンテナ
イメージ以外のものを
格納するためのツール
がある：oras：
https://github.com/
deislabs/oras
? Microsoftが支援して
いる
? ノード上にイメージ
をキャッシュする
? イメージをそもそも
小さく作る

まとめ
イメージ軽く
できない問題
デプロイ単位
ありすぎ問題
pullに時間
かかりすぎ問題
イメージの肥大を軽減コンテナ起動時pull高速化
OCIv2 lazypull技術
統一的なレジストリ仕様
OCI Artifact Registry

狠狠撸

翱颁滨惫2？！軽量高速なイケてる次世代イメージ仕様の最新动向を抑えよう！

More Related Content

翱颁滨惫2？！軽量高速なイケてる次世代イメージ仕様の最新动向を抑えよう！