Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

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

25,168 views

Published on

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

Published in: Technology
  • Be the first to comment

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

  1. 1. Dockerイメージ管理の内部構造 レッドハット株式会社 v1.1 2015-02-02
  2. 2. 2 Dockerイメージ管理の内部構造 自己紹介  中井悦司(なかいえつじ) – Twitter @enakai00  日々の仕事 – Senior Solution Architect and Cloud Evangelist at Red Hat K.K. 企業システムでオープンソースの活用を希望される お客様を全力でご支援させていただきます。  昔とった杵柄 – 素粒子論の研究(超弦理論とか) – 予備校講師(物理担当) – インフラエンジニア(Unix/Linux専門) 好評発売中!
  3. 3. 3 Dockerイメージ管理の内部構造 Contents  Docker入門  Dockerイメージ管理の内部構造  Dockerイメージの外部保管形式  参考資料
  4. 4. Docker入門
  5. 5. 5 Dockerイメージ管理の内部構造 Dockerに対するRed Hatの貢献  Red Hatの開発協力により、RHEL対応とさらなる機能拡張を継続 – RHEL7での正式サポート – RHELのThin Provisioning機能対応(ディスク性能の向上) – RHEL7のプロセス管理機能(systemd)との統合 – Docker専用Linuxディストリビューション(RHEL Atomic Host)の提供
  6. 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. 7 Dockerイメージ管理の内部構造 Dockerが提供する基本機能 Dockerfile ① Dockerイメージを自動作成 OSイメージ アプリケーション ライブラリー アプリケーション フレームワーク イメージの 作成手順を記載 Docker イメージ OS上にインストール可能な ものはすべてイメージ化可能 ② Dockerイメージを保存・公開 ③ Dockerサーバーに  イメージを配布・実行
  8. 8. 8 Dockerイメージ管理の内部構造 (参考)Linuxコンテナーの仕組み コンテナー 物理サーバー/仮想マシン Linuxカーネル アプリケーション アプリケーション ・・・ 物理サーバー/仮想マシン Linuxカーネル ・・・ コンテナー 通常のLinux環境 コンテナーで分割した環境 コンテナーごとに 見える環境が異なる すべてのアプリケーション から同じ環境が見える  「Linuxコンテナー」は、プロセスグループごとに独立したOS環境を見せる技術 – ローカルディスクの内容(ディレクトリー内のファイル) – ネットワーク環境(NIC、IPアドレス) – CPU、メモリー割り当て ※ Dockerよりもずっと古くから存在する技術です。 アプリケーション アプリケーション
  9. 9. 9 Dockerイメージ管理の内部構造 Dockerとコンテナの関係 コンテナー アプリケーション ディレクトリーツリー Linux上にマウント ルートディレクトリー として割り当て  「Dockerイメージ」の実体は、コンテナーに 割り当てるディスクイメージに、ネットワー ク設定などの環境情報を付与したものにすぎ ません。  Dockerの真の価値は、次のような「イメージ 管理機能」にあります。 – Dockerfile: Dockerイメージを自動作成する仕組み – Docker Hub: Dockerイメージを共有・配布する仕組み Dockerイメージ
  10. 10. Dockerイメージ管理の内部構造
  11. 11. 11 Dockerイメージ管理の内部構造 ローカルでのイメージ保存方式  RHEL7/CentOS7/Atomic Hostでは、ローカルでのイメージ保存に、「Device Mapper Thin- Provisioning (dm-thin)」の機能を利用しています。  dm-thinでは、データ用デバイス(ブロックプール)の上に複数の「論理デバイス」を定義 して利用します。 – dm-thinで作成した論理デバイスをマウントすると、コンテナに見せるルートファイルシステムが 入っています。 – それぞれの論理デバイス対して、実際に書き込みがあった部分のみに一定サイズのブロックが割り当 てられていきます。 データ用デバイス(ブロックプール) メタデータ用 デバイス 論理デバイスへの個々の ブロックの割り当てを記録 Docker イメージ 論理デバイス#1 ・・・ Docker イメージ 論理デバイス#2
  12. 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. 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. 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. 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. 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. 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. 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. 19 Dockerイメージ管理の内部構造 コンテナとイメージのライフサイクル 保存イメージ スナップ ショット コンテナ起動時に スナップショットを作成 × run commit rm プロセス スナップ ショット stop start 保存イメージ コンテナを停止するとプロセスが停止 (ディスクイメージは残っている) コンテナを削除すると ディスクイメージを破棄 ディスクイメージを複製して 保存イメージとして登録 参考:Dockerにおけるコンテナのライフサイクル http://d.hatena.ne.jp/enakai00/20140628/1403933390
  20. 20. 20 Dockerイメージ管理の内部構造 共通のベースイメージから複数イメージを作った場合  CentOS6のイメージから「httpdを追加したイメージ」と「mysqlを追加したイメージ」をそ れぞれ作成して保存すると、内部的には下記のような論理デバイスが構成されます。 CentOS6 論理デバイス#1 CentOS6 + mysql 論理デバイス#3 CentOS6 + httpd 論理デバイス#2 CentOS6の コンテンツ httpdの 追加ファイル msyqlの 追加ファイル
  21. 21. 21 Dockerイメージ管理の内部構造 イメージの親子関係  ローカルに保存したイメージは、どのイメージのスナップショットから作成されたのかとい う親子関係のツリー情報をメタデータとして保存しています。 – それぞれのイメージは、論理デバイスとしては独立しているので、サーバー上で使用する上では、親 子関係の情報は不要です。このようなツリー情報を保持している理由は、この後で・・・。 CentOS6 論理デバイス#1 CentOS6 + mysql 論理デバイス#3 CentOS6 + httpd 論理デバイス#2 親のイメージ 親のイメージ
  22. 22. Dockerイメージの外部保管形式
  23. 23. 23 Dockerイメージ管理の内部構造 Dockerイメージのexport/importとsave/loadの違い  Dockerイメージをアーカイブファイルとして取り出して、他のDockerサーバーに持ち運ぶ方 法には、「export/import」と「save/load」の2種類の方法があります。 CentOS6 論理デバイス#1 CentOS6 + mysql 論理デバイス#3 CentOS6 + httpd 論理デバイス#2 save_image.tar export_image.tar # docker save # docker export これらにはどんな違いがあるのでしょうか?
  24. 24. 24 Dockerイメージ管理の内部構造 exportイメージは「単なるtarアーカイブ」  「docker export」でイメージを取り出すと、論理デバイスをローカルマウントして、その中 のルートファイルシステムをまるごとtarコマンドで固めたものが得られます。 – イメージの親子関係や各種メタデータはすべて失われます。 CentOS6 論理デバイス#1 CentOS6 + mysql 論理デバイス#3 CentOS6 + httpd 論理デバイス#2 export_image.tar # docker export ローカルマウント tarコマンドでアーカイブ
  25. 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. 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. 27 Dockerイメージ管理の内部構造 CentOS6 + httpd saveイメージからの論理デバイスの復元  saveイメージを「docker load」で読み込むと、次のような流れで、最初と同じ論理デバイス の状態が再現されます。 – 空の論理デバイス「CentOS6」を作成して、ベースイメージのアーカイブを書き出します。 – 「CentOS6」のスナップショットコピー「CentOS6+httpd」を作成して、差分ファイルのアーカイ ブを上書きで書き出します。  それぞれのイメージには、固有のUUIDが割り当てられているので、共通のベースイメージを 持つ複数のsaveイメージを復元した場合、同じベースイメージが重複して再現されることは ありません。 CentOS6 httpd.tarbase_image.tar save_image.tar ① 復元 ② スナップショット作成 ③ 差分を上書き
  28. 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. 29 Dockerイメージ管理の内部構造 exportイメージのインポート  exportイメージを「docker import」で読み込んだ場合は、新規の論理デバイスにルート ファイルシステムの内容を展開するだけです。 – ベースイメージを共有することができないので、ディスク容量の節約はできなくなります。  一方、Dockerを使用しない普通の物理サーバーや仮想マシンのルートファイルシステムを tarで固めて、無理やりインポートすることも可能です。 http://www.slideshare.net/Yuryu/ec2linux
  30. 30. 参考資料
  31. 31. 31 Dockerイメージ管理の内部構造 参考資料  Dockerイメージのレイヤー構造について – http://d.hatena.ne.jp/enakai00/20140802/1406958412  Docker専用のLinux - RHEL Atomic Hostが登場!(パート1) – http://www.school.ctc-g.co.jp/columns/nakai/nakai58.html  Docker専用のLinux - RHEL Atomic Hostが登場!(パート2) – http://www.school.ctc-g.co.jp/columns/nakai/nakai59.html
  32. 32. Thank you

×