daemon

目次

使い方: dockerd [オプション]

Linux コンテナの自給自足ランタイム

オプション:
  --api-cors-header=""                   リモート API の CORS ヘッダをセットする
  --authorization-plugin=[]              読み込む認証プラグインを指定
  -b, --bridge=""                        コンテナをネットワーク・ブリッジにアタッチ
  --bip=""                               ネットワーク・ブリッジ IP の指定
  --cgroup-parent=                       全てのコンテナの親 cgroup を指定
  --cluster-store=""                     分散ストレージバックエンドの URL
  --cluster-advertise=""                 クラスタ上のデーモン・インスタンスのアドレス
  --cluster-store-opt=map[]              クラスタのオプションを指定
  --config-file=/etc/docker/daemon.json  デーモン設定ファイル
  --containerd                           containerd ソケットのパス
  -D, --debug                            デバッグ・モードの有効化
  --default-gateway=""                   コンテナのデフォルト・ゲートウェイ IPv4 アドレス
  --default-gateway-v6=""                コンテナのデフォルト・ゲートウェイ IPv6 アドレス
  --dns=[]                               DNS サーバの指定
  --dns-opt=[]                           DNS オプションの指定
  --dns-search=[]                        DNS の検索に使うドメイン（search domain）
  --default-ulimit=[]                    コンテナのデフォルト ulimit 設定を指定
  --exec-opt=[]                          実行時のオプションを指定
  --exec-root="/var/run/docker"          実行ステート・ファイルのルート・ディレクトリ
  --fixed-cidr=""                        IP アドレスの IPv4 サブネットを固定
  --fixed-cidr-v6=""                     IP アドレスの IPv6 サブネットを固定
  -G, --group="docker"                   unix ソケット用のグループ
  -g, --graph="/var/lib/docker"          Docker 実行時の Docker ルート
  -H, --host=[]                          接続するデーモンのソケット
  --help                                 使い方を表示
  --icc=true                             コンテナ内部通信（inter-container communication）を有効化
  --insecure-registry=[]                 安全ではないレジストリとの通信を有効化
  --ip=0.0.0.0                           コンテナのポートがデフォルトでバインドする IP
  --ip-forward=true                      net.ipv4.ip_forward の有効化
  --ip-masq=true                         IP マスカレードの有効化
  --iptables=true                        iptables のルール追加の有効化
  --ipv6                                  IPv6 ネットワークの有効化
  -l, --log-level="info"                 ログ記録レベルの設定
  --label=[]                             デーモンにキー=バリューのラベルを指定
  --log-driver="json-file"               デフォルトのコンテナのログ記録ドライバ
  --log-opt=[]                           ログドライバのオプションを指定
  --mtu=0                                コンテナ・ネットワークの MTU を指定
  --max-concurrent-downloads=3           pull ごとの最大同時ダウンロード数を指定
  --max-concurrent-uploads=5             push ごとの最大同時アップロード数を指定
  --disable-legacy-registry              レガシーのレジストリには接続しない
  -p, --pidfile="/var/run/docker.pid"    デーモン PID ファイル用のパス
  --registry-mirror=[]                   Docker レジストリの優先ミラー
  --add-runtime=[]                       追加 OCI 互換ランタイムの登録
  -s, --storage-driver=""                使用するストレージ・ドライバ
  --selinux-enabled                      SELinux サポートの有効化
  --storage-opt=[]                       ストレージ・ドライバのオプションを指定
  --tls                                  TLSを使用、--tlsverify を含む
  --tlscacert="~/.docker/ca.pem"         この CA で署名された証明書のみ信頼
  --tlscert="~/.docker/cert.pem"         TLS 証明書ファイルのパス
  --tlskey="~/.docker/key.pem"           TLS 鍵ファイルのパス
  --tlsverify                            TLS でリモート認証
  --userns-remap="default"               ユーザ名前空間の再マッピングを有効化
  --userland-proxy=true                  ループバック通信用に userland プロキシを使う

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

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

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

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

Docker デーモンは Docker リモート API を受信できます。３種類のソケット unix 、 tcp 、 fd を通します。

