ver1.0 公開 ver1.1 ディスクイメージを直接操作する方法を追加 (2015/02/20)

1. Dockerイメージ管理の内部構造
レッドハット株式会社
v1.1 2015-02-02

2. 2
Dockerイメージ管理の内部構造
自己紹介
 中井悦司（なかいえつじ）
– Twitter @enakai00
 日々の仕事
– Senior Solution Architect and
Cloud Evangelist at Red Hat K.K.
企業システムでオープンソースの活用を希望される
お客様を全力でご支援させていただきます。
 昔とった杵柄
– 素粒子論の研究（超弦理論とか）
– 予備校講師（物理担当）
– インフラエンジニア（Unix/Linux専門）
好評発売中！

3. 3
Dockerイメージ管理の内部構造
Contents
 Docker入門
 Dockerイメージ管理の内部構造
 Dockerイメージの外部保管形式
 参考資料

4. Docker入門

5. 5
Dockerイメージ管理の内部構造
Dockerに対するRed Hatの貢献
 Red Hatの開発協力により、RHEL対応とさらなる機能拡張を継続
– RHEL7での正式サポート
– RHELのThin Provisioning機能対応（ディスク性能の向上）
– RHEL7のプロセス管理機能（systemd）との統合
– Docker専用Linuxディストリビューション（RHEL Atomic Host）の提供

6. 6
Dockerイメージ管理の内部構造
RHEL Atomic Hostとは？
 Red Hat Enterprise Linux 7をベースに、Dockerの実行環境として最適化
したLinuxディストリビューション
– Kubernetesで管理するための前提パッケージを追加
– Docker用に最適化したディスク構成でインストール
• Dockerイメージ保存領域を専用の論理ボリュームで構成
– Docker用のtunedプロファイル提供
– rpm-ostreeによる一括アップデート機能
• RPMパッケージの個別管理が不要
• アップデート後のロールバック（以前のバージョンへの復帰）が可能
 アップストリームの開発プロジェクトは「PROJECT ATOMIC」
– http://www.projectatomic.io/

7. 7
Dockerイメージ管理の内部構造
Dockerが提供する基本機能
Dockerfile
① Dockerイメージを自動作成
OSイメージ
アプリケーション
ライブラリー
アプリケーション
フレームワーク
イメージの
作成手順を記載
Docker
イメージ
OS上にインストール可能な
ものはすべてイメージ化可能
② Dockerイメージを保存・公開
③ Dockerサーバーに
イメージを配布・実行

8. 8
Dockerイメージ管理の内部構造
（参考）Linuxコンテナーの仕組み
コンテナー
物理サーバー／仮想マシン
Linuxカーネル
アプリケーション
アプリケーション
・・・
物理サーバー／仮想マシン
Linuxカーネル
・・・
コンテナー
通常のLinux環境 コンテナーで分割した環境
コンテナーごとに
見える環境が異なる
すべてのアプリケーション
から同じ環境が見える
 「Linuxコンテナー」は、プロセスグループごとに独立したOS環境を見せる技術
– ローカルディスクの内容（ディレクトリー内のファイル）
– ネットワーク環境（NIC、IPアドレス）
– CPU、メモリー割り当て
※ Dockerよりもずっと古くから存在する技術です。
アプリケーション
アプリケーション

9. 9
Dockerイメージ管理の内部構造
Dockerとコンテナの関係
コンテナー
アプリケーション
ディレクトリーツリー
Linux上にマウント
ルートディレクトリー
として割り当て
 「Dockerイメージ」の実体は、コンテナーに
割り当てるディスクイメージに、ネットワー
ク設定などの環境情報を付与したものにすぎ
ません。
 Dockerの真の価値は、次のような「イメージ
管理機能」にあります。
– Dockerfile：
Dockerイメージを自動作成する仕組み
– Docker Hub：
Dockerイメージを共有・配布する仕組み
Dockerイメージ

10. Dockerイメージ管理の内部構造

11. 11
Dockerイメージ管理の内部構造
ローカルでのイメージ保存方式
 RHEL7/CentOS7/Atomic Hostでは、ローカルでのイメージ保存に、「Device Mapper Thin-
Provisioning (dm-thin)」の機能を利用しています。
 dm-thinでは、データ用デバイス（ブロックプール）の上に複数の「論理デバイス」を定義
して利用します。
– dm-thinで作成した論理デバイスをマウントすると、コンテナに見せるルートファイルシステムが
入っています。
– それぞれの論理デバイス対して、実際に書き込みがあった部分のみに一定サイズのブロックが割り当
てられていきます。
データ用デバイス（ブロックプール）
メタデータ用
デバイス
論理デバイスへの個々の
ブロックの割り当てを記録
Docker
イメージ
論理デバイス#1 ・・・
Docker
イメージ
論理デバイス#2

