daemon

Usage: docker daemon [OPTIONS]

A self-sufficient runtime for linux containers.

Options:
  --api-cors-header=""                   Set CORS headers in the remote API
  --authorization-plugin=[]              Set authorization plugins to load
  -b, --bridge=""                        Attach containers to a network bridge
  --bip=""                               Specify network bridge IP
  --cgroup-parent=                       Set parent cgroup for all containers
  -D, --debug                            Enable debug mode
  --default-gateway=""                   Container default gateway IPv4 address
  --default-gateway-v6=""                Container default gateway IPv6 address
  --cluster-store=""                     URL of the distributed storage backend
  --cluster-advertise=""                 Address of the daemon instance on the cluster
  --cluster-store-opt=map[]              Set cluster options
  --config-file=/etc/docker/daemon.json  Daemon configuration file
  --dns=[]                               DNS server to use
  --dns-opt=[]                           DNS options to use
  --dns-search=[]                        DNS search domains to use
  --default-ulimit=[]                    Set default ulimit settings for containers
  --exec-opt=[]                          Set exec driver options
  --exec-root="/var/run/docker"          Root of the Docker execdriver
  --fixed-cidr=""                        IPv4 subnet for fixed IPs
  --fixed-cidr-v6=""                     IPv6 subnet for fixed IPs
  -G, --group="docker"                   Group for the unix socket
  -g, --graph="/var/lib/docker"          Root of the Docker runtime
  -H, --host=[]                          Daemon socket(s) to connect to
  --help                                 Print usage
  --icc=true                             Enable inter-container communication
  --insecure-registry=[]                 Enable insecure registry communication
  --ip=0.0.0.0                           Default IP when binding container ports
  --ip-forward=true                      Enable net.ipv4.ip_forward
  --ip-masq=true                         Enable IP masquerading
  --iptables=true                        Enable addition of iptables rules
  --ipv6                                 Enable IPv6 networking
  -l, --log-level="info"                 Set the logging level
  --label=[]                             Set key=value labels to the daemon
  --log-driver="json-file"               Default driver for container logs
  --log-opt=[]                           Log driver specific options
  --mtu=0                                Set the containers network MTU
  --disable-legacy-registry              Do not contact legacy registries
  -p, --pidfile="/var/run/docker.pid"    Path to use for daemon PID file
  --registry-mirror=[]                   Preferred Docker registry mirror
  -s, --storage-driver=""                Storage driver to use
  --selinux-enabled                      Enable selinux support
  --storage-opt=[]                       Set storage driver options
  --tls                                  Use TLS; implied by --tlsverify
  --tlscacert="~/.docker/ca.pem"         Trust certs signed only by this CA
  --tlscert="~/.docker/cert.pem"         Path to TLS certificate file
  --tlskey="~/.docker/key.pem"           Path to TLS key file
  --tlsverify                            Use TLS and verify the remote
  --userns-remap="default"               Enable user namespace remapping
  --userland-proxy=true                  Use userland proxy for loopback traffic

[] が付いているオプションは、複数回指定できます。

Docker デーモンはコンテナを管理するために常駐するプロセスです。Docker はデーモンもクライアントも同じバイナリを使います。デーモンを起動するには docker daemon を入力します。

デーモンでデバッグ出力を行うには、 docker daemon -D を使います。

デーモン・ソケットのオプション

Docker デーモンは Docker リモート API をリッスンできます。3種類のソケット、 unixtcpfd を通して利用できます。

デフォルトでは unix ドメイン・ソケット(あるいは IPC ソケット)が /var/run/docker.sock に作成されるため、 root 権限か docker グループへの所属が必要です。

Docker デーモンにリモートからの接続を考えているのであれば、 tcp ソケットを有効にする必要があります。デフォルトのセットアップでは、Docker デーモンとの暗号化や認証機能はありませんのでご注意ください。そして、安全に使うには 内蔵の HTTP 暗号化ソケット を使うべきです。あるいは安全なウェブ・プロキシをフロントに準備してください。ポート 2375 をリッスンしている場合は、全てのネットワークインターフェースで -H tcp://0.0.0.0:2375 を使うか、あるいは IP アドレスを -H tcp://192.168.59.103:2375 のように指定します。慣例として、デーモンとの通信が暗号化されていない場合はポート 2375 を、暗号化されている場合はポート 2376 を使います。