デフォルトでは 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 ソケット・アクティベーション を通し、 dockerd -H fd:// で通信が可能です。 fd:// は大部分のセットアップで動作するため、個々のソケットを dockerd -H fd://3 のように指定できます。もし指定したソケットが見つからない時は、Docker が終了します。Docker で Systemd ソケット・アクティベーションを使う例は Docker のソース・ツリー をご覧ください。

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

# デフォルトの unix ソケットと、ホスト上の２つの IP アドレスをリッスンする
dockerd -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_PROXY 、 HTTPS_PROXY 、 NO_PROXY 環境変数を（あるいは小文字でも）使えます。 HTTPS_PROXY は HTTP_PROXY よりも上位です。

Docker の別ホスト/ポート、あるいは Unix ソケットをバインド

警告

docker デーモンがバインドするデフォルトの TCP ポートや Unix docker ユーザ・グループの変更は、セキュリティ上の危険性を高めます。危険性とは、ホスト上の root 以外のユーザが root へのアクセスが可能になるかもしれません。 docker に対するアクセス管理を確実に行ってください。TCP ポートをバインドする場合、ポートにアクセス可能な誰もが Docker に対するフル・アクセスを可能にします。そのため、オープンなネットワーク上では望ましくありません。

Docker デーモンに -H オプションを指定すると、特定の IP アドレスとポートをリッスンします。デフォルトでリッスンするのは unix:///var/run/docker.sock であり、root ユーザのみローカル接続可能です。誰もが接続可能とするには 0.0.0.0:2375 かホスト IP アドレスを指定しますが、 非推奨です 。デーモンを実行しているホストにアクセス可能であれば、誰もが root アクセスを得られるのと同じだからです。

同様に、 Docker クライアントは -H を使い任意のポートに節即できます。 Docker クライアントはデフォルトで、Linux であれば unix:///var/run/docker.sock へ、Windows であれば tcp://127.0.0.1:2376 に接続します。

tcp://[ホスト]:[ポート][パス] あるいは unix://パス

例：

  • tcp:// → 127.0.0.1 に接続。TLS 暗号化が有効であればポート 2376 を、平文の通信時はポート 2375 を使用。
  • tcp://ホスト:2375 → ホスト:2375 の TCP 接続。
  • tcp://host:2375/path → ホスト:2375 の TCP 接続と、リクエストに追加パスが必要。
  • unix://path/to/socket → path/to/socket にある Unix ソケット。

-H の値がなければ、デフォルトでは -H を指定しなかった値になります。

-H は TCP バインドの指定を短縮できます。

