この資料で解説しているDockerのバージョンは、Docker v18.03.1-ce (moby/moby@05c751b1be6785b4f8a42c412e858508b137c10e)です。

Overview

• コンテナ: ホストから隔離されたプロセスの実行環境のこと。
  • ホストとは異なるnamespace(7)でプロセスを動かす。
  • ホストに接続されているデバイスやネットワーク、動作しているプロセスなどを見えないようにしているのが一般的。
• namespace(7):
  • Linuxに実装された機能
  • 種類:
    • IPC: POSIXメッセージキューなど
    • Mount: ファイルシステム階層
    • Network: network device / routing tableなど
    • PID: PID/PGID/SIDなど
    • UTS: ホストネーム / NISドメイン名
    • User: UID / GID / rootディレクトリなど
• Docker: コンテナを作成・管理するソフトウェアの1つ。
• コンテナの作り方:
  • (Linux上では) Linux Kernelに実装されているcgroupとchrootを使う。
• drivers:
  • Dcoker Engineのプラグイン。
  • 種類:
    • Storage Drivers
    • Volume Drivers
    • Log Drivers

Dockerのバージョン番号からDocker engineのcommit IDを得る

1. docker/docker-ceのbranchやtagを手がかりに、目的のバージョンをチェックアウトする。
2. commit logをさかのぼり、 Merge component 'engine' from から始まるmerge commitを探す。
3. このコミットの、merge元のツリーの最後のコミットのコミットメッセージを確認する。 コミットメッセージに Upstream-commit: から始まる行を探す。

もっといい方法が知りたい。

Dockerとは

コンテナ管理システムの実装の1つ。 Dockerのcore部分をコンポーネント化をするmoby projectが進められている。 ソフトウェアの名称はdockerだけど、ソースコードはmoby projectをベースにしたものが使われている。

Docker Update Channels

deprecatedなchannelを除けば、3つのchannelが存在する。

• nightly
• edge (deprecated)
• test
• stable

Container

広義の意味では、ホストから隔離されたプロセスの実行環境のこと。 コンテナの種類は下記の通り。

• OS containers
  • systemd-nspawn
  • LXC / LXD
  • systemd portable services (?)
• Micro service containers
  • Docker
  • rkt
  • containerd (事実上標準のcontainer runtime)
• Lightweight VM containers
  • Containerの内外でkernelを分離し、より高い隔離レベルにする。 Container as a Serviceでは、基本的にこの方式で提供しているはず。
  • gVisor (by Google)
  • Kata Containers (by OpenStack foundation)
  • Hyper-V container (by Microsoft)
  • Firecracker (by Amazon)

隔離されるリソースの例:

• filesystem
• UID / GIDなど
• network
• アクセス制御ポリシー
  • sVirt - 仮想マシンプロセス間の分離を行い、ハイパバイザーに対する攻撃の影響を緩和する。 Lightweight VM containersに使えるはず。

Docker Container

Security

File System

Life Cycle

so0kさんが書いた図: https://github.com/docker-saigon/blog-hugo/blob/9a36cb4df96f7e036405a0dd384c40b0df6ac4aa/static/img/event_state.png

Docker以外のコンテナ

• LXC Container
  • LXC (Linux Container) が作成・管理できるプロセスの実行環境。
  • namespace(7)
  • selinux profile
  • chroot(7)
  • capability(7)
  • cgroup(7)

Docker Image (Data Format)

Docker Image Specification v1.2.0 に準拠したtarballのこと。

NOTE: 2種類のDocker Image

一般にDocker Imageと呼ばれるのは2種類ある。