12. 12
Dockerイメージ管理の内部構造
 Device Mapperはブロックデバイス（/dev/sdXなど）の上にソフトウェアのWrapperを被せ
て、さまざまな機能拡張を行ったブロックデバイスを作成する仕組みです。次のような機能
拡張を行うモジュールがあります。
– ソフトウェアRAID（dm-raid）
– マルチパスアクセス（dm-multipath）
– 暗号化（dm-crypt）
– アクセス遅延挿入（dm-delay）
– etc...
（参考）Device Mapperとは？
/dev/sda /dev/sdb
/dev/dm1
ミラーリング
dm-raid
/dev/sda
/dev/dm1
dm-crypt
暗号化／復号化
/dev/sda
/dev/dm1
dm-delay
遅延挿入

13. 13
Dockerイメージ管理の内部構造
 論理デバイスの管理情報は、下記のJSONファイルに記録されています。
– /var/lib/docker/devicemapper/metadata/<Image ID>
– 特に、デバイスID「0」の論理デバイスは、最初にDockerサービスを起動した際に10GBで作成され、
ファイルシステムとしてフォーマットされます。Docker Hubからイメージをダウンロードすると、こ
の論理デバイスのスナップショットを作成して、空のファイルシステムを用意して、その中にダウン
ロードファイルを展開します。（そのため、すべての論理デバイスのサイズは10GBになります。）
DockerにおけるThin Povisioningの利用方式
# docker images enakai/httpd
REPOSITORY TAG IMAGE ID CREATED VIRTUAL SIZE
enakai/httpd ver1.0 d3d92adfcafb 36 hours ago 206.6 MB
# cat /var/lib/docker/devicemapper/metadata/d3d92adfcafb* | python -mjson.tool
{
"device_id": 72,
"initialized": false,
"size": 10737418240,
"transaction_id": 99
}
# cat /var/lib/docker/devicemapper/metadata/base | python -mjson.tool
{
"device_id": 0,
"initialized": true,
"size": 10737418240,
"transaction_id": 1
}

14. 14
Dockerイメージ管理の内部構造
 dmsetupコマンドでネイティブにDevice Mapperを操作すると、Dockerが管理するディスク
イメージを直接にマウントして内容を確認することができます。手順の例は次の通りです。
– 前ページの方法で、対象のディスクイメージのIDから、対応する「device_id」と「size」の値を確認
します。また、次のコマンドで、プールの名称（この例では「docker-252:3-130516-pool」）を確
認します。
– 簡単のため、確認した情報を変数にセットしておきます。
Dockerのディスクイメージを直接操作する方法 (1)
# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
...
loop0 7:0 0 100G 0 loop
└─docker-252:3-130516-pool 253:0 0 100G 0 dm
loop1 7:1 0 2G 0 loop
└─docker-252:3-130516-pool 253:0 0 100G 0 dm
# device_id=72
# size=10737418240
# pool=docker-252:3-130516-pool

15. 15
Dockerイメージ管理の内部構造
– 次のコマンドで論理デバイスを有効化して、マウントします。下記の「rootfs」以下がコンテナから
みえるルートファイルシステムになります。
– 最後に次のコマンドでアンマウントして、論理デバイスを無効化しておきます。
※ この手順でイメージ内のファイルを修正することは、Docker的には想定外の使い方ですので、
予想外の問題が起きる可能性はあるかも知れません。
– 参考：https://www.kernel.org/doc/Documentation/device-mapper/thin-provisioning.txt
Dockerのディスクイメージを直接操作する方法 (2)
# dmsetup create myvol --table "0 $(($size / 512)) thin /dev/mapper/$pool $device_id"
# lsblk
...
loop0 7:0 0 100G 0 loop
└─docker-252:3-130516-pool 253:0 0 100G 0 dm
└─myvol 253:1 0 10G 0 dm
loop1 7:1 0 2G 0 loop
└─docker-252:3-130516-pool 253:0 0 100G 0 dm
└─myvol 253:1 0 10G 0 dm
# mount /dev/mapper/myvol /mnt
# ls /mnt
id lost+found rootfs
# cat /mnt/rootfs/var/www/html/index.html
Hello, World!
# umount /mnt
# dmsetup remove myvol

16. 16
Dockerイメージ管理の内部構造
（参考）データ用デバイスの構成例 (1)
 RHEL7/CentOS7で普通にDockerをインストールした場合は、「100GBのスパース形式の
