More than 5 years have passed since last update.

Dockerコンテナとイメージを簡易的に理解する

Last updated at 2017-12-16Posted at 2017-12-15

Dockerは便利なので開発には毎度使用していますが、インフラ系の人間ではないのでDockerの仮想化技術の仕組みを殆ど理解していなかったので社内勉強会を期に調べてみてなんとなくわかった気がしたのでまとめておきます。

調べる前までの私の理解度

コンテナで手早くlinux環境を自由に作成できる
同じ環境を作ることが出来る
コンテナはプロセスで実行されている？
Dockerの説明の際に必ずと言ってよい程出てくる例の構造画像
例の構造画像のおかげでVMと比べて軽いらしい
コンテナのCPUやメモリはよくわからないけどDockerエンジンがよしなにやってくれているのだろうか？

Dockerコンテナの主な技術

cgroups（プロセスをグループ化してリソース(CPU、メモリ、ディスクI/Oなど)の利用をコントロール(制限・隔離)するLinuxカーネルの機能）
namespace（ホスト名やPID空間などのカーネル/OSが扱うリソースをコントロール(制限・隔離)するLinuxカーネルの機能）
chroot (現在のプロセスとその子プロセス群に対してルートディレクトリを変更する操作である。ルートディレクトリを別のディレクトリに変更されたプロセスは、その範囲外のファイルにはアクセスできなくなる)

上記を使用してコンテナを実現している。
RHEL7のDockerでは、systemdと連携してcgroupsの制御を行っているらしい。

cgroups系のコンテナ技術

LXC
systemd-nspawn(systemdには軽量コンテナを建てる機能がなぜか備わっている。)
Docker

イメージとコンテナには実体がある様子

ホストOS　Archlinux
ファイルシステムがbtrfsの場合

/var/lib/docker/btrfs/subvolume/<ハッシュ値のフォルダ>
この中に実体が存在していた。

ホストOS　DockerToolBox
ファイルシステムがaufsの場合

/var/lib/docker/aufs/diff/<ハッシュ値のフォルダ>
この中に実体が存在していた。

ベースイメージっぽいハッシュ値のフォルダの中身

# ls -l
total 68
-rw-r--r--    1 root     root         11958 Nov 28 16:08 anaconda-post.log
lrwxrwxrwx    1 root     root             7 Nov 28 16:07 bin -> usr/bin
drwxr-xr-x    2 root     root          4096 Nov 28 16:07 dev
drwxr-xr-x   47 root     root          4096 Nov 28 16:08 etc
drwxr-xr-x    2 root     root          4096 Nov  5  2016 home
lrwxrwxrwx    1 root     root             7 Nov 28 16:07 lib -> usr/lib
lrwxrwxrwx    1 root     root             9 Nov 28 16:07 lib64 -> usr/lib64
drwxr-xr-x    2 root     root          4096 Nov  5  2016 media
drwxr-xr-x    2 root     root          4096 Nov  5  2016 mnt
drwxr-xr-x    2 root     root          4096 Nov  5  2016 opt
drwxr-xr-x    2 root     root          4096 Nov 28 16:07 proc
dr-xr-x---    2 root     root          4096 Nov 28 16:08 root
drwxr-xr-x   10 root     root          4096 Nov 28 16:08 run
lrwxrwxrwx    1 root     root             8 Nov 28 16:07 sbin -> usr/sbin
drwxr-xr-x    2 root     root          4096 Nov  5  2016 srv
drwxr-xr-x    2 root     root          4096 Nov 28 16:07 sys
drwxrwxrwt    7 root     root          4096 Nov 28 16:08 tmp
drwxr-xr-x   13 root     root          4096 Nov 28 16:07 usr
drwxr-xr-x   18 root     root          4096 Nov 28 16:07 var

Linuxの/が再現されていた。

ホストによって/var/lib/docker/配下の構造が異なるのはDockerエンジンがディストリビューションの標準ストレージ・ドライバを使ってよしなにやってくれているから。
Dockerをインストールする時、システム上の設定に応じてデフォルトのストレージ・ドライバを選択します。

イメージとコンテナの実体

AUFSストレージ・ドライバ時の動作例

イメージ・レイヤと各コンテナは、/var/lib/docker/aufs/diff/<イメージID>または<コンテナ ID>ディレクトリ以下に保管されます。

Docker 1.10 以降では、イメージ・レイヤ ID コンテナ ID はディレクトリ名と一致しません。

イメージ

１つのイメージが複数のレイヤをもつので１つのイメージに対して複数のディレクトリを持つ。
docker commit で新しいイメージを作る度にディレクトリが増える様子でした。
コミット時にイメージ・レイヤ（差分）が上層に積み上げられていく感じのようです。

イメージ・レイヤを統合することでイメージを再現している。

コンテナ

コンテナを作成すると以下の2つができた。

/var/lib/docker/aufs/diff/75e8cf47a9daf6b7a52d78704e408f102fe2006fea2a8218c65434af4a42bbc7-init

/var/lib/docker/aufs/diff/75e8cf47a9daf6b7a52d78704e408f102fe2006fea2a8218c65434af4a42bbc7

-initの方にはコンテナ作成時のhost設定等が入っていた。
もう一つの方にはコンテナに入って修正したもの等が入る。
2つのディレクトリは共にベースイメージの様にLinuxの/が再現されている様子はなかった。
（多分run時の時に作成されたイメージのスナップショット（runでの変更差分）がこの２つのディレクトリといった感じになるのでしょう）
１つのコンテナは2つのディレクトリを持つようです。

この-initの無い方のディレクトリは AUFS によってコンテナの最上位の書き込みレイヤとして積み重ねられるものであり、コンテナに対する全ての変更が保管されます。コンテナが停止しても、このディレクトリは存在し続けます。つまり、コンテナを再起動しても、その変更内容は失われません。コンテナが削除された時のみ、このディレクトリは削除されます。

コンテナ内でファイルを変更するとコピーオンライトでコピーされ差分のみ管理している様子でした。