注釈

HTTP 暗号化ソケットを使う時は、TLS 1.0 以上でサポートされているプロトコル SSLv3 以上をお使いください。以下のバージョンはセキュリティ上の理由によりサポートされていません。

systemd をベースとするシステムでは、 Systemd ソケット・アクティベーション を通して、 docker damon -H fd:// で通信が可能です。 fd:// は大部分のセットアップで動作しますが、個々のソケットを docker daemon -H fd://3 のように指定できます。もし指定したソケットが見つからない婆は、Docker は終了します。Docker で Systemd ソケット・アクティベーションを使う例は Docker のソース・ツリー をご覧ください。

Docker デーモンは複数の -H オプションを使い、複数のソケットをリッスンできます。

# デフォルトの unix ソケットと、ホスト上の2つの IP アドレスをリッスンする
docker daemon -H unix:///var/run/docker.sock -H tcp://192.168.59.106 -H tcp://10.10.10.2

Docker クライアントは DOCKER_HOST 環境変数か -H フラグで接続できるようになります。

$ docker -H tcp://0.0.0.0:2375 ps
# あるいは
$ export DOCKER_HOST="tcp://0.0.0.0:2375"
$ docker ps
# どちらも同じです

DOCKER_TLS_VERIFY 環境変数が設定してあれば、コマンド実行時に --tlsverify フラグを都度指定するのと同じです。以下はいずれも同じです。

$ docker --tlsverify ps
# または
$ export DOCKER_TLS_VERIFY=1
$ docker ps

Docker クライアントは HTTP_PROXYHTTPS_PROXYNO_PROXY 環境変数を(あるいは小文字でも)使えます。 HTTPS_PROXYHTTP_PROXY よりも上位です。

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

Docker デーモンは様々に異なるイメージ・レイヤ・ストレージ・ドライバをサポートしています。ドライバは、 aufsdevicemapperbtrfszfsoverlay です。

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

devicemapper ドライバはシン・プロビジョニング(thin provisioning)とコピー・オン・ライト(Copy on Write)スナップショットを使います。各 devicemapper が位置する場所は、 /var/lib/docker/devicemapper が典型的です。シン(thin)プールは2つのブロックデバイス上に作られます。1つはデータであり、もう1つはメタデータです。デフォルトでは、これらのブロック・デバイスは、別々のファイルとして自動されたループバックのマウントをもとに、自動的に作成されます。セットアップのカスタマイズ方法は、以下にある ストレージ・ドライバのオプション をご覧ください。 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 のおかげで、クローン間の共有ブロックが1度キャッシュされます。使うには docker daemon -s zfs を指定します。異なる zfs ファイルシステムセットを選択するには、 zfs.fsname オプションを ストレージ・ドライバのオプション で指定します。

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

注釈

前途有望な overlay ですが、機能がまだ若く、プロダクションで使うべきではありません。特に overlay を使うと過度の inode 消費を引き起こします(特にイメージが大きく成長する場合)。また、RPM との互換性がありません。

注釈

現在のサポートされていない btrfs やコピー・オン・ライトのファイルシステムは、 ext4 パーティション上のみで使うべきです。

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

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

  • dm.thinpooldev

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

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

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

シン・プールが割り当てられなければフェイルバックします。このとき、ループバックのファイルが作成されます。ループバックは非常に遅いものですが、ストレージの再設定を行わなくても利用可能になります。プロダクション環境においては、ループバックを使わない事を強く推奨します。Docker デーモンで --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

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

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

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

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

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

docker デーモンを開始するには、 udev 同期をサポートしているかどうかに関わらず、 dm.override_udev_sync_check を true にします。

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

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

注釈

