SlideShare a Scribd company logo
Copyright©2019 NTT Corp. All Rights Reserved.
OCIv2?!
軽量高速なイケてる次世代イメージ仕様の
最新動向を抑えよう!
2019/7/22(月)
日本電信電話株式会社
ソフトウェアイノベーションセンタ
徳永 航平
CloudNative Days Tokyo 2019 [1B4]
2Copyright©2019 NTT Corp. All Rights Reserved.
自己紹介
名前 徳永 航平
所属 NTT ソフトウェアイノベーションセンタ
興味 コンテナランタイム、イメージ
3Copyright©2019 NTT Corp. All Rights Reserved.
今のランタイム・イメージまわりの様子
目次
1.
2. これからのランタイム・イメージまわりの動向
3. まとめ
4Copyright©2019 NTT Corp. All Rights Reserved.
コンテナまわりの標準仕様
コンテナイメージの標準
仕様。コンテナに含める
ファイルのレイヤや、メ
タデータの仕様およびそ
の フ ァ イ ル を 定 義
コンテナの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
5Copyright©2019 NTT Corp. All Rights Reserved.
コンテナを取り巻く基礎技術たち
ランタイム管理イメージ
レジストリ
Build Run
Ship
docker pull
docker push
docker rundocker build
6Copyright©2019 NTT Corp. All Rights Reserved.
嗚呼素晴らしき哉、コンテナ技術(?)
「取り回しやすさ」がウリのコンテナ(以下はその特長の例)
差分をレイヤ状に保
持し、hashベースの
重複排除により軽量
さを意識したイメー
ジフォーマット仕様
クラスタ上で用いる
イメージ群を統一的
に格納でき、バー
ジョン管理も可能な
レジストリ
VMのような隔離環
境を持ちながらも、
VMよりも軽量で高
速に起動。
イメージ レジストリ ランタイム
7Copyright©2019 NTT Corp. All Rights Reserved.
レイヤ構造で軽量なコンテナイメージ
同じレイヤは共有
 カーネルを含まず、軽量
 イメージ同士で同一のレイヤがある場合、
それは共有された状態で保存される
 つまり重複レイヤを排除できる
 ベースイメージを使い回せる
 キャッシュが活用できる
$ 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の人気イメージ
軽い
8Copyright©2019 NTT Corp. All Rights Reserved.
OCIイメージ仕様の概要
 Markle tree構造。
 各jsonファイル上で子要素となるファイル(blobディレクトリ配下)をハッシュ値で参照
 コンテナのrootfsのレイヤは、blobsディレクトリ内のtarball
 各ファイル名はハッシュ値であり、同じハッシュ値を持つ(同じ内容の)レイヤ同士は
重複排除され、実体として一つのみが保持されるようになっている。
/index.json
Manifest
(json)
/blobs/sha256/
Manifestファイルで
そのイメージに含まれる
各レイヤファイルの
ハッシュ値が指定される
各ファイル名は
その内容のハッシュ値
実行時の環境変数などの
設定ファイルも含まれる
9Copyright©2019 NTT Corp. All Rights Reserved.
クラスタにおける統一的なレジストリ
 クラスタ全体の統一的なイメージのソー
スになる
 シンプルな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
10Copyright©2019 NTT Corp. All Rights Reserved.
レジストリ仕様(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)取得
レイヤのハッシュ値
11Copyright©2019 NTT Corp. All Rights Reserved.
高速起動するコンテナ
 カーネルを含まず、その分起動が高速
(環境にもよるが大体数秒)
 イメージサイズが小さい場合、レジス
