daemon¶

デーモンのストレージ・ドライバ用オプション¶

Docker デーモンはイメージ・レイヤ用途に、様々に異なるストレージ・ドライバの利用をサポートします。ドライバは、 aufs 、 devicemapper 、 btrfs 、 zfs 、 overlay です。

最も古いドライバは aufs であり、Linux カーネルに対するパッチ群が基になっています。ドライバにはメイン・カーネルにマージされなかったコードも含まれます。そのため、深刻なカーネルのクラッシュを引き起こすのが分かっています。一方で、 aufs はコンテナの共有実行と共有ライブラリ・メモリが使える唯一のストレージ・ドライバです。そのため、同じプログラムやライブラリで数千ものコンテナを実行する時は便利な選択でしょう。

devicemapper ドライバはシン・プロビジョニング（thin provisioning）とコピー・オン・ライト（Copy on Write）スナップショットを使います。devicemapper の各グラフ（graph）がある典型的な場所は /var/lib/docker/devicemapper です。シン（thin）プールは２つのブロックデバイス上に作ります。１つはデータで、もう１つはメタデータです。デフォルトでは、別々のファイルとして自動作成したループバックのマウントを元に、これらのブロック・デバイスを自動的に作成します。セットアップのカスタマイズ方法は、以下にある ストレージ・ドライバのオプション をご覧ください。オプションを使わない設定方法は jpetazzo/Resizing Docker containers with the Device Mapper plugin の記事に説明があります。

btrfs ドライバは docker build が非常に高速です。しかし、 devicemapper のようにデバイス間の実行メモリを共有しません。使うには docker daemon -s btrfs -g /mnt/btrfs_partition を実行します。

zfs ドライバは btrfs ほど速くありませんが、安定さのためレコードを長く追跡します。 Single Copy ARC のおかげで、クローン間の共有ブロックを１度キャッシュします。使うには docker daemon -s zfs を指定します。異なる zfs ファイルシステムセットを選択するには、 zfs.fsname オプションを ストレージ・ドライバのオプション で指定します。

overlay は非常に高速なユニオン・ファイル・システムです。ようやく Linux カーネル 3.18.0 でメインにマージされました。使うには docker daemon -s overlay を指定します。

ストレージ・ドライバのオプション¶

個々のストレージドライバは --storage-opt フラグでオプションを設定できます。 devicemapper 用のオプションは dm で始まり、 zfs 用のオプションは zfs で始まります。

• dm.thinpooldev

シン・プール用に使うカスタム・ブロックストレージ・デバイスを指定します。

ブロック・デバイスをデバイスマッパー・ストレージに指定する場合は、lvm を使うシン・プール・ボリュームの作成・管理がベストです。その後、このボリュームは Docker により、イメージまたはコンテナで、排他的なスナップショット用ボリュームを作成するために使われます。

シン・プールの管理を Docker Engine の外で行うため、最も機能豊富な手法をもたらします。Docker コンテナの背後にあるストレージとして、Docker はデバイスマッパーによる シン・プロビジョニングを活用するからです。lvm をベースにしたシン・プール管理機能に含まれるハイライトは、自動もしくはインタラクティブなシン・プールの容量変更のサポートです。動的にシン・プールを変更する機能とは、lvm が シン・プールをアクティブにする時、自動的にメタデータのチェックを行います。

シン・プールが割り当てられ無ければフェイルバックします。この時、ループバックのファイルが作成されます。ループバックは非常に遅いものですが、ストレージの再設定を行わなくても利用可能になります。プロダクション環境においては、ループバックを使わないよう強く推奨します。Docker Engine デーモンで --storage-opt dm.thinpooldev の指定があるのを確認してください。

使用例：

$ docker daemon \
      --storage-opt dm.thinpooldev=/dev/mapper/thin-pool

• dm.basesize

ベース・デバイス作成時の容量を指定します。これはイメージとコンテナのサイズの上限にあたります。デフォルトの値は 10GB です。シン・デバイスは本質的に「希薄」（sparse）なのを覚えて置いてください。そのため、10GB のデバイスの大半が空白で未使用だったとしても、10GB の領域がプールされます。しかしながら、ファイルシステムがより大きなデバイスであれば、空白としても多くの容量を使う可能性があるでしょう。

以後のイメージや（イメージを元にする）コンテナが利用可能となる新しいベース・デバイス容量を増やしたい場合は、デーモンの再起動で変更できます。

使用例：

$ docker daemon --storage-opt dm.basesize=50G

これはベース・デバイス容量を 50GB に増やしています。Docker デーモンはこのベース・イメージの容量が 50GB よりも大きくなるとエラーを投げます。ユーザはこのオプションを使ってベース・デバイス容量を拡張できますが、縮小はできません。