``host:` あるいは `host:port` あるいは `:port`

Docker をデーモン・モードで実行するには：

$ sudo <path to>/dockerd -H 0.0.0.0:5555 &

ubuntu イメージをダウンロードするには：

$ docker -H :5555 pull ubuntu

複数の -H を指定できます。たとえば、TCP と Unix ソケットの両方をリッスンするには、次のようにします。

# docker をデーモン・モードで実行
$ sudo <path to>/dockerd -H tcp://127.0.0.1:2375 -H unix:///var/run/docker.sock &
# デフォルトの Unix ソケットを使い、 ubuntu イメージのダウンロード
$ docker pull ubuntu
# あるいは、TCP ポートを使用
$ docker -H tcp://127.0.0.1:2375 pull ubuntu

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

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

最も古いドライバは 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 のようにデバイス間の実行メモリを共有しません。使うには dockerd -s btrfs -g /mnt/btrfs_partition を実行します。

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

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

注釈

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

overlay2 は同じ高速なユニオン・ファイルシステムを使いますが、Linux カーネル 4.0 で追加された 追加機能 を使います。これは過度のｉノード消費を防ぐものです。使うには dockerd -s overlay2 を実行します。

注釈

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

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

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

devicemapper のオプション

  • dm.thinpooldev

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

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

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

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

使用例：

$ dockerd \
      --storage-opt dm.thinpooldev=/dev/mapper/thin-pool
  • dm.basesize

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

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

使用例：

$ dockerd --storage-opt dm.basesize=50G

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

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

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

使用例：

$ dockerd --storage-opt dm.basesize=20G
  • dm.loopdatasize

注釈

この設定はデバイスマッパーのループバックを変更するものです。プロダクションで使うべきではありません。

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

使用例：

$ dockerd --storage-opt dm.loopdatasize=200G
  • dm.loopmetadatasize

注釈

この設定はデバイスマッパーのループバックを変更するものです。プロダクションで使うべきではありません。

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

使用例：

$ dockerd –storage-opt dm.loopmetadatasize=4G
  • dm.fs

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

使用例：

$ dockerd --storage-opt dm.fs=ext4
  • dm.mkfsarg

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

使用例：

$ dockerd --storage-opt "dm.mkfsarg=-O ^has_journal"
  • dm.mountopt

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

使用例：

$ dockerd –storage-opt dm.mountopt=nodiscard
  • dm.datadev

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

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

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

使用例：

$ dockerd \
      --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

使用例：

$ dockerd \
      --storage-opt dm.datadev=/dev/sdb1 \
      --storage-opt dm.metadatadev=/dev/sdc1
  • dm.blocksize

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

使用例：

$ dockerd --storage-opt dm.blocksize=512K
  • dm.blkdiscard

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

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

使用例：

$ dockerd --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 にします。

$ dockerd --storage-opt dm.override_udev_sync_check=true

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

注釈

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

  • dm.use_deferred_removal

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

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

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

使用例：

$ dockerd --storage-opt dm.use_deferred_removal=true
  • dm.use_deferred_deletion

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

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

$ dockerd \
      --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 デーモンは停止します。この問題を解決するにはデーモンを再起動してループ・ファイルの容量を増やします。

指定例：

$ dockerd --storage-opt dm.min_free_space=10%

ZFS オプション

  • zfs.fsname

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

使用例：

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

Btrfs オプション

  • btrfs.min_space

コンテナ用サブボリュームの作成時に、最小容量を指定します。コンテナに --storage-opt 容量 オプションを指定して作成・実行する時、ユーザが btrfs のディスク・クォータを使っていれば、docker は btrfs.min_space より小さな 容量 を指定できないようにします。

Docker ランタイム実行オプション

Docker デーモンは OCI 基準のランタイム（containerd デーモンの呼び出し）に基づいています。これに従いながら Linux カーネルの 名前空間（namespaces） 、 コントロール・グループ（cgroups） 、 SELinux に対するインターフェースとして動作します。

Docker ランタイム実行オプション

Docker デーモンは OCI 規格のランタイムに依存します（ containerd デーモンを経由して呼び出します）。これが Linux カーネルの namespace 、 cgroups 、SELinux のインターフェースとして働きます。

ランタイムはデーモンに登録できます。登録は設定ファイルを通してか、あるいは、コマンドラインの引数 --add-runtime を使います。

以下の例は、設定ファイルを通して２つのランタイムを追加しています。

"default-runtime": "runc",
"runtimes": {
    "runc": {
        "path": "runc"
    },
    "custom": {
        "path": "/usr/local/bin/my-runc-replacement",
        "runtimeArgs": [
            "--debug"
        ]
    }
}

これは、コマンドライン上で次のように実行するのと同じです。

$ sudo dockerd --add-runtime runc=runc --add-runtime custom=/usr/local/bin/my-runc-replacement

注釈

ランタイム引数はコマンドラインを経由して定義できません（サポートされていません）。

ランタイム用のオプション

ランタイムのオプションは --exec-opt フラグで指定できます。全てのオプションのフラグには、先頭に native が付きます。（現時点では）唯一 native.cgroupdriver オプションを利用可能です。

native.cgroupdriver オプションはコンテナの cgroups 管理を指定します。 systemd の cgroupfs で指定可能です。 systemd で指定時、対象が利用可能でなければ、システムはエラーを返します。 native.cgroupdriver オプションを指定しなければ cgroupfs を使います。

次の例は systemd に cgroupdriver を指定しています。

$ sudo dockerd --exec-opt native.cgroupdriver=systemd

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

また、Windows コンテナであれば特別な目的のために --exec-opt を使えます。Docker がデフォルトで使うコンテナの分離技術の指定です。指定例：

$ dockerd --exec-opt isolation=hyperv

この指定は Windows 上のデフォルト分離技術 hyperv を使います。デーモン起動時に分離技術の指定が無ければ、Windows クライアントはデフォルトで hyper-v を使い、Windows server はデフォルトで process を使います。

デーモンの DNS オプション

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

全ての Docker コンテナ用の DNS 検索ドメインを設定するには、 dockerd --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 という２つの形式のオプションが必要です。

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

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

安全ではないレジストリを「安全ではない」と指定しなければ、 docker pull 、 docker push 、 docker 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 レジストリへの push 、 pull 、 login を阻止します。例外として、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://ユーザ名:パスワード@proxy:port/ dockerd を付けて起動します。 ユーザ名: と パスワード@ はオプションです。そして、プロ指揮の認証設定も必要であれば追加します。

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

Ulimits のデフォルト

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

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

ノードのディスカバリ（検出）

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

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

dockerd \
    --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 daemond で --authorization-plugin=PLUGIN_ID オプションを使って起動します。

dockerd --authorization-plugin=plugin1 --authorization-plugin=plugin2,...

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

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

認証プラグインの作成方法については、この 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 にエントリが追加されます。

注釈

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

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

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

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

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

注釈

Fedora 22 では、ユーザ作成時に範囲を割り当てるために必要な /etc/subuid と /etc/subgid ファイルを touch コマンドで作成する必要があります。この作業は --usernsremap オプションを有効にする前に行わなくてはいけません。ファイルが存在していれば、ユーザが作成した処理が範囲で処理が適切に行われるよう、デーモンを（再）起動できます。

例：default の Docker ユーザ管理

$ dockerd --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

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

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

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

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

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

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

  1. 特定ユーザに対する範囲のセグメント（区分）が見つれば、開始 ID を昇順でソートします。
  1. セグメントの割り当てには、各セグメントの長さに一致するよう、範囲の値を増やします。そうすると、セグメントの範囲は最も低い数値から始まり、これを root として再割り当てし、あとはホスト側の uid/gid と一致する範囲まで繰り返します。例えば、最小セグメントの ID が 1000 から始まり、長さが 100 としたら、 1000 を 0 にマップし（root として再マップ）ます。これを対象セグメントでは 1100 が 100 にマップするまで続けます。次のセグメントは ID 10000 から始まる場合、次は 10000 が 101 にマップし、その長さの分だけ処理します。この処理を対象ユーザのサボーディネート（従属）ファイルに空きセグメントが無くなるまで繰り返します。
  1. ユーザ向けのセグメント範囲が無くなった場合は、カーネルで５つまで使えるよう制限されているエントリ /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 であったとしてもデバイス作成の権限がありません。

その他のオプション

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/dockerd -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 を作成します。

systemd cgroup ドライバは --cgroup-parent と異なるルールです。Systemd のリソース階層は、スライス（訳者注：systemd における CPU やメモリなどのリソースを分割する単位のこと）とツリー上でスライスをエンコードする場所の名前で表します。そのため systemd cgroups 用の --cgroup-parent はスライス名と同じにすべきです。名前はダッシュ区切りの名前で構成します。つまりルート・スライスからのスライスに対するパスです。例えば --cgroup-parent=user-a-b.slice を指定する意は、コンテナ用の cgroup を /sys/fs/cgroup/memory/user.slice/user-a.slice/user-a-b.slice/docker-<id>.scope に割り当てます。

これらの指定はコンテナに対しても可能です。 docker create と docker 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": "",
     "max-concurrent-downloads": 3,
     "max-concurrent-uploads": 5,
     "debug": true,
     "hosts": [],
     "log-level": "",
     "tls": true,
     "tlsverify": true,
     "tlscacert": "",
     "tlscert": "",
     "tlskey": "",
     "api-cors-header": "",
     "selinux-enabled": false,
     "userns-remap": "",
     "group": "",
     "cgroup-parent": "",
     "default-ulimits": {},
       "ipv6": false,
       "iptables": false,
       "ip-forward": false,
       "ip-masq": false,
       "userland-proxy": false,
       "ip": "0.0.0.0",
       "bridge": "",
       "bip": "",
       "fixed-cidr": "",
       "fixed-cidr-v6": "",
       "default-gateway": "",
       "default-gateway-v6": "",
       "icc": false,
       "raw-logs": false,
       "registry-mirrors": [],
       "insecure-registries": [],
       "disable-legacy-registry": false,
       "default-runtime": "runc",
       "runtimes": {
           "runc": {
               "path": "runc"
           },
           "custom": {
               "path": "/usr/local/bin/my-runc-replacement",
               "runtimeArgs": [
                   "--debug"
               ]
            }
       }
}

設定の再読み込み

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

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

  • debug ：true を設定したら、デーモンをデバッグ・モードにします。
  • cluster-store ：新しいアドレスにディスカバリ・ストアを読み込み直します。
  • cluster-store-opts ：ディスカバリ・ストアを読み込む時の新しいオプションを指定します。
  • cluster-advertise ：再起動後のアドバタイズド・アドレスを指定します。
  • labels ：デーモンのラベルを新しく設定したものに変えます。
  • max-concurrent-downloads ：pull ごとの最大同時ダウンロード数を更新します。
  • max-concurrent-uploads ：push ごとの最大同時アップロード数を更新します。
  • default-runtime ：デフォルトのランタイム（コンテナ作成時にランタイムの指定がない場合）を更新します。「デフォルト」とは Docker 公式パッケージに含まれるランタイムを意味します。
  • runtimes ：コンテナ実行時に利用可能な OCI ランタイムの一覧です。

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

複数のデーモンを実行

注釈

単一ホスト上での複数デーモンの実行は「実験的」機能です。利用者は、未解決問題に注意すべきです。この解決方法は、特定条件下で動作しない可能性があります。解決方法は現在開発中であり、近いうちに解決されるでしょう。

このセクションの説明は、単一ホスト上で複数の Docker デーモンを実行する方法です。複数のデーモンを実行するには、各デーモンごとに同一ホスト上で重複しないような設定が必要です。各オプションはフラグを使って指定するか、あるいは デーモン設定ファイル で指定します。

各デーモンで以下のオプション指定が必須です：

-b, --bridge=                          コンテナがアタッチするネットワーク・ブリッジ
--exec-root=/var/run/docker            Docker 実行ドライバのルート
-g, --graph=/var/lib/docker            Docker ランタイムのルート
-p, --pidfile=/var/run/docker.pid      デーモンの PID ファイルに使うパス
-H, --host=[]                          デーモンが接続するソケット
--config-file=/etc/docker/daemon.json  Daemon 設定ファイル
--tlscacert="~/.docker/ca.pem"         信頼できる認証局で署名された証明書
--tlscert="~/.docker/cert.pem"         TLS 証明書ファイルのパス
--tlskey="~/.docker/key.pem"           TLS 鍵ファイルのパス

デーモンに対してフラグ用に異なる値を指定したら、同じホスト上でも、別のデーモンを問題なく起動できます。各オプションと使い方を適切に理解するのは、非常に重要です。

  • -b, --bridge= フラグはデフォルトのブリッジ・ネットワークとして docker0 を指定します。これは Docker インストール時に自動作成されます。デフォルトで使いたくなければ、手動で何らかのブリッジを作成して設定するか、あるいは none を --bridge=none で指定します。
  • --exec-root はコンテナの状態を補完するパスです。デフォルトの値は /var/run/docker です。ここで docker デーモンを実行するパスを指定します。
  • --graph はイメージを保存する場所です。デフォルト値は /var/lib/docker です。デーモンごとに別々のパラメータを指定し、重複しないようにする必要があります。
  • -p, --pidfile=/var/run/docker.pid はデーモンのプロセス ID を保存する場所です。PID ファイルのパスを指定します。
  • --host=[] には、 Docker デーモンがクライアントからの接続をリッスンする場所を指定します。指定しなければ、デフォルトは /var/run/docker.sock です。
  • --config-file=/etc/docker/daemon.json は設定ファイルがあるパスです。デーモンのフラグの代わりに、こちらで指定できます。各デーモンごとにパスの指定が必要です。
  • --tls* は Docker デーモンが `--tlsverify （TLS認証）モードを有効化します。これはリモート接続時に暗号化と認証を義務づけます。 --tls* オプションを有効にするには、デーモンごとに証明書を指定する必要があります。

次の例は、「bootstrap」インスタンスとして、ネットワークを持たない Docker デーモンを起動します。

$ docker daemon \
        -H unix:///var/run/docker-bootstrap.sock \
        -p /var/run/docker-bootstrap.pid \
        --iptables=false \
        --ip-masq=false \
        --bridge=none \
        --graph=/var/lib/docker-bootstrap \
        --exec-root=/var/run/docker-bootstrap

参考

daemon
https://docs.docker.com/engine/reference/commandline/daemon/