トリからノードへのイメージ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秒くらい
12Copyright©2019 NTT Corp. All Rights Reserved.
$ 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
の準備
コンテナ実行
コンテナの中
13Copyright©2019 NTT Corp. All Rights Reserved.
ここまでのまとめ
レイヤベースの軽量
なイメージ、クラス
タ上で統一されたレ
ジストリ、高速な起
動が特徴的。
イメージ、レジスト
リ、ランタイムに仕
様が定められ、競争
と互換性が両立して
いる。
取り回しがしやすい 標準仕様が定められている
14Copyright©2019 NTT Corp. All Rights Reserved.
これからのランタイム・イメージまわりの動向
今のランタイム・イメージまわりの様子
目次
1.
2.
3. まとめ
15Copyright©2019 NTT Corp. All Rights Reserved.
最近話題になり始めている課題感
「取り回しやすさ」は今後保てるのか・・・?!
機械学習や学術分野
など、ユースケース
によってはコンテナ
が大きくなるのを避
けられない場合があ
る。レイヤ同士の重
複排除も効きにくい。
コンテナイメージ以
外にも、コンテナ関
連のデプロイ単位が
様々出現。各種デプ
ロイ関連ファイルを
個別に管理する必要
が出てきている。
コンテナ起動時、コ
ンテナイメージの
pullに時間がかかっ
てしまっている。イ
メージが大きくなる
につれ、その影響は
顕著になるだろう。
イメージ軽く
できない問題
デプロイ単位
ありすぎ問題
pullに時間
かかりすぎ問題
16Copyright©2019 NTT Corp. All Rights Reserved.
イメージ課題:イメージが軽くできない問題
 機械学習フレームワーク等、もはや軽くない(数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
!!
17Copyright©2019 NTT Corp. All Rights Reserved.
0
1
2
3
4
5
6
7
8
9
10
各レイヤの出現回数
イメージ課題:イメージが軽くできない問題
 9回出現:3レイヤ
 7回出現:1レイヤ
 6回出現:1レイヤ
 5回出現:2レイヤ
 4回出現:8レイヤ
 2回出現:23レイヤ
 1回出現:285レイヤ
そこそこ軽くなっている。
でももうちょっとレイヤが
かぶってくれてもいい気が
する・・・
約18.44GB(論理的な合計サイズ)
約13.13GB(実際のサイズ)
※docker system dfより算出
出現回数(回)
出現レイヤ(1本がユニークな1レイヤ)
18Copyright©2019 NTT Corp. All Rights Reserved.
レジストリ課題:デプロイ単位ありすぎ問題
 Cloud Native関連のデプロイ技術はたくさんある
 それらそれぞれで「レジストリ」的なストアサーバを用意する必要がある
コンテナ。基本的な実行単位。
OCIで標準仕様の定められたレ
ジストリに格納できる。
Kubernetes。yamlファイル群
でKubernetesに指示する。git
リポジトリなどで管理する。
Helm Charts。Kubernetesの
パッケージマネージャ。Tillerに
格納する。
CNAB。分散アプリケーション
のパッケージ仕様。Dockerレジ
ストリに格納可能。
Docker Compose。デプロイに
yamlファイルを使う。gitリポ
ジトリなどで管理する。 and more…
19Copyright©2019 NTT Corp. All Rights Reserved.
ランタイム課題: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
↓論文から引用
20Copyright©2019 NTT Corp. All Rights Reserved.
コンテナ仮想化技術低レイヤの最新動向
イメージの肥大を軽減 コンテナ起動時のpull高速化
OCIコミュニティを中心
に次世代イメージフォー
マットについて議論され
ている、次世代の軽量な
イ メ ー ジ 仕 様 。
コンテナ起動時のpullを
高 速 化 す る 手 法 と し て
「lazy-pull」がいろい
ろなプロジェクトで議論、
実 装 さ れ て き た 。
OCIv2 lazypull技術
統一的なレジストリ仕様
OCIコミュニティと、各
レジストリのベンダ中心
に議論されている、「な
んでも入るレジストリ」
に 関 す る 仕 様 。
OCI Artifact Registry
21Copyright©2019 NTT Corp. All Rights Reserved.
次世代イメージ仕様: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
議論模様
22Copyright©2019 NTT Corp. All Rights Reserved.
レイヤよりも細かい単位で重複排除したい
レイヤ単位の重複排除 より細かい粒度での重複排除
イメージ内
イメージ間
イメージ内で全く同じレイヤ
が出現することはほぼ無い
レイヤに含まれるファイル群の
1bitでも違えば違うレイヤ
ファイルより細かい粒度なら
「同じカタマリ」が出やすい
ファイルより細かい粒度なら
1つのイメージ内でも重複排除されうる
23Copyright©2019 NTT Corp. All Rights Reserved.
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
24Copyright©2019 NTT Corp. All Rights Reserved.
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
25Copyright©2019 NTT Corp. All Rights Reserved.
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を
レイヤではなく
ファイル単位にする
26Copyright©2019 NTT Corp. All Rights Reserved.
これからのランタイム・イメージまわりの動向
今のランタイム・イメージまわりの様子
目次
1.
2.
3. まとめ
27Copyright©2019 NTT Corp. All Rights Reserved.
今、何ができるのか
イメージ レジストリ ランタイム
 Dockerfileのベスト
プラクティスに従う。
 レイヤレベルで重複
排除を意識する(無
意味にレイヤの順番
を入れ替えない)
 レジストリにコンテナ
イメージ以外のものを
格納するためのツール
がある:oras:
https://github.com/
deislabs/oras
 Microsoftが支援して
いる
 ノード上にイメージ
をキャッシュする
 イメージをそもそも
小さく作る
28Copyright©2019 NTT Corp. All Rights Reserved.
まとめ
イメージ軽く
できない問題
デプロイ単位
ありすぎ問題
pullに時間
かかりすぎ問題
イメージの肥大を軽減 コンテナ起動時pull高速化
OCIv2 lazypull技術
統一的なレジストリ仕様
OCI Artifact Registry

More Related Content

What's hot

DockerとKubernetesをかけめぐる
DockerとKubernetesをかけめぐるDockerとKubernetesをかけめぐる
DockerとKubernetesをかけめぐる
Kohei Tokunaga
 
Kubernetesでの性能解析 ~なんとなく遅いからの脱却~(Kubernetes Meetup Tokyo #33 発表資料)
Kubernetesでの性能解析 ~なんとなく遅いからの脱却~(Kubernetes Meetup Tokyo #33 発表資料)Kubernetesでの性能解析 ~なんとなく遅いからの脱却~(Kubernetes Meetup Tokyo #33 発表資料)
Kubernetesでの性能解析 ~なんとなく遅いからの脱却~(Kubernetes Meetup Tokyo #33 発表資料)
NTT DATA Technology & Innovation
 
Dockerからcontainerdへの移行
Dockerからcontainerdへの移行Dockerからcontainerdへの移行
Dockerからcontainerdへの移行
Akihiro Suda
 
Faster Container Image Distribution on a Variety of Tools with Lazy Pulling
Faster Container Image Distribution on a Variety of Tools with Lazy PullingFaster Container Image Distribution on a Variety of Tools with Lazy Pulling
Faster Container Image Distribution on a Variety of Tools with Lazy Pulling
Kohei Tokunaga
 
BuildKitによる高速でセキュアなイメージビルド
BuildKitによる高速でセキュアなイメージビルドBuildKitによる高速でセキュアなイメージビルド
BuildKitによる高速でセキュアなイメージビルド
Akihiro Suda
 
乗っ取れコンテナ!!開発者から見たコンテナセキュリティの考え方(CloudNative Days Tokyo 2021 発表資料)
乗っ取れコンテナ!!開発者から見たコンテナセキュリティの考え方(CloudNative Days Tokyo 2021 発表資料)乗っ取れコンテナ!!開発者から見たコンテナセキュリティの考え方(CloudNative Days Tokyo 2021 発表資料)
乗っ取れコンテナ!!開発者から見たコンテナセキュリティの考え方(CloudNative Days Tokyo 2021 発表資料)
NTT DATA Technology & Innovation
 
[Container Runtime Meetup] runc & User Namespaces
[Container Runtime Meetup] runc & User Namespaces[Container Runtime Meetup] runc & User Namespaces
[Container Runtime Meetup] runc & User Namespaces
Akihiro Suda
 
[CEDEC 2021] 運用中タイトルでも怖くない! 『メルクストーリア』におけるハイパフォーマンス・ローコストなリアルタイム通信技術の導入事例
[CEDEC 2021] 運用中タイトルでも怖くない! 『メルクストーリア』におけるハイパフォーマンス・ローコストなリアルタイム通信技術の導入事例[CEDEC 2021] 運用中タイトルでも怖くない! 『メルクストーリア』におけるハイパフォーマンス・ローコストなリアルタイム通信技術の導入事例
[CEDEC 2021] 運用中タイトルでも怖くない! 『メルクストーリア』におけるハイパフォーマンス・ローコストなリアルタイム通信技術の導入事例
Naoya Kishimoto
 
Amazon EKS によるスマホゲームのバックエンド運用事例
Amazon EKS によるスマホゲームのバックエンド運用事例Amazon EKS によるスマホゲームのバックエンド運用事例
Amazon EKS によるスマホゲームのバックエンド運用事例
gree_tech
 
20分でわかるgVisor入門
20分でわかるgVisor入門20分でわかるgVisor入門
20分でわかるgVisor入門
Shuji Yamada
 
Dockerからcontainerdへの移行
Dockerからcontainerdへの移行Dockerからcontainerdへの移行
Dockerからcontainerdへの移行
Kohei Tokunaga
 
なぜディスクレスハイパーバイザに至ったのか / Why did we select to the diskless hypervisor? #builde...
なぜディスクレスハイパーバイザに至ったのか / Why did we select to the diskless hypervisor? #builde...なぜディスクレスハイパーバイザに至ったのか / Why did we select to the diskless hypervisor? #builde...
なぜディスクレスハイパーバイザに至ったのか / Why did we select to the diskless hypervisor? #builde...
whywaita
 
[KubeCon NA 2020] containerd: Rootless Containers 2020
[KubeCon NA 2020] containerd: Rootless Containers 2020[KubeCon NA 2020] containerd: Rootless Containers 2020
[KubeCon NA 2020] containerd: Rootless Containers 2020
Akihiro Suda
 
ゼロからはじめるKVM超入門
ゼロからはじめるKVM超入門ゼロからはじめるKVM超入門
ゼロからはじめるKVM超入門
VirtualTech Japan Inc.
 
OCIランタイムの筆頭「runc」を俯瞰する
OCIランタイムの筆頭「runc」を俯瞰するOCIランタイムの筆頭「runc」を俯瞰する
OCIランタイムの筆頭「runc」を俯瞰する
Kohei Tokunaga
 
本当は恐ろしい分散システムの話
本当は恐ろしい分散システムの話本当は恐ろしい分散システムの話
本当は恐ろしい分散システムの話
Kumazaki Hiroki
 
3種類のTEE比較(Intel SGX, ARM TrustZone, RISC-V Keystone)
3種類のTEE比較(Intel SGX, ARM TrustZone, RISC-V Keystone)3種類のTEE比較(Intel SGX, ARM TrustZone, RISC-V Keystone)
3種類のTEE比較(Intel SGX, ARM TrustZone, RISC-V Keystone)
Kuniyasu Suzaki
 
Kubernetes ControllerをScale-Outさせる方法 / Kubernetes Meetup Tokyo #55
Kubernetes ControllerをScale-Outさせる方法 / Kubernetes Meetup Tokyo #55Kubernetes ControllerをScale-Outさせる方法 / Kubernetes Meetup Tokyo #55
Kubernetes ControllerをScale-Outさせる方法 / Kubernetes Meetup Tokyo #55
Preferred Networks
 
Docker Compose 徹底解説
Docker Compose 徹底解説Docker Compose 徹底解説
Docker Compose 徹底解説
Masahito Zembutsu
 
ネットワーク ゲームにおけるTCPとUDPの使い分け
ネットワーク ゲームにおけるTCPとUDPの使い分けネットワーク ゲームにおけるTCPとUDPの使い分け
ネットワーク ゲームにおけるTCPとUDPの使い分け
モノビット エンジン
 

What's hot (20)

DockerとKubernetesをかけめぐる
DockerとKubernetesをかけめぐるDockerとKubernetesをかけめぐる
DockerとKubernetesをかけめぐる
 
Kubernetesでの性能解析 ~なんとなく遅いからの脱却~(Kubernetes Meetup Tokyo #33 発表資料)
Kubernetesでの性能解析 ~なんとなく遅いからの脱却~(Kubernetes Meetup Tokyo #33 発表資料)Kubernetesでの性能解析 ~なんとなく遅いからの脱却~(Kubernetes Meetup Tokyo #33 発表資料)
Kubernetesでの性能解析 ~なんとなく遅いからの脱却~(Kubernetes Meetup Tokyo #33 発表資料)
 
Dockerからcontainerdへの移行
Dockerからcontainerdへの移行Dockerからcontainerdへの移行
Dockerからcontainerdへの移行
 
Faster Container Image Distribution on a Variety of Tools with Lazy Pulling
Faster Container Image Distribution on a Variety of Tools with Lazy PullingFaster Container Image Distribution on a Variety of Tools with Lazy Pulling
Faster Container Image Distribution on a Variety of Tools with Lazy Pulling
 
BuildKitによる高速でセキュアなイメージビルド
BuildKitによる高速でセキュアなイメージビルドBuildKitによる高速でセキュアなイメージビルド
BuildKitによる高速でセキュアなイメージビルド
 
乗っ取れコンテナ!!開発者から見たコンテナセキュリティの考え方(CloudNative Days Tokyo 2021 発表資料)
乗っ取れコンテナ!!開発者から見たコンテナセキュリティの考え方(CloudNative Days Tokyo 2021 発表資料)乗っ取れコンテナ!!開発者から見たコンテナセキュリティの考え方(CloudNative Days Tokyo 2021 発表資料)
乗っ取れコンテナ!!開発者から見たコンテナセキュリティの考え方(CloudNative Days Tokyo 2021 発表資料)
 
[Container Runtime Meetup] runc & User Namespaces
[Container Runtime Meetup] runc & User Namespaces[Container Runtime Meetup] runc & User Namespaces
[Container Runtime Meetup] runc & User Namespaces
 
[CEDEC 2021] 運用中タイトルでも怖くない! 『メルクストーリア』におけるハイパフォーマンス・ローコストなリアルタイム通信技術の導入事例
[CEDEC 2021] 運用中タイトルでも怖くない! 『メルクストーリア』におけるハイパフォーマンス・ローコストなリアルタイム通信技術の導入事例[CEDEC 2021] 運用中タイトルでも怖くない! 『メルクストーリア』におけるハイパフォーマンス・ローコストなリアルタイム通信技術の導入事例
[CEDEC 2021] 運用中タイトルでも怖くない! 『メルクストーリア』におけるハイパフォーマンス・ローコストなリアルタイム通信技術の導入事例
 
Amazon EKS によるスマホゲームのバックエンド運用事例
Amazon EKS によるスマホゲームのバックエンド運用事例Amazon EKS によるスマホゲームのバックエンド運用事例
Amazon EKS によるスマホゲームのバックエンド運用事例
 
20分でわかるgVisor入門
20分でわかるgVisor入門20分でわかるgVisor入門
20分でわかるgVisor入門
 
Dockerからcontainerdへの移行
Dockerからcontainerdへの移行Dockerからcontainerdへの移行
Dockerからcontainerdへの移行
 
なぜディスクレスハイパーバイザに至ったのか / Why did we select to the diskless hypervisor? #builde...
なぜディスクレスハイパーバイザに至ったのか / Why did we select to the diskless hypervisor? #builde...なぜディスクレスハイパーバイザに至ったのか / Why did we select to the diskless hypervisor? #builde...
なぜディスクレスハイパーバイザに至ったのか / Why did we select to the diskless hypervisor? #builde...
 
[KubeCon NA 2020] containerd: Rootless Containers 2020
[KubeCon NA 2020] containerd: Rootless Containers 2020[KubeCon NA 2020] containerd: Rootless Containers 2020
[KubeCon NA 2020] containerd: Rootless Containers 2020
 
ゼロからはじめるKVM超入門
ゼロからはじめるKVM超入門ゼロからはじめるKVM超入門
ゼロからはじめるKVM超入門
 
OCIランタイムの筆頭「runc」を俯瞰する
OCIランタイムの筆頭「runc」を俯瞰するOCIランタイムの筆頭「runc」を俯瞰する
OCIランタイムの筆頭「runc」を俯瞰する
 
本当は恐ろしい分散システムの話
本当は恐ろしい分散システムの話本当は恐ろしい分散システムの話
本当は恐ろしい分散システムの話
 
3種類のTEE比較(Intel SGX, ARM TrustZone, RISC-V Keystone)
3種類のTEE比較(Intel SGX, ARM TrustZone, RISC-V Keystone)3種類のTEE比較(Intel SGX, ARM TrustZone, RISC-V Keystone)
3種類のTEE比較(Intel SGX, ARM TrustZone, RISC-V Keystone)
 
Kubernetes ControllerをScale-Outさせる方法 / Kubernetes Meetup Tokyo #55
Kubernetes ControllerをScale-Outさせる方法 / Kubernetes Meetup Tokyo #55Kubernetes ControllerをScale-Outさせる方法 / Kubernetes Meetup Tokyo #55
Kubernetes ControllerをScale-Outさせる方法 / Kubernetes Meetup Tokyo #55
 
Docker Compose 徹底解説
Docker Compose 徹底解説Docker Compose 徹底解説
Docker Compose 徹底解説
 
ネットワーク ゲームにおけるTCPとUDPの使い分け
ネットワーク ゲームにおけるTCPとUDPの使い分けネットワーク ゲームにおけるTCPとUDPの使い分け
ネットワーク ゲームにおけるTCPとUDPの使い分け
 

Similar to OCIv2?!軽量高速なイケてる次世代イメージ仕様の最新動向を抑えよう!

Cloudstack user group meeting in osaka
Cloudstack user group meeting in osakaCloudstack user group meeting in osaka
Cloudstack user group meeting in osakaNaotaka Jay HOTTA
 
Open Shift v3 主要機能と内部構造のご紹介
Open Shift v3 主要機能と内部構造のご紹介Open Shift v3 主要機能と内部構造のご紹介
Open Shift v3 主要機能と内部構造のご紹介
Etsuji Nakai
 
DOO-013_Docker 最新動向と Azure Container Service 入門
DOO-013_Docker 最新動向と Azure Container Service 入門DOO-013_Docker 最新動向と Azure Container Service 入門
DOO-013_Docker 最新動向と Azure Container Service 入門
decode2016
 
OpenStackをさらに”使う”技術 - OpenStack&Docker活用テクニック
OpenStackをさらに”使う”技術 - OpenStack&Docker活用テクニックOpenStackをさらに”使う”技術 - OpenStack&Docker活用テクニック
OpenStackをさらに”使う”技術 - OpenStack&Docker活用テクニック
Etsuji Nakai
 
OpenStack最新動向と構築のポイント - EMC様セミナー 「あなたのビジネスを高速化! OpenStackが実現する戦略的なクラウドインフラ」
OpenStack最新動向と構築のポイント - EMC様セミナー 「あなたのビジネスを高速化! OpenStackが実現する戦略的なクラウドインフラ」OpenStack最新動向と構築のポイント - EMC様セミナー 「あなたのビジネスを高速化! OpenStackが実現する戦略的なクラウドインフラ」
OpenStack最新動向と構築のポイント - EMC様セミナー 「あなたのビジネスを高速化! OpenStackが実現する戦略的なクラウドインフラ」
Nobuyuki Tamaoki
 
Docker ComposeでMastodonが必要なものを梱包する話
Docker ComposeでMastodonが必要なものを梱包する話Docker ComposeでMastodonが必要なものを梱包する話
Docker ComposeでMastodonが必要なものを梱包する話
Masahito Zembutsu
 
OSC2012 Tokyo/Spring JOSUG
OSC2012 Tokyo/Spring JOSUGOSC2012 Tokyo/Spring JOSUG
OSC2012 Tokyo/Spring JOSUG
Hideki Saito
 
Dockerライフサイクルの基礎 地雷を踏み抜けろ!
Dockerライフサイクルの基礎 地雷を踏み抜けろ!Dockerライフサイクルの基礎 地雷を踏み抜けろ!
Dockerライフサイクルの基礎 地雷を踏み抜けろ!
Masahito Zembutsu
 
RoR周辺知識15項目
RoR周辺知識15項目RoR周辺知識15項目
RoR周辺知識15項目
saiwaki
 
「hbstudy#23 OpenStack祭!!」資料 ~OpenStackプロジェクトの全体像~
「hbstudy#23 OpenStack祭!!」資料 ~OpenStackプロジェクトの全体像~「hbstudy#23 OpenStack祭!!」資料 ~OpenStackプロジェクトの全体像~
「hbstudy#23 OpenStack祭!!」資料 ~OpenStackプロジェクトの全体像~
Masanori Itoh
 
CloudStack Ecosystem Day - OpenStack/Swift
CloudStack Ecosystem Day - OpenStack/SwiftCloudStack Ecosystem Day - OpenStack/Swift
CloudStack Ecosystem Day - OpenStack/Swiftirix_jp
 
Apache Bigtop3.2 (仮)(Open Source Conference 2022 Online/Hiroshima 発表資料)
Apache Bigtop3.2 (仮)(Open Source Conference 2022 Online/Hiroshima 発表資料)Apache Bigtop3.2 (仮)(Open Source Conference 2022 Online/Hiroshima 発表資料)
Apache Bigtop3.2 (仮)(Open Source Conference 2022 Online/Hiroshima 発表資料)
NTT DATA Technology & Innovation
 
OSC2012 Nagoya - OpenStack - Storage System; Overview
OSC2012 Nagoya - OpenStack - Storage System; OverviewOSC2012 Nagoya - OpenStack - Storage System; Overview
OSC2012 Nagoya - OpenStack - Storage System; Overviewirix_jp
 
Dockerイメージ管理の内部構造
Dockerイメージ管理の内部構造Dockerイメージ管理の内部構造
Dockerイメージ管理の内部構造
Etsuji Nakai
 
ASP.NET vNextの全貌
ASP.NET vNextの全貌ASP.NET vNextの全貌
ASP.NET vNextの全貌
A AOKI
 
OpenStackで始めるクラウド環境構築入門
OpenStackで始めるクラウド環境構築入門OpenStackで始めるクラウド環境構築入門
OpenStackで始めるクラウド環境構築入門
VirtualTech Japan Inc.
 
Docker 17.06 Updates 最近何が変わったの?
Docker 17.06 Updates 最近何が変わったの?Docker 17.06 Updates 最近何が変わったの?
Docker 17.06 Updates 最近何が変わったの?
Masahito Zembutsu
 
AlibabaCloudではじめるKubernetes
AlibabaCloudではじめるKubernetesAlibabaCloudではじめるKubernetes
AlibabaCloudではじめるKubernetes
Shinya Mori (@mosuke5)
 
20131211 Neutron Havana
20131211 Neutron Havana20131211 Neutron Havana
20131211 Neutron HavanaAkihiro Motoki
 
BioDevOpsによる再現性のあるバイオインフォマティクス環境の構築
BioDevOpsによる再現性のあるバイオインフォマティクス環境の構築BioDevOpsによる再現性のあるバイオインフォマティクス環境の構築
BioDevOpsによる再現性のあるバイオインフォマティクス環境の構築
Itoshi Nikaido
 

Similar to OCIv2?!軽量高速なイケてる次世代イメージ仕様の最新動向を抑えよう! (20)

Cloudstack user group meeting in osaka
Cloudstack user group meeting in osakaCloudstack user group meeting in osaka
Cloudstack user group meeting in osaka
 
Open Shift v3 主要機能と内部構造のご紹介
Open Shift v3 主要機能と内部構造のご紹介Open Shift v3 主要機能と内部構造のご紹介
Open Shift v3 主要機能と内部構造のご紹介
 
DOO-013_Docker 最新動向と Azure Container Service 入門
DOO-013_Docker 最新動向と Azure Container Service 入門DOO-013_Docker 最新動向と Azure Container Service 入門
DOO-013_Docker 最新動向と Azure Container Service 入門
 
OpenStackをさらに”使う”技術 - OpenStack&Docker活用テクニック
OpenStackをさらに”使う”技術 - OpenStack&Docker活用テクニックOpenStackをさらに”使う”技術 - OpenStack&Docker活用テクニック
OpenStackをさらに”使う”技術 - OpenStack&Docker活用テクニック
 
OpenStack最新動向と構築のポイント - EMC様セミナー 「あなたのビジネスを高速化! OpenStackが実現する戦略的なクラウドインフラ」
OpenStack最新動向と構築のポイント - EMC様セミナー 「あなたのビジネスを高速化! OpenStackが実現する戦略的なクラウドインフラ」OpenStack最新動向と構築のポイント - EMC様セミナー 「あなたのビジネスを高速化! OpenStackが実現する戦略的なクラウドインフラ」
OpenStack最新動向と構築のポイント - EMC様セミナー 「あなたのビジネスを高速化! OpenStackが実現する戦略的なクラウドインフラ」
 
Docker ComposeでMastodonが必要なものを梱包する話
Docker ComposeでMastodonが必要なものを梱包する話Docker ComposeでMastodonが必要なものを梱包する話
Docker ComposeでMastodonが必要なものを梱包する話
 
OSC2012 Tokyo/Spring JOSUG
OSC2012 Tokyo/Spring JOSUGOSC2012 Tokyo/Spring JOSUG
OSC2012 Tokyo/Spring JOSUG
 
Dockerライフサイクルの基礎 地雷を踏み抜けろ!
Dockerライフサイクルの基礎 地雷を踏み抜けろ!Dockerライフサイクルの基礎 地雷を踏み抜けろ!
Dockerライフサイクルの基礎 地雷を踏み抜けろ!
 
RoR周辺知識15項目
RoR周辺知識15項目RoR周辺知識15項目
RoR周辺知識15項目
 
「hbstudy#23 OpenStack祭!!」資料 ~OpenStackプロジェクトの全体像~
「hbstudy#23 OpenStack祭!!」資料 ~OpenStackプロジェクトの全体像~「hbstudy#23 OpenStack祭!!」資料 ~OpenStackプロジェクトの全体像~
「hbstudy#23 OpenStack祭!!」資料 ~OpenStackプロジェクトの全体像~
 
CloudStack Ecosystem Day - OpenStack/Swift
CloudStack Ecosystem Day - OpenStack/SwiftCloudStack Ecosystem Day - OpenStack/Swift
CloudStack Ecosystem Day - OpenStack/Swift
 
Apache Bigtop3.2 (仮)(Open Source Conference 2022 Online/Hiroshima 発表資料)
Apache Bigtop3.2 (仮)(Open Source Conference 2022 Online/Hiroshima 発表資料)Apache Bigtop3.2 (仮)(Open Source Conference 2022 Online/Hiroshima 発表資料)
Apache Bigtop3.2 (仮)(Open Source Conference 2022 Online/Hiroshima 発表資料)
 
OSC2012 Nagoya - OpenStack - Storage System; Overview
OSC2012 Nagoya - OpenStack - Storage System; OverviewOSC2012 Nagoya - OpenStack - Storage System; Overview
OSC2012 Nagoya - OpenStack - Storage System; Overview
 
Dockerイメージ管理の内部構造
Dockerイメージ管理の内部構造Dockerイメージ管理の内部構造
Dockerイメージ管理の内部構造
 
ASP.NET vNextの全貌
ASP.NET vNextの全貌ASP.NET vNextの全貌
ASP.NET vNextの全貌
 
OpenStackで始めるクラウド環境構築入門
OpenStackで始めるクラウド環境構築入門OpenStackで始めるクラウド環境構築入門
OpenStackで始めるクラウド環境構築入門
 
Docker 17.06 Updates 最近何が変わったの?
Docker 17.06 Updates 最近何が変わったの?Docker 17.06 Updates 最近何が変わったの?
Docker 17.06 Updates 最近何が変わったの?
 
AlibabaCloudではじめるKubernetes
AlibabaCloudではじめるKubernetesAlibabaCloudではじめるKubernetes
AlibabaCloudではじめるKubernetes
 
20131211 Neutron Havana
20131211 Neutron Havana20131211 Neutron Havana
20131211 Neutron Havana
 
BioDevOpsによる再現性のあるバイオインフォマティクス環境の構築
BioDevOpsによる再現性のあるバイオインフォマティクス環境の構築BioDevOpsによる再現性のあるバイオインフォマティクス環境の構築
BioDevOpsによる再現性のあるバイオインフォマティクス環境の構築
 

More from Kohei Tokunaga

BuildKitの概要と最近の機能
BuildKitの概要と最近の機能BuildKitの概要と最近の機能
BuildKitの概要と最近の機能
Kohei Tokunaga
 
P2P Container Image Distribution on IPFS With containerd and nerdctl
P2P Container Image Distribution on IPFS With containerd and nerdctlP2P Container Image Distribution on IPFS With containerd and nerdctl
P2P Container Image Distribution on IPFS With containerd and nerdctl
Kohei Tokunaga
 
Introduction and Deep Dive Into Containerd
Introduction and Deep Dive Into ContainerdIntroduction and Deep Dive Into Containerd
Introduction and Deep Dive Into Containerd
Kohei Tokunaga
 
Starting up Containers Super Fast With Lazy Pulling of Images
Starting up Containers Super Fast With Lazy Pulling of ImagesStarting up Containers Super Fast With Lazy Pulling of Images
Starting up Containers Super Fast With Lazy Pulling of Images
Kohei Tokunaga
 
Build and Run Containers With Lazy Pulling - Adoption status of containerd St...
Build and Run Containers With Lazy Pulling - Adoption status of containerd St...Build and Run Containers With Lazy Pulling - Adoption status of containerd St...
Build and Run Containers With Lazy Pulling - Adoption status of containerd St...
Kohei Tokunaga
 
BuildKitでLazy Pullを有効にしてビルドを早くする話
BuildKitでLazy Pullを有効にしてビルドを早くする話BuildKitでLazy Pullを有効にしてビルドを早くする話
BuildKitでLazy Pullを有効にしてビルドを早くする話
Kohei Tokunaga
 
The overview of lazypull with containerd Remote Snapshotter & Stargz Snapshotter
The overview of lazypull with containerd Remote Snapshotter & Stargz SnapshotterThe overview of lazypull with containerd Remote Snapshotter & Stargz Snapshotter
The overview of lazypull with containerd Remote Snapshotter & Stargz Snapshotter
Kohei Tokunaga
 
Startup Containers in Lightning Speed with Lazy Image Distribution
Startup Containers in Lightning Speed with Lazy Image DistributionStartup Containers in Lightning Speed with Lazy Image Distribution
Startup Containers in Lightning Speed with Lazy Image Distribution
Kohei Tokunaga
 
Stargz Snapshotter: イメージのpullを省略してcontainerdでコンテナを高速に起動する
Stargz Snapshotter: イメージのpullを省略してcontainerdでコンテナを高速に起動するStargz Snapshotter: イメージのpullを省略してcontainerdでコンテナを高速に起動する
Stargz Snapshotter: イメージのpullを省略してcontainerdでコンテナを高速に起動する
Kohei Tokunaga
 
5分で振り返るKubeCon EU 2019:ランタイムとイメージの話題ダイジェスト
5分で振り返るKubeCon EU 2019:ランタイムとイメージの話題ダイジェスト5分で振り返るKubeCon EU 2019:ランタイムとイメージの話題ダイジェスト
5分で振り返るKubeCon EU 2019:ランタイムとイメージの話題ダイジェスト
Kohei Tokunaga
 

More from Kohei Tokunaga (10)

BuildKitの概要と最近の機能
BuildKitの概要と最近の機能BuildKitの概要と最近の機能
BuildKitの概要と最近の機能
 
P2P Container Image Distribution on IPFS With containerd and nerdctl
P2P Container Image Distribution on IPFS With containerd and nerdctlP2P Container Image Distribution on IPFS With containerd and nerdctl
P2P Container Image Distribution on IPFS With containerd and nerdctl
 
Introduction and Deep Dive Into Containerd
Introduction and Deep Dive Into ContainerdIntroduction and Deep Dive Into Containerd
Introduction and Deep Dive Into Containerd
 
Starting up Containers Super Fast With Lazy Pulling of Images
Starting up Containers Super Fast With Lazy Pulling of ImagesStarting up Containers Super Fast With Lazy Pulling of Images
Starting up Containers Super Fast With Lazy Pulling of Images
 
Build and Run Containers With Lazy Pulling - Adoption status of containerd St...
Build and Run Containers With Lazy Pulling - Adoption status of containerd St...Build and Run Containers With Lazy Pulling - Adoption status of containerd St...
Build and Run Containers With Lazy Pulling - Adoption status of containerd St...
 
BuildKitでLazy Pullを有効にしてビルドを早くする話
BuildKitでLazy Pullを有効にしてビルドを早くする話BuildKitでLazy Pullを有効にしてビルドを早くする話
BuildKitでLazy Pullを有効にしてビルドを早くする話
 
The overview of lazypull with containerd Remote Snapshotter & Stargz Snapshotter
The overview of lazypull with containerd Remote Snapshotter & Stargz SnapshotterThe overview of lazypull with containerd Remote Snapshotter & Stargz Snapshotter
The overview of lazypull with containerd Remote Snapshotter & Stargz Snapshotter
 
Startup Containers in Lightning Speed with Lazy Image Distribution
Startup Containers in Lightning Speed with Lazy Image DistributionStartup Containers in Lightning Speed with Lazy Image Distribution
Startup Containers in Lightning Speed with Lazy Image Distribution
 
Stargz Snapshotter: イメージのpullを省略してcontainerdでコンテナを高速に起動する
Stargz Snapshotter: イメージのpullを省略してcontainerdでコンテナを高速に起動するStargz Snapshotter: イメージのpullを省略してcontainerdでコンテナを高速に起動する
Stargz Snapshotter: イメージのpullを省略してcontainerdでコンテナを高速に起動する
 
5分で振り返るKubeCon EU 2019:ランタイムとイメージの話題ダイジェスト
5分で振り返るKubeCon EU 2019:ランタイムとイメージの話題ダイジェスト5分で振り返るKubeCon EU 2019:ランタイムとイメージの話題ダイジェスト
5分で振り返るKubeCon EU 2019:ランタイムとイメージの話題ダイジェスト
 

Recently uploaded

NIST Cybersecurity Framework 2.0の変更点整理をしよう
NIST Cybersecurity Framework 2.0の変更点整理をしようNIST Cybersecurity Framework 2.0の変更点整理をしよう
NIST Cybersecurity Framework 2.0の変更点整理をしよう
You&I
 
20240603_SD輪読&座談会#57_kitazaki_______.pdf
20240603_SD輪読&座談会#57_kitazaki_______.pdf20240603_SD輪読&座談会#57_kitazaki_______.pdf
20240603_SD輪読&座談会#57_kitazaki_______.pdf
Ayachika Kitazaki
 
CO2排出量見える化・削減・報告クラウド「アスエネ」サービス紹介_Saleshub.pdf
CO2排出量見える化・削減・報告クラウド「アスエネ」サービス紹介_Saleshub.pdfCO2排出量見える化・削減・報告クラウド「アスエネ」サービス紹介_Saleshub.pdf
CO2排出量見える化・削減・報告クラウド「アスエネ」サービス紹介_Saleshub.pdf
yamamotominami
 
FIWARE Orion Context Broker コンテキスト情報管理 (Orion 4.0.0対応)
FIWARE Orion Context Broker コンテキスト情報管理 (Orion 4.0.0対応)FIWARE Orion Context Broker コンテキスト情報管理 (Orion 4.0.0対応)
FIWARE Orion Context Broker コンテキスト情報管理 (Orion 4.0.0対応)
fisuda
 
Grokking Simplicity探訪
Grokking Simplicity探訪Grokking Simplicity探訪
Grokking Simplicity探訪
Yoshitaka Kawashima
 
アジャイルの30年(Tree Decades of Agileというブログ記事に関する要約)
アジャイルの30年(Tree Decades of Agileというブログ記事に関する要約)アジャイルの30年(Tree Decades of Agileというブログ記事に関する要約)
アジャイルの30年(Tree Decades of Agileというブログ記事に関する要約)
You&I
 
受発注バスターズ説明資料  株式会社batton Saleshub掲載用.pdf
受発注バスターズ説明資料  株式会社batton Saleshub掲載用.pdf受発注バスターズ説明資料  株式会社batton Saleshub掲載用.pdf
受発注バスターズ説明資料  株式会社batton Saleshub掲載用.pdf
ooishi1
 

Recently uploaded (7)

NIST Cybersecurity Framework 2.0の変更点整理をしよう
NIST Cybersecurity Framework 2.0の変更点整理をしようNIST Cybersecurity Framework 2.0の変更点整理をしよう
NIST Cybersecurity Framework 2.0の変更点整理をしよう
 
20240603_SD輪読&座談会#57_kitazaki_______.pdf
20240603_SD輪読&座談会#57_kitazaki_______.pdf20240603_SD輪読&座談会#57_kitazaki_______.pdf
20240603_SD輪読&座談会#57_kitazaki_______.pdf
 
CO2排出量見える化・削減・報告クラウド「アスエネ」サービス紹介_Saleshub.pdf
CO2排出量見える化・削減・報告クラウド「アスエネ」サービス紹介_Saleshub.pdfCO2排出量見える化・削減・報告クラウド「アスエネ」サービス紹介_Saleshub.pdf
CO2排出量見える化・削減・報告クラウド「アスエネ」サービス紹介_Saleshub.pdf
 
FIWARE Orion Context Broker コンテキスト情報管理 (Orion 4.0.0対応)
FIWARE Orion Context Broker コンテキスト情報管理 (Orion 4.0.0対応)FIWARE Orion Context Broker コンテキスト情報管理 (Orion 4.0.0対応)
FIWARE Orion Context Broker コンテキスト情報管理 (Orion 4.0.0対応)
 
Grokking Simplicity探訪
Grokking Simplicity探訪Grokking Simplicity探訪
Grokking Simplicity探訪
 
アジャイルの30年(Tree Decades of Agileというブログ記事に関する要約)
アジャイルの30年(Tree Decades of Agileというブログ記事に関する要約)アジャイルの30年(Tree Decades of Agileというブログ記事に関する要約)
アジャイルの30年(Tree Decades of Agileというブログ記事に関する要約)
 
受発注バスターズ説明資料  株式会社batton Saleshub掲載用.pdf
受発注バスターズ説明資料  株式会社batton Saleshub掲載用.pdf受発注バスターズ説明資料  株式会社batton Saleshub掲載用.pdf
受発注バスターズ説明資料  株式会社batton Saleshub掲載用.pdf
 

OCIv2?!軽量高速なイケてる次世代イメージ仕様の最新動向を抑えよう!

  • 1. Copyright©2019 NTT Corp. All Rights Reserved. OCIv2?! 軽量高速なイケてる次世代イメージ仕様の 最新動向を抑えよう! 2019/7/22(月) 日本電信電話株式会社 ソフトウェアイノベーションセンタ 徳永 航平 CloudNative Days Tokyo 2019 [1B4]
  • 2. 2Copyright©2019 NTT Corp. All Rights Reserved. 自己紹介 名前 徳永 航平 所属 NTT ソフトウェアイノベーションセンタ 興味 コンテナランタイム、イメージ
  • 3. 3Copyright©2019 NTT Corp. All Rights Reserved. 今のランタイム・イメージまわりの様子 目次 1. 2. これからのランタイム・イメージまわりの動向 3. まとめ
  • 4. 4Copyright©2019 NTT Corp. All Rights Reserved. コンテナまわりの標準仕様 コンテナイメージの標準 仕様。コンテナに含める ファイルのレイヤや、メ タデータの仕様およびそ の フ ァ イ ル を 定 義 コンテナの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
  • 5. 5Copyright©2019 NTT Corp. All Rights Reserved. コンテナを取り巻く基礎技術たち ランタイム管理イメージ レジストリ Build Run Ship docker pull docker push docker rundocker build
  • 6. 6Copyright©2019 NTT Corp. All Rights Reserved. 嗚呼素晴らしき哉、コンテナ技術(?) 「取り回しやすさ」がウリのコンテナ(以下はその特長の例) 差分をレイヤ状に保 持し、hashベースの 重複排除により軽量 さを意識したイメー ジフォーマット仕様 クラスタ上で用いる イメージ群を統一的 に格納でき、バー ジョン管理も可能な レジストリ VMのような隔離環 境を持ちながらも、 VMよりも軽量で高 速に起動。 イメージ レジストリ ランタイム
  • 7. 7Copyright©2019 NTT Corp. All Rights Reserved. レイヤ構造で軽量なコンテナイメージ 同じレイヤは共有  カーネルを含まず、軽量  イメージ同士で同一のレイヤがある場合、 それは共有された状態で保存される  つまり重複レイヤを排除できる  ベースイメージを使い回せる  キャッシュが活用できる $ 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の人気イメージ 軽い
  • 8. 8Copyright©2019 NTT Corp. All Rights Reserved. OCIイメージ仕様の概要  Markle tree構造。  各jsonファイル上で子要素となるファイル(blobディレクトリ配下)をハッシュ値で参照  コンテナのrootfsのレイヤは、blobsディレクトリ内のtarball  各ファイル名はハッシュ値であり、同じハッシュ値を持つ(同じ内容の)レイヤ同士は 重複排除され、実体として一つのみが保持されるようになっている。 /index.json Manifest (json) /blobs/sha256/ Manifestファイルで そのイメージに含まれる 各レイヤファイルの ハッシュ値が指定される 各ファイル名は その内容のハッシュ値 実行時の環境変数などの 設定ファイルも含まれる
  • 9. 9Copyright©2019 NTT Corp. All Rights Reserved. クラスタにおける統一的なレジストリ  クラスタ全体の統一的なイメージのソー スになる  シンプルな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
  • 10. 10Copyright©2019 NTT Corp. All Rights Reserved. レジストリ仕様(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)取得 レイヤのハッシュ値
  • 11. 11Copyright©2019 NTT Corp. All Rights Reserved. 高速起動するコンテナ  カーネルを含まず、その分起動が高速 (環境にもよるが大体数秒)  イメージサイズが小さい場合、レジス トリからノードへのイメージ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秒くらい
  • 12. 12Copyright©2019 NTT Corp. All Rights Reserved. $ 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 の準備 コンテナ実行 コンテナの中
  • 13. 13Copyright©2019 NTT Corp. All Rights Reserved. ここまでのまとめ レイヤベースの軽量 なイメージ、クラス タ上で統一されたレ ジストリ、高速な起 動が特徴的。 イメージ、レジスト リ、ランタイムに仕 様が定められ、競争 と互換性が両立して いる。 取り回しがしやすい 標準仕様が定められている
  • 14. 14Copyright©2019 NTT Corp. All Rights Reserved. これからのランタイム・イメージまわりの動向 今のランタイム・イメージまわりの様子 目次 1. 2. 3. まとめ
  • 15. 15Copyright©2019 NTT Corp. All Rights Reserved. 最近話題になり始めている課題感 「取り回しやすさ」は今後保てるのか・・・?! 機械学習や学術分野 など、ユースケース によってはコンテナ が大きくなるのを避 けられない場合があ る。レイヤ同士の重 複排除も効きにくい。 コンテナイメージ以 外にも、コンテナ関 連のデプロイ単位が 様々出現。各種デプ ロイ関連ファイルを 個別に管理する必要 が出てきている。 コンテナ起動時、コ ンテナイメージの pullに時間がかかっ てしまっている。イ メージが大きくなる につれ、その影響は 顕著になるだろう。 イメージ軽く できない問題 デプロイ単位 ありすぎ問題 pullに時間 かかりすぎ問題
  • 16. 16Copyright©2019 NTT Corp. All Rights Reserved. イメージ課題:イメージが軽くできない問題  機械学習フレームワーク等、もはや軽くない(数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 !!
  • 17. 17Copyright©2019 NTT Corp. All Rights Reserved. 0 1 2 3 4 5 6 7 8 9 10 各レイヤの出現回数 イメージ課題:イメージが軽くできない問題  9回出現:3レイヤ  7回出現:1レイヤ  6回出現:1レイヤ  5回出現:2レイヤ  4回出現:8レイヤ  2回出現:23レイヤ  1回出現:285レイヤ そこそこ軽くなっている。 でももうちょっとレイヤが かぶってくれてもいい気が する・・・ 約18.44GB(論理的な合計サイズ) 約13.13GB(実際のサイズ) ※docker system dfより算出 出現回数(回) 出現レイヤ(1本がユニークな1レイヤ)
  • 18. 18Copyright©2019 NTT Corp. All Rights Reserved. レジストリ課題:デプロイ単位ありすぎ問題  Cloud Native関連のデプロイ技術はたくさんある  それらそれぞれで「レジストリ」的なストアサーバを用意する必要がある コンテナ。基本的な実行単位。 OCIで標準仕様の定められたレ ジストリに格納できる。 Kubernetes。yamlファイル群 でKubernetesに指示する。git リポジトリなどで管理する。 Helm Charts。Kubernetesの パッケージマネージャ。Tillerに 格納する。 CNAB。分散アプリケーション のパッケージ仕様。Dockerレジ ストリに格納可能。 Docker Compose。デプロイに yamlファイルを使う。gitリポ ジトリなどで管理する。 and more…
  • 19. 19Copyright©2019 NTT Corp. All Rights Reserved. ランタイム課題: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 ↓論文から引用
  • 20. 20Copyright©2019 NTT Corp. All Rights Reserved. コンテナ仮想化技術低レイヤの最新動向 イメージの肥大を軽減 コンテナ起動時のpull高速化 OCIコミュニティを中心 に次世代イメージフォー マットについて議論され ている、次世代の軽量な イ メ ー ジ 仕 様 。 コンテナ起動時のpullを 高 速 化 す る 手 法 と し て 「lazy-pull」がいろい ろなプロジェクトで議論、 実 装 さ れ て き た 。 OCIv2 lazypull技術 統一的なレジストリ仕様 OCIコミュニティと、各 レジストリのベンダ中心 に議論されている、「な んでも入るレジストリ」 に 関 す る 仕 様 。 OCI Artifact Registry
  • 21. 21Copyright©2019 NTT Corp. All Rights Reserved. 次世代イメージ仕様: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 議論模様
  • 22. 22Copyright©2019 NTT Corp. All Rights Reserved. レイヤよりも細かい単位で重複排除したい レイヤ単位の重複排除 より細かい粒度での重複排除 イメージ内 イメージ間 イメージ内で全く同じレイヤ が出現することはほぼ無い レイヤに含まれるファイル群の 1bitでも違えば違うレイヤ ファイルより細かい粒度なら 「同じカタマリ」が出やすい ファイルより細かい粒度なら 1つのイメージ内でも重複排除されうる
  • 23. 23Copyright©2019 NTT Corp. All Rights Reserved. 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
  • 24. 24Copyright©2019 NTT Corp. All Rights Reserved. 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
  • 25. 25Copyright©2019 NTT Corp. All Rights Reserved. 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を レイヤではなく ファイル単位にする
  • 26. 26Copyright©2019 NTT Corp. All Rights Reserved. これからのランタイム・イメージまわりの動向 今のランタイム・イメージまわりの様子 目次 1. 2. 3. まとめ
  • 27. 27Copyright©2019 NTT Corp. All Rights Reserved. 今、何ができるのか イメージ レジストリ ランタイム  Dockerfileのベスト プラクティスに従う。  レイヤレベルで重複 排除を意識する(無 意味にレイヤの順番 を入れ替えない)  レジストリにコンテナ イメージ以外のものを 格納するためのツール がある:oras: https://github.com/ deislabs/oras  Microsoftが支援して いる  ノード上にイメージ をキャッシュする  イメージをそもそも 小さく作る
  • 28. 28Copyright©2019 NTT Corp. All Rights Reserved. まとめ イメージ軽く できない問題 デプロイ単位 ありすぎ問題 pullに時間 かかりすぎ問題 イメージの肥大を軽減 コンテナ起動時pull高速化 OCIv2 lazypull技術 統一的なレジストリ仕様 OCI Artifact Registry