システム全体の「ベース」となる空白のファイルシステムに対して、設定値が影響を与えます。これは、既に初期化されているか、取得しているイメージから継承している場合です。とりわけ、この値の変更時には、反映するにために追加手順が必要です。

$ sudo service docker stop
$ sudo rm -rf /var/lib/docker
$ sudo service docker start

使用例：

$ docker daemon --storage-opt dm.basesize=20G

• dm.loopdatasize

「データ」デバイスがシン・プール用に使うためのループバック・ファイルの作成時、この容量の指定に使います。デフォルトの容量は 100GB です。ファイルは希薄なため、初期段階ではさほど容量を使いません。

使用例：

$ docker daemon --storage-opt dm.loopdatasize=200G

• dm.loopmetadatasize

「メタデータ」デバイスがシン・プール用に使うためのループバック・ファイルの作成時、この容量の指定に使います。デフォルトの容量は 2GB です。ファイルは希薄なため、初期段階ではさほど容量を使いません。

使用例：

$ docker daemon –storage-opt dm.loopmetadatasize=4G

• dm.fs

ベース・デバイスで使用するファイルシステムの種類を指定します。サポートされているオプションは「ext4」と「xfs」です。デフォルトは「xfs」です。

使用例：

$ docker daemon --storage-opt dm.fs=ext4

• dm.mkfsarg

ベース・デバイスの作成時に mkfs に対する追加の引数を指定します。

使用例：

$ docker daemon --storage-opt "dm.mkfsarg=-O ^has_journal"

• dm.mountopt

シン・デバイスをマウントする時に使う、追加マウントオプションを指定します。

使用例：

$ docker daemon –storage-opt dm.mountopt=nodiscard

• dm.datadev

（廃止されました。 dm.thinpooldev をお使いください ）

シン・プール用のブロック・デバイスが使うデータを指定します。

デバイスマッパー用のストレージにブロック・デバイスを使う時、datadev と metadatadev の両方がループバック・デバイスを完全に使わないようにするのが理想です。

使用例：

$ docker daemon \
      --storage-opt dm.datadev=/dev/sdb1 \
      --storage-opt dm.metadatadev=/dev/sdc1

• dm.metadatadev

（廃止されました。 dm.thinpooldev をお使いください ）

シン・プール用のブロック・デバイスが使うメタデータを指定します。

最も性能の高いメタデータとは、データとは軸が異なる場所にあるものです。 SSD を使うのが望ましいでしょう。

新しいメタデータ・プールのセットアップには有効化が必要です。次のように、ゼロ値を使い、始めから 4096 まで空白のメタデータを作ります。

$ dd if=/dev/zero of=$metadata_dev bs=4096 count=1

使用例：

$ docker daemon \
      --storage-opt dm.datadev=/dev/sdb1 \
      --storage-opt dm.metadatadev=/dev/sdc1

• dm.blocksize

シン・プールで使うカスタム・ブロックサイズを指定します。デフォルトのブロックサイズは 64K です。

使用例：

$ docker daemon --storage-opt dm.blocksize=512K

• dm.blkdiscard

デバイスマッパー・デバイスの削除時に blkdiscard を使うか使わないかを指定します。デフォルトは有効であり、ループバック・デバイスを使っているのであれば、イメージやコンテナ削除時にループバック・ファイルを再希薄化させるために使います。

このループバックを無効にしたら、コンテナの削除時間がより早くなります。しかし、 /var/lib/docker ディレクトリで使用している領域量は、コンテナが削除された時点で使っていた領域を返してしまいます。

使用例：

$ docker daemon --storage-opt dm.blkdiscard=false

• dm.override_udev_sync_check

devicemapper と udev 間における udev 同期確認の設定を上書きします。 udev は Linux カーネル用のデバイスマッパーです。

Docker デーモンが udev 同期をサポートしているかどうかは、 devicemapper ドライバを使い確認します。

$ docker info
[...]
Udev Sync Supported: true
[...]

udev 同期サポートが true であれば、 devicemapper と udev を組み合わせ、コンテナ向けのデバイスを有効化（activation）・無効化（deactivation）します。

udev 同期サポートが false であれば、 devicemapper と udev 間で作成・クリーンアップ時に競合を引き起こします。競合状態の結果、エラーが発生して失敗します（の失敗に関する詳しい情報は docker#4036 をご覧ください。）

docker デーモンの起動時に有効にするには、 udev 同期をサポートしているかどうかに拘わらず、 dm.override_udev_sync_check を true にします。

$ docker daemon --storage-opt dm.override_udev_sync_check=true

この値が true の場合、 devicemapper はエラーが発生しても簡単に警告を表示するだけで、処理を継続します。

• dm.use_deferred_removal

libdm やカーネル・ドライバがサポートしている仕組みがあれば、デバイス削除の遅延を有効化します。