docker デーモンと環境を追跡するという考えは、 udev の同期機能をサポートするためのものでした。このトピックに関しては docker#4036 をご覧下さい。一方で、既存の Docker デーモンを、サポートされている別の環境に移行する時のフラグとしても使います。

  • 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

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

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

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

  • zfs.fsname

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

使用例:

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

Docker 実行ドライバのオプション

Docker デーモンは Linux カーネルの namespacescgroupsSELinux に対するインターフェースとして、特別に作られた libcontainer 実行ドライバを使います。

lxc 実行ドライバを通して、オリジナルの LXC 名前空間ツール もレガシーとしてサポートします。しかし、新機能を追加するための重要な開発対象ではなくなっています。 -e lxc をデーモンのフラグに追加し、 lxc 実行ドライバを使えます。

ネイティブ実行ドライバのオプション

native (libcontainer) 実行ドライバは、 --exec-opt フラグを使ってオプションを指定できます。全てのオプションのフラグには、先頭に native が付きます。 native.cgroupdriver オプションが利用可能です。

native.cgroupdriver オプションはコンテナの cgroups 管理を指定します。 systemdcgroupfs で指定可能です。 systemd で指定した時、対象が利用可能でなければ、システムは cgroupfs を使います。デフォルトでは、オプションの指定がない場合、実行ドライバはまず systemdcgroupfs のフェイルバックを試みます。次の例は cgroupfs を実行ドライバに設定します。

$ sudo docker daemon --exec-opt native.cgroupdriver=cgroupfs

このオプション設定は、デーモンが起動した全てのコンテナに対して適用されます。

デーモンの DNS オプション

全ての Docker コンテナに向けての DNS サーバを設定するには、 docker damon --dns 8.8.8.8 を使います。

全ての Docker コンテナに向けて DNS 検索ドメインを設定するには、 docker daemon --dns-search example.com を使います。

安全ではないレジストリ

Docker はプライベート・レジストリが安全かそうでないかを確認します。このセクションでは、 レジストリ として プライベート・レジストリ (private registry) を使い、例としてプライベート・レジストリが myregistry:5000 で動作しているものとします。

安全なレジストリは、TLS を使い、CA 証明書のコピーが /etc/docker/certs.d/myregistry:5000/ca.crt にあります。安全ではないレジストリとは、TLS を使っていない場合(例:平文の HTTP をリッスン)や、TLS を使っていても Docker デーモンが知らない CA 証明書を使う場合を指します。後者であれば、証明書が /etc/docker/certs.d/myregistry:5000/ 以下に存在しないか、証明書の照合に失敗しています(例:CA が違う)。

デフォルトでは、Docker はローカルにあるレジストリ(以下のローカル・レジストリについてをご覧ください)は安全であるとみなします。Docker はレジストリが安全とみなさない限り、安全ではないレジストリとの通信はできません。安全ではないレジストリと通信できるようにするには、Docker デーモンに --insecure-registry という2つの形式のオプションが必要です。

  • --insecure-registry myregistry:5000 Docker デーモンに対して、myregistry:5000 は安全ではないと考えられると伝えます。
  • --insecure-registry 10.1.0.0/16 は Docker デーモンに対して、ドメインを逆引きすると、CIDR 構文で記述した対象のサブネット上の IP アドレスを持つ全てが安全ではないと伝えます。

このフラグは、複数のレジストリに対して安全ではないと複数回指定できます。

安全ではないレジストリを「安全ではない」と指定しなければ、 docker pulldocker pushdocker search を実行してもエラーメッセージが帰ってきます。ユーザは安全なレジストリを使うか、あるいは先ほどのように --insecure-registry フラグで Docker デーモンに対して明示する必要があります。

IP アドレスが 127.0.0.0/8 の範囲にあるローカルのレジストリは、Docker 1.3.2 以降、自動的に安全ではないレジストリとしてマークされます。ですが、これを信用するのは推奨しません。将来のバージョンでは変更される可能性があります。