ディスクイメージファイル」をループバックマウントしたものが「データ用デバイス」とし
て使用されます。
– ちょっといけてません。。。。
# ls -lh /var/lib/docker/devicemapper/devicemapper/
合計 1.2G
-rw-------. 1 root root 100G 5月 11 21:37 data
-rw-------. 1 root root 2.0G 5月 11 22:05 metadata
# losetup
NAME SIZELIMIT OFFSET AUTOCLEAR RO BACK-FILE
/dev/loop0 0 0 1 0 /var/lib/docker/devicemapper/devicemapper/data
/dev/loop1 0 0 1 0 /var/lib/docker/devicemapper/devicemapper/metadata
# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
...
loop0 7:0 0 100G 0 loop
└─docker-252:3-130516-pool 253:0 0 100G 0 dm
loop1 7:1 0 2G 0 loop
└─docker-252:3-130516-pool 253:0 0 100G 0 dm
データ用デバイス
メタデータ用デバイス

17. 17
Dockerイメージ管理の内部構造
（参考）データ用デバイスの構成例 (2)
 RHEL Atomic Hostでは、ルートファイルシステム（3G）、スワップ領域などを除いた残り
が、すべてデータ用デバイスとして利用されます。
– ディスクイメージファイルではなく、専用の論理ボリュームをデータ用デバイスとして使用します。
-bash-4.2# lvs
LV VG Attr LSize Pool Origin Data% Move Log Cpy%Sync Convert
docker-data rah_atomic01 -wi-ao---- 26.64g
docker-meta rah_atomic01 -wi-ao---- 36.00m
root rah_atomic01 -wi-ao---- 3.00g
swap rah_atomic01 -wi-ao---- 2.03g
-bash-4.2# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
vda 252:0 0 32G 0 disk
|-vda1 252:1 0 300M 0 part /boot
`-vda2 252:2 0 31.7G 0 part
|-rah_atomic01-swap 253:0 0 2G 0 lvm [SWAP]
|-rah_atomic01-root 253:1 0 3G 0 lvm /sysroot
|-rah_atomic01-docker--meta 253:2 0 36M 0 lvm
| `-docker-253:1-5320663-pool 253:4 0 26.7G 0 dm
`-rah_atomic02-docker--data 253:3 0 26.7G 0 lvm
`-docker-253:1-5320663-pool 253:4 0 26.7G 0 dm
データ用デバイス
メタデータ用デバイス

18. 18
Dockerイメージ管理の内部構造
dm-thinのスナップショット機能について
 Dockerは、Dockerイメージのスナップショットコピーを多用します（次ページ参照）が、
RHEL7/CentOS7/Atomic HostのDockerでは、dm-thinのスナップショット機能を用いて、
コピーを作成します。
– 差分領域のみに新しいブロックが割り当てるため高速にコピーを取得すると共に、ディスク使用量を
節約する効果があります。
A B C
スナップショット作成直後
A B C A B C
ブロックプール
・・・ A B C D
A B C A B D
書き込み発生
・・・
ブロックプール
書き込んだ部分は
新しいブロックを割り当てる

19. 19
Dockerイメージ管理の内部構造
コンテナとイメージのライフサイクル
保存イメージ
スナップ
ショット
コンテナ起動時に
スナップショットを作成
×
run
commit
rm
プロセス
スナップ
ショット
stop
start
保存イメージ
コンテナを停止するとプロセスが停止
（ディスクイメージは残っている）
コンテナを削除すると
ディスクイメージを破棄
ディスクイメージを複製して
保存イメージとして登録
参考：Dockerにおけるコンテナのライフサイクル
http://d.hatena.ne.jp/enakai00/20140628/1403933390

20. 20
Dockerイメージ管理の内部構造
共通のベースイメージから複数イメージを作った場合
 CentOS6のイメージから「httpdを追加したイメージ」と「mysqlを追加したイメージ」をそ
れぞれ作成して保存すると、内部的には下記のような論理デバイスが構成されます。
CentOS6
論理デバイス#1
CentOS6
+ mysql
論理デバイス#3
CentOS6
+ httpd
論理デバイス#2
CentOS6の
コンテンツ
httpdの
追加ファイル
msyqlの
追加ファイル

21. 21
Dockerイメージ管理の内部構造
イメージの親子関係
 ローカルに保存したイメージは、どのイメージのスナップショットから作成されたのかとい