デバイス削除の遅延が意味するのは、デバイスを無効化・非アクティブ化しようとしてもビジー（使用中）であれば、デバイス上で遅延削除が予定されます。そして、最後にデバイスを使っているユーザが終了したら、自動的に削除します。

例えば、コンテナを終了したら、関連づけられているシン・デバイスも削除されます。デバイスが他のマウント名前空間も利用しているの場合は、削除できません。コンテナの終了が成功したら、このオプションが有効であれば、システムがデバイスの遅延削除をスケジュールします。使用中のデバイスが削除できるまで、ループを繰り返すことはありません。

使用例：

$ docker daemon --storage-opt dm.use_deferred_removal=true

• dm.use_deferred_deletion

シン・プール用デバイスの遅延削除を有効化するのに使います。デフォルトでは、シン・プールの削除は同期します。コンテナを削除する前に、Docker デーモンは関連するデバイスを削除します。ストレージ・ドライバがデバイスを削除できなければ、コンテナの削除は失敗し、デーモンはエラーを表示します。

この失敗を避けるには、デバイス遅延削除（deletion）と、デバイス遅延廃止（removal）をデーモンで有効化します。

$ docker daemon \
      --storage-opt dm.use_deferred_deletion=true \
      --storage-opt dm.use_deferred_removal=true

この２つのオプションが有効であれば、ドライバがコンテナを削除する時にデバイスが使用中でも、ドライバはデバイスを削除対象としてマークします。その後、デバイスが使えなくなったら、ドライバはデバイスを削除します。

通常、安全のためにデフォルトでこのオプションを有効化すべきです。複数のマウント名前空間にまたがり、マウントポイントの意図しないリークが発生した時に役立つでしょう。

• dm.min_free_space

シン・プールが新しいデバイスを正常に作成するために必要な最小ディスク空き容量を、パーセントで指定します。チェックはデータ領域とメタデータ領域の両方に適用します。有効な値は 0% ~ 99% です。値を 0% に指定すると空き領域のチェック機構を無効にします。ユーザがオプションの値を指定しなければ、Engine はデフォルト値 10% を用います。

新しいシン・プール用デバイスを作成すると（ docker pull 時やコンテナの作成時 ）、すぐに Engine は最小空き容量を確認します。十分な領域がなければデバイスの作成は失敗し、対象の docker オプションは失敗します。

このエラーから復帰するには、エラーが出なくなるようシン・プール内の空き容量を増やす必要があります。シン・プールかにある同じイメージやコンテナを削除することで、空き容量を増やせます。

LVM (Logical Volume Management；論理ボリューム管理) シン・プールの容量を増やすには、コンテナのシン・プールのボリューム・グループに対する領域を追加します。そうすると、エラーは出なくなります。もしループ・デバイスを使う設定であれば、Engine デーモンは停止します。この問題を解決するにはデーモンを再起動してループ・ファイルの容量を増やします。

指定例：

$ docker daemon --storage-opt dm.min_free_space=10%

現時点で zfs がサポートしているオプション：

• zfs.fsname

Docker が自身のデータセットとして、どの zfs ファイルシステムを使うか指定します。デフォルトの Docker は docker グラフ（ /var/lib/docker ）がある場所を zfs ファイルシステムとして用います。

使用例：

$ docker daemon -s zfs --storage-opt zfs.fsname=zroot/docker

ユーザ名前空間を有効にしてデーモンを起動¶

ユーザ名前空間のサポートを有効化するには、デーモン起動時に --userns-remap フラグを使います。以下のフォーマット形式が指定できます。

• uid
• uid:gid
• ユーザ名
• ユーザ名:グループ名

整数値の ID を指定したら、有効なユーザ名かグループ名に交換されます。これにより、従属 uid と gid の情報が読み込まれ、指定されたこれらのリソースは ID ベースではなく名前ベースでとなります。 /etc/passwd や /etc/group にエントリが無い数値 ID 情報が指定された場合は、docker は起動せずにエラーを表示します。

$ docker daemon --userns-remap=default

$ cat /etc/subuid
user1:100000:65536
dockremap:165536:65536

subuid / subgid 範囲についての詳細情報¶

パワーユーザであれば、従属 ID の範囲変更という高度な使い方があります。以下で扱うのは、現在どのようにして Docker デーモンが従属範囲のファイルから範囲を決めているかの定義です。

最も簡単なケースは、ユーザとグループに対する近接範囲（contiguous range）を１つだけ指定する場合です。この例では、Docker はコンテナのプロセスに対し、ホスト側の uid と gid の全てを近接範囲として割り当て（マッピングし）ます。つまり、範囲において一番始めに割り当てるのが root ユーザです。この ID が初期 ID として、（ホスト側）範囲における最後をホスト ID 1 として（コンテナ側に）割り当てます。