--insecure-registry を有効にするとは、暗号化されていない、あるいは信頼できない通信を可能にします。そのため、ローカル環境でのレジストリ実行には便利でしょう。しかし、セキュリティ上の脆弱性を生み出してしまうため、テスト目的のみで使うべきです。セキュリティを高めるには、 --insecure-registry を有効にするのではなく、信頼できる CA 機関が発行する CA を使うべきです。

過去のレジストリ

--disable-legacy-registry を有効にすると、Docker は V2 プロトコルをサポートしているデーモンとしか通信しないように強制します。この指定によって、デーモンは v1 レジストリへの pushpulllogin を阻止します。例外として、v1 レジストリでも search のみ実行できます。

Docker デーモンを HTTPS_PROXY の背後で動かす

LAN の内部で HTTPS プロキシを使う場合、Docker Hub の証明書がプロキシの証明書に置き換えられます。これら証明書を、Docker ホストの設定に追加する必要があります。

  1. 各ディストリビューションに対応する ca-certificates パッケージをインストールします。
  1. ネットワーク管理者にプロキシの CA 証明書を訊ね、 /etc/pki/tls/certs/ca-bundle.crt に追加します。
  1. Docker デーモンに HTTPS_PROXY=http://username:password@proxy:port/ docker daemon を付けて起動します。 username:password@ はオプションです。そして、プロ指揮の認証設定も必要であれば追加します。

これは Docker デーモンのリクエストに対してプロキシと認証の設定を追加しただけです。 docker build でコンテナを実行する時は、プロキシを使うために更なる追加設定が必要です。

Ulimits のデフォルト

--default-ulimit を使い、全てのコンテナに対するデフォルトの ulimit オプションを指定できます。 docker run 時に --ulimit オプションを指定するのと同じです。デフォルトを設定しなければ、 ulimit 設定は継承されます。 docker run 時に設定されなければ、Docker デーモンから継承します。docker run 時のあらゆる --ulimit オプションは、デフォルトを上書きします。

noproculimit フラグを使う時は注意してください。 noproc は Linux がユーザに対して利用可能な最大プロセス数を設定するものであり、コンテナ向けではありません。詳細については、 run リファレンスをご確認ください。

ノードのディスカバリ(検出)

--cluster-advertise オプションは、 ホスト:ポート あるいは インターフェース:ポート の組み合わせを指定します。これは、この特定のデーモン・インスタンスがクラスタに自分自身の存在を伝える(advertising)ために使います。リモートホストに到達するデーモンの情報を、ここに指定します。インターフェースを指定する場合は、実際の Docker ホスト上の IP アドレスも含められます。たとえば、 docker-machine を使ってインストールする時、典型的なインターフェースは eth1 です。

デーモンはクラスタ内のノードに存在を伝えるため、 libkv を使います。キーバリュー・バックエンドは同じ TLS をサポートします。デーモンが使用するクライアント TLS の設定は --cluster-store-opt フラグを使い、PEM エンコード・ファイルのパスを指定します。実行例:

docker daemon \
    --cluster-advertise 192.168.1.2:2376 \
    --cluster-store etcd://192.168.1.2:2379 \
    --cluster-store-opt kv.cacertfile=/path/to/ca.pem \
    --cluster-store-opt kv.certfile=/path/to/cert.pem \
    --cluster-store-opt kv.keyfile=/path/to/key.pem

現在サポートされているクラスタ・ストアのオプションは:

  • kv.cacertfile

信頼すべき CA 証明書がエンコードされた PEM のローカル・パスを指定します。

  • kv.certfile

証明書でエンコードされた PEM のローカル・パスを指定。この証明書はクライアントがキーバリュー・ストアとの通信の証明に使います。

  • kv.keyfile

秘密鍵がエンコードされた PEM のローカル・パスを指定します。この秘密鍵はクライアントがキーバリュー・ストアと通信時に鍵として使います。

  • kv.path

キーバリュー・ストアのパスを指定します。指定しなければ、デフォルトの docker/nodes が使われます。

アクセス認証

Docker のアクセス認証は認証プラグインの拡張であり、組織が組織自身で購入・構築できます。認証プラグイン(authorization plugin)を使うには、Docker daemon--authorization-plugin=PLUGIN_ID オプションを使って起動します。