う親子関係のツリー情報をメタデータとして保存しています。
– それぞれのイメージは、論理デバイスとしては独立しているので、サーバー上で使用する上では、親
子関係の情報は不要です。このようなツリー情報を保持している理由は、この後で・・・。
CentOS6
論理デバイス#1
CentOS6
+ mysql
論理デバイス#3
CentOS6
+ httpd
論理デバイス#2
親のイメージ 親のイメージ

22. Dockerイメージの外部保管形式

23. 23
Dockerイメージ管理の内部構造
Dockerイメージのexport/importとsave/loadの違い
 Dockerイメージをアーカイブファイルとして取り出して、他のDockerサーバーに持ち運ぶ方
法には、「export/import」と「save/load」の２種類の方法があります。
CentOS6
論理デバイス#1
CentOS6
+ mysql
論理デバイス#3
CentOS6
+ httpd
論理デバイス#2
save_image.tar export_image.tar
# docker save # docker export
これらにはどんな違いがあるのでしょうか？

24. 24
Dockerイメージ管理の内部構造
exportイメージは「単なるtarアーカイブ」
 「docker export」でイメージを取り出すと、論理デバイスをローカルマウントして、その中
のルートファイルシステムをまるごとtarコマンドで固めたものが得られます。
– イメージの親子関係や各種メタデータはすべて失われます。
CentOS6
論理デバイス#1
CentOS6
+ mysql
論理デバイス#3
CentOS6
+ httpd
論理デバイス#2
export_image.tar
# docker export
ローカルマウント
tarコマンドでアーカイブ

25. 25
Dockerイメージ管理の内部構造
saveイメージは「親子関係を再現可能な分割tarファイル」
 「docker save」でイメージを取り出すと、親子関係を再現できるように複数のtarアーカイ
ブが作成されます。下図の例では、次のような順序になります。
– ベースイメージ（CentOS6）をローカルマウントして、ルートファイルシステムをtarアーカイブに
します。
– 派生したイメージ（CentOS6+httpd）をローカルマウントして、「ベースイメージから追加・変更
されたファイルのみを抽出したtarアーカイブ」を作成します。
– それぞれのイメージの親子関係やメタデータを記載したファイルを作成します。
– 以上のすべてを1つのtarアーカイブにまとまて出力します。
CentOS6
CentOS6
+ httpd
httpd.tar
# docker save
ローカルマウント
base_image.tar
ローカルマウント
ルートファイルシステムを
まとめてアーカイブ
ベースイメージとの
差分ファイルのみをアーカイブ
save_image.tar すべてを1つにまとめたtarアーカイブ

26. 26
Dockerイメージ管理の内部構造
saveイメージは「親子関係を再現可能な分割tarファイル」
 saveイメージの内容を実際に確認した例です。
– layer.tarは、そのレイヤーのコンテンツを含むアーカイブファイルです。
– jsonは、そのレイヤーの親子関係やメタデータを記載したファイルです。
# docker save hoge > hoge.tar
# tar -tvf hoge.tar
drwx------ 0/0 0 2014-08-02 14:49 ./
drwxr-xr-x 0/0 0 2014-08-02 14:49 34e94e67e63a0f079d9336b3c2a52e814d138e5b3f1f614a0cfe273814ed7c0a/
-rw-r--r-- 0/0 3 2014-08-02 14:49 34e94e67e63a0f079d9336b3c2a52e814d138e5b3f1f614a0cfe273814ed7c0a/VERSION
-rw-r--r-- 0/0 1565 2014-08-02 14:49 34e94e67e63a0f079d9336b3c2a52e814d138e5b3f1f614a0cfe273814ed7c0a/json
-rw-r--r-- 0/0 1024 2014-08-02 14:49 34e94e67e63a0f079d9336b3c2a52e814d138e5b3f1f614a0cfe273814ed7c0a/layer.tar
drwxr-xr-x 0/0 0 2014-08-02 14:49 511136ea3c5a64f264b78b5433614aec563103b4d4702f3ba7d4d2698e22c158/
-rw-r--r-- 0/0 3 2014-08-02 14:49 511136ea3c5a64f264b78b5433614aec563103b4d4702f3ba7d4d2698e22c158/VERSION
-rw-r--r-- 0/0 585 2014-08-02 14:49 511136ea3c5a64f264b78b5433614aec563103b4d4702f3ba7d4d2698e22c158/json
-rw-r--r-- 0/0 1536 2014-08-02 14:49 511136ea3c5a64f264b78b5433614aec563103b4d4702f3ba7d4d2698e22c158/layer.tar
drwxr-xr-x 0/0 0 2014-08-02 14:49 aff9664bf7d8eed96731fffc05a2002306e09ca5e22290354eeca6fa577fe8b2/
-rw-r--r-- 0/0 3 2014-08-02 14:49 aff9664bf7d8eed96731fffc05a2002306e09ca5e22290354eeca6fa577fe8b2/VERSION
-rw-r--r-- 0/0 1285 2014-08-02 14:49 aff9664bf7d8eed96731fffc05a2002306e09ca5e22290354eeca6fa577fe8b2/json
-rw-r--r-- 0/0 3584 2014-08-02 14:49 aff9664bf7d8eed96731fffc05a2002306e09ca5e22290354eeca6fa577fe8b2/layer.tar
drwxr-xr-x 0/0 0 2014-08-02 14:49 b1bd49907d559b703c2b7c1b0d6f120b5182440f7ac5f08636625d328e96f1ef/
-rw-r--r-- 0/0 3 2014-08-02 14:49 b1bd49907d559b703c2b7c1b0d6f120b5182440f7ac5f08636625d328e96f1ef/VERSION
-rw-r--r-- 0/0 1574 2014-08-02 14:49 b1bd49907d559b703c2b7c1b0d6f120b5182440f7ac5f08636625d328e96f1ef/json
-rw-r--r-- 0/0 222638592 2014-08-02 14:49 b1bd49907d559b703c2b7c1b0d6f120b5182440f7ac5f08636625d328e96f1ef/layer.tar
-rw-r--r-- 0/0 86 2014-08-02 14:49 repositories
ベースイメージなのでサイズが大きい
差分イメージなのでサイズが小さい