1つは /var/lib/docker/image/*/の下に 展開された状態のDocker Image のことである。 docker image lsを実行されたときに表示されるのがこれに相当する。 この状態のDocker Imageの扱われ方は、使用するStorage Driver (Graph Driverとも呼ぶ)によって異なる。 詳細はStorage Driverの項目で解説する。

もう1つは、 データフォーマットとしてのDocker Image である。 docker image exportしたときに出力されるのが、これに相当する。 本項で解説するのは、データフォーマットしてのDocker Imageを解説する。

含まれるデータ

• layers
• metadata
  • タグ
  • 含まれるレイヤーのLayerIDのリスト
  • ビルド手順
  • 環境変数
  • タイムスタンプ
  • etc…

Layer

root filesystemへ加えられた変更のまとまり。 具体的には、ファイル・ディレクトリの追加・更新・削除や、属性の変更などが記録される。 メタデータは含まない。

4種類のID

• Layer Diff ID - 差分を記録したtarballのsha256の値。 [0] [1]
• Layer Chain ID - sha256(parent_chain_id + current_diff_id) [1]
• Image ID - sha256(json file) [0] [1]
• Layer Cache ID - 256bitの乱数を16進数表現にした文字列 (決まった名前が無い気がする・・・)

Tarballの中身

./repositories
./manifest.json
./${IMAGE_ID}.json
./${LAYER_ID}/layer.tar
./${LAYER_ID}/json
./${LAYER_ID}/VERSION

• repositories: Docker Imageにつけられたtag
• manifest.json: コンテナイメージの構成と、レイヤーの一覧を提供する。
• ${IMAGE_ID}.json: Image JSONと呼ばれている。 多分Docker EngineがDocker Imageを管理するときにしよする構造体の内容をダンプしたもの。
• ${LAYER_ID}/layer.tar: layer.tarを参照。
• ${LAYER_ID}/json: Image Layerのメタデータ。下位互換のためだけにある。
• ${LAYER_ID}/VERSION

layer.tar

• root filesystemへ加えられた変更の差分が記録されたtarball。
• 何も変更されていないファイル・ディレクトリは、このtarballに記録されない。
• 追加・更新されたファイルは、tarballに記録される。
• 削除されたファイルとディレクトリは、“.wh.${元の名前}”という空のファイルとして記録される。

$ tar tf ${LAYER_ID}/layer.tar
root/
root/new_file
root/new_empty_directory/
root/.wh.deleted_file
root/.wh.deleted_directory

Layer Diff IDの同一性保証の仕方

tarは、ファイルの格納順序は任意である。 そのため、同じdirectory treeを記録しているのに、出力されたtarballのhash値が異なるという問題が発生しうる。

Dockerでは、格納順序をファイル名順にする(tar --sort=nameに相当)ことでこの問題を回避している [0] [1] [2]

Docker Volume

• volumeのメタデータは、boltDBに保存されている
• 保存場所: /var/lib/docker/volumes/metadata.db
• 保存されているのは、volumeMetadata構造体

Docker Engine

Docker Engine Managed Plugin

• Docker Engine本体にパッチを当てることなく、機能を拡張できる
• Plugins APIが公開されており、現時点ではNetwork/Volume/Auth pluginが作れる
• 例えばNetshareやTwistlock AuthZ Broker

参考: Managed plugin system

Docker Engine API

• RPC-StyleなAPI
• dockerコマンドでできることは全部このAPIを介して行える

参考: Docker Engine API and SDKs

Storage Drivers (Graph Drivers)

• /var/lib/docker/image/の下に展開された、レイヤーを管理する。
• 差分情報のみ記録された層状構造のファイルシステムを実現するためのインターフェース
• Data Volumeの管理は行わない
• graphdriver.Driverインターフェースを実装している。
• コードネームはGraph Driver [1]
• OSごとに、サポートされているstorage driverは異なる [1]

参考: Docker storage drivers

Docker v18.03.1-ce の時点で使えそうなドライバの一覧。 ドキュメントに乗ってないドライバーがありますね。

$ ag 'graphdriver\.Register'
daemon/graphdriver/aufs/aufs.go
67:     graphdriver.Register("aufs", Init)

daemon/graphdriver/btrfs/btrfs.go
41:     graphdriver.Register("btrfs", Init)

daemon/graphdriver/devmapper/driver.go
25:     graphdriver.Register("devicemapper", Init)

daemon/graphdriver/overlay/overlay.go
109:    graphdriver.Register("overlay", Init)

daemon/graphdriver/overlay2/overlay.go
116:    graphdriver.Register(driverName, Init)

daemon/graphdriver/vfs/driver.go
23:     graphdriver.Register("vfs", Init)

daemon/graphdriver/windows/windows.go
57:     graphdriver.Register("windowsfilter", InitFilter)

daemon/graphdriver/zfs/zfs.go
32:     graphdriver.Register("zfs", Init)

daemon/graphdriver/lcow/lcow.go
85:     graphdriver.Register("lcow", InitDriver)

copy

Storage Driverではない。 DirCopy()を提供するだけのパッケージ。 DirCopy()は、タイムスタンプや属性を含めディレクトリ全体をコピーする関数。 cp -aコマンドに相当する動作をするはず。

これを使用しているStorage Driverは、overlayとvfs。

% ag github.com/docker/docker/daemon/graphdriver/copy
daemon/graphdriver/overlay/overlay.go
17:     "github.com/docker/docker/daemon/graphdriver/copy"

daemon/graphdriver/vfs/copy_linux.go
3:import "github.com/docker/docker/daemon/graphdriver/copy"

daemon/graphdriver/copy/copy.go
3:package copy // import "github.com/docker/docker/daemon/graphdriver/copy"

daemon/graphdriver/copy/copy_test.go
3:package copy // import "github.com/docker/docker/daemon/graphdriver/copy"

aufs

いつの間にか非推薦になってた [1]。 overlay2を使おう。

overlay2

• 実装の場所: daemon/Graphdriver/overlay2
• メタデータ: /var/lib/docker/image/overlay2/
• レイヤの中身: /var/lib/docker/overlay2/

/var/lib/docker/overlay2/以下のディレクトリ構造

./${LAYER_CACHE_ID}/diff/
./${LAYER_CACHE_ID}/work/    (optional)
./${LAYER_CACHE_ID}/link     (optional)
./${LAYER_CACHE_ID}/lower
./${LAYER_CACHE_ID}/merged/  (optional)
./l/${LINK_ID}               (symlink to "../${LAYER_CACHE_ID}/diff" directory)

• LINK_ID: 26文字のID。ランダムな文字列をbase32することで生成している [1] [2]。
  LINK_IDを使わなくても実装できそうだし、これを使う意味あるのか？
• diff/: 差分が保存されたディレクトリ。overlayfsのupperdirオプションに指定。
• work/: overlayfsのworkdirオプションに指定する。
• link: LINK_IDが書き込まれたファイル。
• lower: 親レイヤーのLINK_IDが書き込まれたファイル。これを元に、overlayfsのlowerdirオプションに指定する文字列を作成。
• merged/: overlayfsのマウント先ディレクトリ。

操作

• 新規レイヤー作成: ディレクトリとファイル作るだけ。
• マウント: 必要なディレクトリを作成して、overlayfsのマウントオプションを組み立てて、マウントする。コンテナを起動したときに呼び出されるはず。
• アンマウント: このレイヤーが使われなくなったとき、アンマウントしてディレクトリを消す。

Overlayfsは、mount optionに少なくともlowerdir, upperdir, workdirを指定する必要がある。 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/filesystems/overlayfs.txt

btrfs

vfs

union file systemではない。 新しいレイヤを作るときに、親レイヤーの中身を全てコピーしてくるため、実用的なパフォーマンスは出せないと思う。 commit済みのファイルへ多数の変更を加える用途で、コンテナの起動終了が少ないなら、こういうドライバでもいいかもしれない。

ドキュメントにも書いてある通り、テスト目的で使用されている。

$ ag github.com/docker/docker/daemon/graphdriver/vfs --ignore-dir daemon/graphdriver/vfs
daemon/graphdriver/register/register_vfs.go
5:      _ "github.com/docker/docker/daemon/graphdriver/vfs"

integration-cli/docker_cli_external_graphdriver_unix_test.go
16:     "github.com/docker/docker/daemon/graphdriver/vfs"

layer/layer_test.go
15:     "github.com/docker/docker/daemon/graphdriver/vfs"

lcow

Graph-driver for Linux Containers On Windows (LCOW) [1]

Windows分からん(´・ω・`)

Drivers

Volume Drivers

• Docker engine本体に実装されているのはlocal driverのみ。
• これ以外は、volume pluginとして提供されている。

Log Drivers

• ドライバの種類: json-file/fluentd/ec2/gcs/…
• github.com/docker/docker/daemon/loggerパッケージに実装されている。
  • 新しいLog Driverを実装するには、Docker本体に組み込む必要がありそう。

Plugin

Docker Engine Managed Plugin Systemは、Docker Engineが稼働中にpluginの追加・削除を自由に行うことができるシステムのこと。 dockerの本体に手を加えずに、機能を追加できる！

Pluginの開発には、go-plugins-helpersを使うと良さそう。

実装

# Image/Layer/Graphdriver関連
image.Store
image.FSStoreBackend
layer.Store
layer.roLayer
layer.RWLayer
layer.MetadataStore
daemon.graphdriver.New

# networkやcontainer関連
container/container.go
daemon/container_operations.go
daemon/network/
daemon/network.go