先ほど取り上げた /etc/subuid の例では、root ユーザに再割り当てする uid は 165536 になります。

システム管理者は単一のユーザまたはグループに対して複数の範囲を設定できます。Docker デーモンは利用可能な範囲から、以下のアルゴリズムに基づき範囲を割り当てます。

1. 特定ユーザに対する範囲のセグメント（区分）が見つれば、開始 ID を昇順でソートします。

2. セグメントの割り当てには、各セグメントの長さに一致するよう、範囲の値を増やします。そうすると、セグメントの範囲は最も低い数値から始まり、これを root として再割り当てし、あとはホスト側の uid/gid と一致する範囲まで繰り返します。例えば、最小セグメントの ID が 1000 から始まり、長さが 100 としたら、 1000 を 0 にマップし（root として再マップ）ます。これを対象セグメントでは 1100 が 100 にマップするまで続けます。次のセグメントは ID 10000 から始まる場合、次は 10000 が 101 にマップし、その長さの分だけ処理します。この処理を対象ユーザのサボーディネート（従属）ファイルに空きセグメントが無くなるまで繰り返します。

3. ユーザ向けのセグメント範囲が無くなった場合は、カーネルで５つまで使えるよう制限されているエントリ /proc/self/uid_map と /proc/self/gid_map が使えます。

コンテナ用のユーザ名前空間を無効化¶

デーモンでユーザ名前空間を有効にしたら、全てのコンテナはユーザ名前空間が有効な状態で起動します。状況によってはコンテナに対するユーザ名前空間を無効化したい時があるでしょう。例えば、特権コンテナ（privileged container）の起動時です（詳細は ユーザ名前空間と既知の制限 をご覧ください ）。これらの高度な機能を使うには、コンテナの run exec create コマンド実行時に --userns=host を指定します。このオプションを使えばコンテナの利用者に対するユーザ名前空間の割り当てを完全に無効化します。

ユーザ名前空間と既知の制限¶

Docker デーモンのユーザ名前空間を有効にした状態では、以下の Docker 標準機能は互換性がありません。

• ホスト・モードにおける PID 名前空間または NET 名前空間（ --pid=host あるいは --net=host ）
• --readonly コンテナ・ファイルシステム（ユーザ名前空間内において、現在のマウント・ファイルシステムのフラグを変更してリマウントすることは、Linux カーネルの制約によりできません）
• デーモンが知らない／機能を持たない外部ドライバ（ボリュームやグラフ）をユーザ名前空間内で実行
• docker run で --privileged モードのフラグを指定（また --userns=host も指定できません ）

一般的に、ユーザ名前空間は高度な機能であり、他の機能との調整を必要とします。例えば、ホストにボリュームをマウントするときは、ファイルの所有者はユーザもしくは管理者がボリューム・コンテナにアクセスできるよう、あらかじめ調整しておきます。

最後に、ユーザ名前空間に対応したコンテナ・プロセス内の root ユーザとは、多くの管理特権を持っていると考えるかもしれません。ですが、Linux カーネルは内部情報に基づきユーザ名前空間内のプロセスとして制限を施します。現時点で最も注意が必要な制約は mknod の使用です。コンテナ内のユーザ名前空間では root であったとしてもデバイス作成の権限がありません。

設定の再読み込み¶

いくつかのオプションは設定を反映するために、デーモンのプロセスの再起動を必要とせず、実行中のまま行えます。再読み込みするために、Linux では SIGHUP シグナルを使います。Windows では Global\docker-daemon-config-$PID をキーとするグローバル・イベントを使います。設定ファイルでオプションを変更できますが、指定済みのフラグと競合していなか確認されます。もし設定に重複があれば、デーモンは発生を反映できませんが、実行中のデーモンは止まりません。

現時点で変更可能なオプションは以下の通りです。

• debug ：true を設定したら、デーモンをデバッグ・モードにします。
• cluster-store ：新しいアドレスにディスカバリ・ストアを読み込み直します。
• cluster-store-opts ：ディスカバリ・ストアをお見込む時の新しいオプションを指定します。
• cluster-advertise ：再起動後のアドバタイズド・アドレスを指定します。
• labels ：デーモンのラベルを新しく設定したものに変えます。

--cluster-store 、 --cluster-advertise 、 --cluster-store-opts のようなクラスタ設定情報の更新や再読み込みが反映できるのは、これまでに指定しない項目に対してのみです。フラグで --cluster-store を指定しても cluster-advertise を指定していなければ、 cluster-advertise は --cluster-store を一緒に指定しなくても反映します。既に設定済みのクラスタ設定に対して変更を試みたら、設定読み込み時に警告メッセージをログに残します。