docker daemon --authorization-plugin=plugin1 --authorization-plugin=plugin2,...

PLUGIN_ID の値とは、プラグイン名かファイルのパスを指定します。どのプラグインを実装するかを決めるのは、名前またはパスです。あなたの Docker 管理者に対して、利用可能なプラグインの情報をお訊ねください。

プラグインをインストール後は、コマンドラインや Docker のリモート API を実行する時、プラグインを許可するか許可しないかを選べます。複数のプラグインをインストールした場合は、最後の1つだけが処理されます。

認証プラグインの作成方法については、この Docker ドキュメントの拡張に関するセクションにある 認証プラグイン をご覧ください。

デーモンのユーザ名前空間オプション

Linux カーネルの ユーザ名前空間(user namespace)サポート はプロセスに対する追加のセキュリティを提供します。これを使えば、コンテナでユーザ ID とグループ ID を使う場合、それをコンテナの外、つまり Docker ホスト上で使うユーザ ID とグループ ID のユニークな範囲を指定できます。これは重要なセキュリティ改善になる可能性があります。デフォルトでは、コンテナのプロセスは root ユーザとして実行されるので、コンテナ内で管理特権(と制限)を持っていることが予想されます。しかし、その影響はホスト上の権限の無い uid に対して割り当てられます。

ユーザ名前空間のサポートを有効化すると、Docker はデーモンが扱うマッピングを作成します。これは、同じ Engine のインスタンス上で実行する全コンテナと対応するものです。マッピングを使い、従属ユーザ(subordinate user)ID と従属グループ ID を活用します。この機能は最近の全ての Linux ディストリビューション上において利用可能です。 --userns-remap パラメータを指定することで、 /etc/subuid/etc/subguid ファイルがユーザとオプションのグループ用に使われます。このフラグに自分でユーザとグループを指定しなければ、ここでは default が指定されます。 default のユーザとは dockremap と言う名前であり、各ディストリビューションの一般的なユーザとグループ作成ツールを使い、 /etc/passwd/etc/group にエントリが追加されます。

注釈

現時点ではデーモン毎に1つだけマッピングするという制約があります。これは Engine インスタンス上で実行している全てのコンテナにまたがる共有イメージ・レイヤを Docker が共有しているためです。ファイルの所有者は、レイヤ内容を共有している全てのコンテナで共通の必要があるため、解決策としては docker pull の処理時、ファイル所有者をデーモンのユーザとグループに割り当てる(マッピングする)ことでした。そのため、イメージ内容をダウンロード後は遅延なくコンテナを起動できました。この設計は同じパフォーマンスを維持するため、 docker pulldocker push の実行時には維持されています。

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

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

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

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

例:default の Docker ユーザ管理

$ docker daemon --userns-remap=default

default を指定すると、 Docker は dockermap というユーザ名とグループ名が存在しているかどうか確認し、なければ作成します。ユーザが作成されると、 Linux ディストリビューションは /etc/subuid/etc/subgid ファイルの使用をサポートします。これは従属ユーザ ID と従属グループ ID を 65536 まで数える(カウントする)もので、これらは既存のファイルへのエントリをオフセットに使います。例えば、Ubuntu は次のような範囲を作成します。既存の user1 という名前のユーザは、既に 65536 までの範囲を持っています。

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

注釈

Fedora の新規インストール時であれば、ユーザが作成時に範囲を割り当てるために /etc/subuid/etc/subguid ファイルを touch コマンドで作成する必要があります。ファイルが作成されていれば、ユーザ作成時に適切な範囲が割り当てられます。

もしも、既に自分で行った従属ユーザの設定を使いたい場合は、 --userns-remap フラグにユーザ名か UID を指定します。グループがユーザ名と一致しない場合は、同様に gid やグループ名も指定します。そうしなければ、従属グループ ID の範囲をシステムが応答するときに、ユーザ名がグループ名として使われます。

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

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

(ToDo)

その他のオプション