27. 27
Dockerイメージ管理の内部構造
CentOS6
+ httpd
saveイメージからの論理デバイスの復元
 saveイメージを「docker load」で読み込むと、次のような流れで、最初と同じ論理デバイス
の状態が再現されます。
– 空の論理デバイス「CentOS6」を作成して、ベースイメージのアーカイブを書き出します。
– 「CentOS6」のスナップショットコピー「CentOS6+httpd」を作成して、差分ファイルのアーカイ
ブを上書きで書き出します。
 それぞれのイメージには、固有のUUIDが割り当てられているので、共通のベースイメージを
持つ複数のsaveイメージを復元した場合、同じベースイメージが重複して再現されることは
ありません。
CentOS6
httpd.tarbase_image.tar
save_image.tar
① 復元
② スナップショット作成
③ 差分を上書き

28. 28
Dockerイメージ管理の内部構造
Docker Hubのイメージ保存形式
 Docker Hubにイメージをアップロードすると、次のような処理が行われます。
– saveイメージの作成と同じ流れで、それぞれのレイヤーの「差分tarファイル」を作成します。
– それぞれの「差分tarファイル」を固有のUUIDと共にDocker Hubにアップロードして登録します。
– Docker Hubにすでに存在するファイル（UUIDで識別）は、アップロードをスキップします。
 つまり、Docker Hubは「差分tarファイル」の巨大な保管庫として機能しています。
– 複数のユーザーが、Docker Hubから取得した「CentOS6」のベースイメージをもとにさまざまな派生
イメージを作って、Docker Hubにアップロードした場合、「CentOS6」のベースイメージは、あくま
で1つだけ存在することになります。
CentOS6
（ベースイメージ）
httpd
（差分tarファイル）
mysql
（差分tarファイル）
# docker pull
CentOS6
CentOS6
+httpd
# docker push
# docker pull
CentOS6
CentOS6
+mysql
# docker push
Docker HubユーザーA ユーザーB

29. 29
Dockerイメージ管理の内部構造
exportイメージのインポート
 exportイメージを「docker import」で読み込んだ場合は、新規の論理デバイスにルート
ファイルシステムの内容を展開するだけです。
– ベースイメージを共有することができないので、ディスク容量の節約はできなくなります。
 一方、Dockerを使用しない普通の物理サーバーや仮想マシンのルートファイルシステムを
tarで固めて、無理やりインポートすることも可能です。
http://www.slideshare.net/Yuryu/ec2linux

30. 参考資料

31. 31
Dockerイメージ管理の内部構造
参考資料
 Dockerイメージのレイヤー構造について
– http://d.hatena.ne.jp/enakai00/20140802/1406958412
 Docker専用のLinux - RHEL Atomic Hostが登場！（パート１）
– http://www.school.ctc-g.co.jp/columns/nakai/nakai58.html
 Docker専用のLinux - RHEL Atomic Hostが登場！（パート２）
– http://www.school.ctc-g.co.jp/columns/nakai/nakai59.html

32. Thank you