IP マスカレードはコンテナがパブリック IP を持っていなくても、インターネット上の他のマシンと通信するための仕組みです。これにより、インターフェースは複数のネットワーク・トポロジを持ちますが、 --ip-masq=false を使って無効化できます。

Docker は Docker データ/ディレクトリ( /var/lib/docker )と /var/lib/docker/tmp に対するソフトリンクをサポートしています。 DOCKER_TMPDIR を使っても、データディレクトリを次のように指定可能です。

DOCKER_TMPDIR=/mnt/disk2/tmp /usr/local/bin/docker daemon -D -g /var/lib/docker -H unix:// > /var/lib/docker-machine/docker.log 2>&1
# あるいは
export DOCKER_TMPDIR=/mnt/disk2/tmp
/usr/local/bin/docker daemon -D -g /var/lib/docker -H unix:// > /var/lib/docker-machine/docker.log 2>&1

デフォルトの親 cgroup

--cgroup-parent オプションは、コンテナがデフォルトで使う親 cgroup (cgroup parent)を指定できます。オプションを設定しないと、 /docker を fs cgroup ドライバとして使います。また system.slice を systemd cgroup ドライバとして使います。

cgroup はスラッシュ記号( / )で始まるルート cgroup の下に作成されますが、他の cgroup は daemon cgroup の下に作成されます。

デーモンが cgroup daemoncgroup で実行されており、--cgroup-parent=/foobar/sys/fs/cgroup/memory/foobar の中に cgroup を作成すると仮定すると、 --cgroup-parent=foobar/sys/fs/cgroup/memory/daemoncgroup/foobar に cgroup を作成します。

これらの指定はコンテナに対しても可能です。 docker createdocker run の実行時に --cgroup-parent を使うと、デーモンのオプションで指定した --cgroup-parent よりも優先されます。

デーモン設定ファイル

--config-file オプションを使うと、デーモンに対する設定オプションを JSON 形式で指定できます。このファイルでは、フラグと同じ名前をキーとします。ただし、複数の項目を指定可能なフラグの場合は、キーを複数形で指定します(例: label フラグの指定は labels になります )。デフォルトは、 Linux の場合は /etc/docker/daemon.json にある設定ファイルを Docker が読み込もうとします。Windows の場合は %programdata%\docker\config\daemon.json です。

設定ファイル上のオプションは、フラグで指定するオプションと競合してはいけません。ファイルとフラグが重複したまま docker デーモンを起動しようとしても、どのような値を指定しても、起動に失敗します。例えば、デーモンの起動時にラベルを設定ファイルで定義し、かつ、 --label フラグを指定すると、デーモンは起動に失敗します。

デーモン起動時、ファイルに記述しないオプション項目は無視します。次の例は、利用可能な全てのオプションをファイルに記述したものです。

{
     "authorization-plugins": [],
     "dns": [],
     "dns-opts": [],
     "dns-search": [],
     "exec-opts": [],
     "exec-root": "",
     "storage-driver": "",
     "storage-opts": "",
     "labels": [],
     "log-driver": "",
     "log-opts": [],
     "mtu": 0,
     "pidfile": "",
     "graph": "",
     "cluster-store": "",
     "cluster-store-opts": [],
     "cluster-advertise": "",
     "debug": true,
     "hosts": [],
     "log-level": "",
     "tls": true,
     "tlsverify": true,
     "tlscacert": "",
     "tlscert": "",
     "tlskey": "",
     "api-cors-headers": "",
     "selinux-enabled": false,
     "userns-remap": "",
     "group": "",
     "cgroup-parent": "",
     "default-ulimits": {},
       "ipv6": false,
       "iptables": false,
       "ip-forward": false,
       "ip-mask": false,
       "userland-proxy": false,
       "ip": "0.0.0.0",
       "bridge": "",
       "bip": "",
       "fixed-cidr": "",
       "fixed-cidr-v6": "",
       "default-gateway": "",
       "default-gateway-v6": "",
       "icc": false
}

設定の再読み込み

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

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

  • debug :true を設定すると、デーモンをデバッグ・モードにします。
  • labels :デーモンのラベルを新しく設定したものに変えます。