dockerd daemon

目次

Usage: dockerd COMMAND

A self-sufficient runtime for containers.

Options:
      --add-runtime runtime                   Register an additional OCI compatible runtime (default [])
      --allow-nondistributable-artifacts list Allow push of nondistributable artifacts to registry
      --api-cors-header string                Set CORS headers in the Engine API
      --authorization-plugin list             Authorization plugins to load
      --bip string                            Specify network bridge IP
  -b, --bridge string                         Attach containers to a network bridge
      --cgroup-parent string                  Set parent cgroup for all containers
      --config-file string                    Daemon configuration file (default "/etc/docker/daemon.json")
      --containerd string                     containerd grpc address
      --containerd-namespace string           Containerd namespace to use (default "moby")
      --containerd-plugins-namespace string   Containerd namespace to use for plugins (default "plugins.moby")
      --cpu-rt-period int                     Limit the CPU real-time period in microseconds for the
                                              parent cgroup for all containers
      --cpu-rt-runtime int                    Limit the CPU real-time runtime in microseconds for the
                                              parent cgroup for all containers
      --cri-containerd                        start containerd with cri
      --data-root string                      Root directory of persistent Docker state (default "/var/lib/docker")
  -D, --debug                                 Enable debug mode
      --default-address-pool pool-options     Default address pools for node specific local networks
      --default-cgroupns-mode string          Default mode for containers cgroup namespace ("host" | "private") (default "host")
      --default-gateway ip                    Container default gateway IPv4 address
      --default-gateway-v6 ip                 Container default gateway IPv6 address
      --default-ipc-mode string               Default mode for containers ipc ("shareable" | "private") (default "private")
      --default-runtime string                Default OCI runtime for containers (default "runc")
      --default-shm-size bytes                Default shm size for containers (default 64MiB)
      --default-ulimit ulimit                 Default ulimits for containers (default [])
      --dns list                              DNS server to use
      --dns-opt list                          DNS options to use
      --dns-search list                       DNS search domains to use
      --exec-opt list                         Runtime execution options
      --exec-root string                      Root directory for execution state files (default "/var/run/docker")
      --experimental                          Enable experimental features
      --fixed-cidr string                     IPv4 subnet for fixed IPs
      --fixed-cidr-v6 string                  IPv6 subnet for fixed IPs
  -G, --group string                          Group for the unix socket (default "docker")
      --help                                  Print usage
  -H, --host list                             Daemon socket(s) to connect to
      --host-gateway-ip ip                    IP address that the special 'host-gateway' string in --add-host resolves to.
                                              Defaults to the IP address of the default bridge
      --icc                                   Enable inter-container communication (default true)
      --init                                  Run an init in the container to forward signals and reap processes
      --init-path string                      Path to the docker-init binary
      --insecure-registry list                Enable insecure registry communication
      --ip ip                                 Default IP when binding container ports (default 0.0.0.0)
      --ip-forward                            Enable net.ipv4.ip_forward (default true)
      --ip-masq                               Enable IP masquerading (default true)
      --iptables                              Enable addition of iptables rules (default true)
      --ip6tables                             Enable addition of ip6tables rules (default false)
      --ipv6                                  Enable IPv6 networking
      --label list                            Set key=value labels to the daemon
      --live-restore                          Enable live restore of docker when containers are still running
      --log-driver string                     Default driver for container logs (default "json-file")
  -l, --log-level string                      Set the logging level ("debug"|"info"|"warn"|"error"|"fatal") (default "info")
      --log-opt map                           Default log driver options for containers (default map[])
      --max-concurrent-downloads int          Set the max concurrent downloads for each pull (default 3)
      --max-concurrent-uploads int            Set the max concurrent uploads for each push (default 5)
      --max-download-attempts int             Set the max download attempts for each pull (default 5)
      --metrics-addr string                   Set default address and port to serve the metrics api on
      --mtu int                               Set the containers network MTU
      --network-control-plane-mtu int         Network Control plane MTU (default 1500)
      --no-new-privileges                     Set no-new-privileges by default for new containers
      --node-generic-resource list            Advertise user-defined resource
      --oom-score-adjust int                  Set the oom_score_adj for the daemon (default -500)
  -p, --pidfile string                        Path to use for daemon PID file (default "/var/run/docker.pid")
      --raw-logs                              Full timestamps without ANSI coloring
      --registry-mirror list                  Preferred Docker registry mirror
      --rootless                              Enable rootless mode; typically used with RootlessKit
      --seccomp-profile string                Path to seccomp profile
      --selinux-enabled                       Enable selinux support
      --shutdown-timeout int                  Set the default shutdown timeout (default 15)
  -s, --storage-driver string                 Storage driver to use
      --storage-opt list                      Storage driver options
      --swarm-default-advertise-addr string   Set default address or interface for swarm advertised address
      --tls                                   Use TLS; implied by --tlsverify
      --tlscacert string                      Trust certs signed only by this CA (default "~/.docker/ca.pem")
      --tlscert string                        Path to TLS certificate file (default "~/.docker/cert.pem")
      --tlskey string                         Path to TLS key file (default "~/.docker/key.pem")
      --tlsverify                             Use TLS and verify the remote
      --userland-proxy                        Use userland proxy for loopback traffic (default true)
      --userland-proxy-path string            Path to the userland proxy binary
      --userns-remap string                   User/Group setting for user namespaces
      --validate                              Validate daemon configuration and exit
  -v, --version                               Print version information and quit

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

説明

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

デーモンにデバッグ情報を出力するには、 dockerd --debug を使って実行するか、 daemon.json ファイル(daemon-configuration-file) に "debug": true を追加します。

環境変数

簡単なリファレンスとして、 dockerd コマンドラインは以下の環境変数をサポートします。

• DOCKER_DRIVER 使用するグラフ ドライバ

• DOCKER_NOWARN_KERNEL_VERSION Linux カーネルが Docker に不適当でも警告を表示しない

• DOCKER_RAMDISK 設定すると、「pivot_root」を無効化

• DOCKER_TMPDIR 一時的な Docker ファイルの場所

• MOBY_DISABLE_PIGZ イメージの取得時、並列レイヤ圧縮には unpigz がインストールされていても使用しない

使用例

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

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 クライアントは、リモートのデーモンに SSH を経由した接続をサポートしています。

$ docker -H ssh://me@example.com:22 ps
$ docker -H ssh://me@example.com ps
$ docker -H ssh://example.com ps

SSH 接続を使うには、リモートホストに公開鍵認証による ssh をセットアップする必要があります。パスワード認証はサポートしています。鍵がパスフレーズで保護されている場合、 ssh-agent のセットアップが必要です。

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

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

Linux では、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 でメインにマージされました。また、 overlay は ページキャッシュ共有(page cache sharing) も竿ポートしています。つまり、複数のコンテナで1つのページキャッシュのエントリ（あるいは全体）を共有できるため、 overlay は aufs ドライバよりもメモリが効率的です。

｡.. The overlay2 uses the same fast union filesystem but takes advantage of additional features added in Linux kernel 4.0 to avoid excessive inode consumption. Call dockerd -s overlay2 to use it.

overlay2 は同じく速いユニオン・ファイルシステムを使いますが、 Linux カーネル 4.0 で追加された過度の inode 消費を抑制する 追加機能 を利用できる利点があります。使うには dockerd -s overlay2 を実行します。

注釈

overlay ストレージドライバは、過度の inode を消費する可能性があります（特に、イメージ数が増加すると）。そのかわり、 overlay2 ストレージドライバの利用を推奨します。

注釈

overlay と overlay2 は、どちらも btrfs をサポートしていないため、あらゆるファイルシステムへのコピーや書き込みは、 ext4 パーティション上のみを利用すべきです。

fuse-overlayfs ドライバは overlay2 と似ていますが、 ユーザスペース(userspace) 内で動作します。 fuse-overlayfs ドライバは、 Rootless モード での利用が想定されています。

Window では、Docker デーモンがサポートしているのは、 単一イメージ・レイヤのストレージ・ドライバに依存します。Windows イメージ用のは``windowsfilter`` であり、 Windows 上の Linux コンテナは lcow です。

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

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

devicemapper のオプション

これは Linux 上の deviemapper 用の設定ファイルを使う例です。

{
  "storage-driver": "devicemapper",
  "storage-opts": [
    "dm.thinpooldev=/dev/mapper/thin-pool",
    "dm.use_deferred_deletion=true",
    "dm.use_deferred_removal=true"
  ]
}

dm.thinpooldev

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

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

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

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

使用例：

$ sudo dockerd --storage-opt dm.thinpooldev=/dev/mapper/thin-pool

dm.directlvm_device

先述とは別の thin pool を指定します。Docker で使いたいブロックデバイスを指定できます。

使用例：

$ sudo dockerd --storage-opt dm.directlvm_device=/dev/xvdf

dm.thinp_percent

ストレージに使うための、ブロックデバイスのパーセントを指定します。

使用例：

$ sudo dockerd --storage-opt dm.thinp_percent=95

dm.thinp_metapercent

メタデータのストレージに使うための、ブロックデバイスのパーセント指定します。

使用例：

$ sudo dockerd --storage-opt dm.thinp_metapercent=1

dm.thinp_autoextend_threshold

lvm が利用可能なスペースに自動展開する前に、使用する値をパーセントで指定します（ 100 = 無効化 ）。

使用例：

$ sudo dockerd --storage-opt dm.thinp_autoextend_threshold=80

dm.thinp_autoextend_percent

lvm が利用可能なスペースに自動展開する場合、 thin pool が増加する値をパーセントで指定します（ 100 = 無効化 ）。

使用例：

$ sudo dockerd --storage-opt dm.thinp_autoextend_percent=20

dm.basesize

ベース・デバイスの生成に使う容量を指定します。これはイメージやコンテナのサイズを制限します。デフォルト値は 10G です。なお thin device は基本的に「 まばら(sparse) 」のため、デバイス上の10 G はほとんどが空となり、プール上で 10G を占有しません。ただしデバイスが大きくなればなるほど、ファイルシステムが扱う空データはより多くなります。

ベース・デバイスの容量は、デーモンの再起動によって増えます。再起動により、以後生成されるイメージやコンテナ（その新たなイメージに基づくもの）は、新たなベース・デバイスの容量に基づいて生成されます。

使用例：

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

これはベース・デバイス容量を 50GB に増やしています。ベース・デバイス容量が元から 50 G よりも大きかった場合には、Docker デーモンはエラーを出力します。ユーザはこのオプションを使ってベース・デバイス容量を拡張できますが、縮小はできません。

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

$ sudo service docker stop

$ sudo rm -rf /var/lib/docker

$ sudo service docker start

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 カーネル用のデバイスマッパーです。

devicemapper ドライバーを利用する Docker デーモンが udev 同期をサポートしているかどうかは、以下を実行して確認できます。

$ docker info
<...>
Udev Sync Supported: true
<...>

udev 同期サポートが true であれば、devicemapper と udev は連携してコンテナ向けデバイスの有効化、無効化を行います。

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

udev 同期がサポートされているかどうかに関係なく docker デーモンを起動するならば、dm.override_udev_sync_check を true に設定してください。

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

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

注釈

理想的には udev との同期をサポートする docker デーモンおよび環境を目指すべきところです。これに関してのさらなるトピックは docker#4036 をご覧ください。これができない限りは、既存の Docker デーモンが動作する環境上において、正常動作するように本フラグを設定してください。

dm.use_deferred_removal

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

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

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

使用例：

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

dm.use_deferred_deletion

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

Error deleting container: Error response from daemon: Cannot destroy container

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

$ sudo 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%

dm.xfs_nospace_max_retries

ENOSPC（空き容量がない）エラーがストレージドライバで発生した時 、完全な IO を試みるため、 XFS が再試行する上限数を指定します。

デフォルトの XFS は IO が完了するまで無限に繰り返すため、結果として停止不可能なプロセスが発生する可能があります。この挙動を変更するには、xfs_nospace_max_retries を 0 にし、XFS が ENOSPC の後に IO を再試行せず、ファイルシステムをシャットダウンします。

使用例：

$ sudo dockerd --storage-opt dm.xfs_nospace_max_retries=0

dm.libdm_log_level

値の指定は、有効な libdm ログレベル範囲内に収める必要があります。以下の libdm ログレベル一覧にあるものから、 dockerd による適切なレベルに応じて書き込まれます。

libdm レベル	値	--log-level
_LOG_FATAL	2	error
_LOG_ERR	3	error
_LOG_WARN	4	warn
_LOG_NOTICE	5	info
_LOG_INFO	6	info
_LOG_DEBUG	7	debug

使用例：

$ sudo dockerd \
      --log-level debug \
      --storage-opt dm.libdm_log_level=7

ZFS オプション

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

使用例：

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

Btrfs オプション

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

$ docker daemon -s btrfs --storage-opt btrfs.min_space=10G

overlay2 のオプション

overlay2.override_kernel_check

Linux カーネルのバージョンチェックで overlay2 の許可を上書きします。Linux カーネル 4.0.0 では overlay2 が必要とする複数の低位ディレクトリの指定をサポートしました。しかしながら、いくつかの古いカーネルでは、 OverlayFS が複数の低位ディレクトリをサポートするためにパッチが適用されている可能性があります。このオプションは、カネール上でサポート対象であることを確認している場合のみ使うべきです。このオプションをサポートしていないカーネル上で実行すると、マウントに失敗します。

overlay2.size

コンテナのデフォルト 最大容量(max size) を指定します。サポートされているのは、バックエンドのファイルシステムが xfs かつ pquota マウントオプションでマウントしている場合のみです。ユーザが指定できる容量は、バックエンドのファイルシステムの容量以下です。

使用例

$ sudo dockerd -s overlay2 --storage-opt overlay2.size=1G

windowsfilter のオプション

size

コンテナが使用するサンドボックスの作成時に使う容量を指定します。デフォルトは 20GB です。

使用例

C:\> dockerd --storage-opt size=40G

LCOW (Windows の Linux コンテナ）オプション

lcow.globalmode

デーモンに対して必要とされるユーティリティ VM インスタンスの例示を指定（推奨かつ、省略時はデフォルト）するか、1つのグローバル・ユーティリティ VM （優れたパフォーマンスですが、セキュリティ関連でプロダクションへのデプロイは推奨されません）を使います。

使用例

C:\> dockerd --storage-opt lcow.globalmode=false

lcow.kirdpath

ユーティリティ VM を起動するために使う、カーネルと initrd ファイルのセットが入っているフォルダを指定します。デフォルトは %ProgramFiles%\Linux Containers です。

使用例

C:\> dockerd --storage-opt lcow.kirdpath=c:\path\to\files

lcow.kernel

カーネルのファイルが置かれている cow.kirdpath パスにあるファイル名を指定します。デフォルトは bootx64.efi です。

使用例

C:\> dockerd --storage-opt lcow.kernel=kernel.efi

lcow.initrd

initrd ファイルが置かれている cow.kirdpath パスにあるファイル名を指定します。デフォルトは initrd.img です。

使用例

C:\> dockerd --storage-opt lcow.initrd=myinitrd.img

lcow.bootparameters

kernel/initrd モードでは、ユーティリティ VM をッ起動するための起動パラメータを追加で指定します。ユーティリティ VM を VHD から起動する場合には、無視されミズ会う。それぞれの設定はカーネルに依存します。

使用例

C:\> dockerd --storage-opt "lcow.bootparameters='option=value'"

lcow.vhdx

起動時に、代替カーネルと initrd を使う、ユーティリティ VM として起動するカスタム VHDX を指定します。デフォルトは lcow.kirdpath 以下の uvm.vhdx です。

使用例

C:\> dockerd --storage-opt lcow.vhdx=custom.vhdx

lcow.timeout

ユーティリティ VM 操作のタイムアウトを秒で指定します。デフォルトは 300 です。

使用例

C:\> dockerd --storage-opt lcow.timeout=240

lcow.sandboxsize

コンテナが使うサンドボックスの作成時、使用する容量を GB で指定します。デフォルトは 20 です。 20 以下にはできません。

使用例

C:\> dockerd --storage-opt lcow.sandboxsize=40

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

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

デフォルトでは、 Docker デーモンは自動的に containerd を起動します。 containerd の起動を制御したい場合は、手動で containerd の起動時、 --containerd フラグを使って containerd ソケットのパスを指定します。以下は実行例です。

$ sudo dockerd --containerd /var/run/dev/docker-containerd.sock

ランタイムはデーモンに登録できます。登録は設定ファイルを通してか、あるいは、コマンドラインの引数 --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 を使います。 native.cgroupdriver `` オプションを省略すると、 ``cgroupfs は cgroup v1 ホストを使い、 systemd が利用可能であれば systemd は cgroup v2 ホストを使います。

次の例は 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 サーバを指定するには、次のようにします。

$ sudo dockerd --dns 8.8.8.8

全てのコンテナが使う DNS 検索ドメインを設定するには、次のようにします。

$ sudo dockerd --dns-search example.com

配布不可能(nondistributable) な アーティファクト(artifact) の送信を許可

イメージによっては（例： Windows ベースのイメージ）、ライセンスによって配布が制限されているアーティファクトを含む場合があります。これらイメージをレジストリに送信しようとしても、制限されたアーティファクトは含まれません。

特定の制限に対するこの挙動を上書きするには、以下の形式どちらかで --allow-nondistributable-artifacts オプションを使います。

• --allow-nondistributable-artifacts myregistry:5000 は、 Docker デーモンに対して myregistry:500 へ配布不可能なアーティファクトを送信するよう命令します。

• --allow-nondistributable-artifacts 10.1.0.0/16 は、 Docker デーモンに対し、 CIDR 構文で記述されたサブネット範囲内で、 IP アドレスの名前解決ができる全てのレジストリに対し、配布不可能なアーティファクトを送信するよう命令します。

このオプションは何回も使えます。

配布不可能なアーティファクトを含むイメージを エアギャップ・ネットワーク(air-gapped network) （訳者注：空気で絶縁されているかのように、到達できないネットワークの意味）上のレジストリに送信を許可する場合は、他のサーバに接続しなくてもイメージを取得できるようになるため、このオプションが役立ちます。

警告

配布不可能アーティファクトは、典型的に、どのように、どこで配布や共有ができるか制限があります。この機能を、アーティファクトをプライベート・レジストリに送信するために使う場合、配布不可能なアーティファクトの再配布に関する利用条件に従ってください。

安全ではないレジストリ(insecure registry)

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 パッケージをインストールします。

2. ネットワーク管理者にプロキシの CA 証明書を訊ね、 /etc/pki/tls/certs/ca-bundle.crt に追加します。

3. 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 がユーザに対して利用可能な最大プロセス数を設定するものであり、コンテナ向けではありません。詳細については、 docker 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

現在サポートされているクラスタ・ストアのオプションは、i以下の通りです。

オプション	説明
discovery.heartbeat	ハートビート・タイマーを秒で指定します。これはデーモンの keepalive メカニズムによって、クラスタ上に存在するノードを利用可能にするためのディスカバリ・モジュールが機能するようにします。
discovery.ttl	TTL（time-to-live）を秒で指定します。これは有効なハートビートを指定した ttl 値以内に受信できなければ、ディスカバリ・モジュールがノードをタイムアウトするために使います。
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 ドキュメントの拡張に関するセクションにある 認証プラグイン をご覧ください。

デーモンの ユーザ名前空間(user namespace) オプション

---

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

この機能の使い方に関する詳細や制限は、 </engine/security/userns-remap> をご覧ください。

その他のオプション

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 を設定します。このオプションが指定されていない場合、デフォルトは fs cgroup ドライバに対しては /docker となり、systemd cgroup ドライバに対しては system.slice となります。

cgroup の先頭がスラッシュ（ / ）で始まる場合、この cgroup はルート cgroup のもとに生成され、そうでない場合はデーモン cgroup のもとに生成されます。

デーモンが仮に daemoncgroup という cgroup 内で実行されているとすると、 --cgroup-parent=/foobar という指定を行うと、cgroup は /sys/fs/cgroup/memory/foobar のもとに生成されます。一方 --cgroup-parent=foobar と指定すると、cgroup は /sys/fs/cgroup/memory/daemoncgroup/foobar のもとに生成されます。

systemd cgroup ドライバには --cgroup-parent に対して別ルールがあります。systemd はスライス（訳者注：systemd における CPU やメモリなどのリソースを分割する単位のこと）による階層構造により表現され、そのスライス名はツリー内の場所をエンコードしています。したがって systemd cgroups に対する --cgroup-parent の設定値はスライス名とします。1 つの名前は、一連の名前をダッシュで区切って構成します。これが、そのスライスに対するルートスライスからのパスを表します。たとえば --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 オプションよりも優先して適用されます。

デーモンのメトリクス

--metrics-addr オプションは、メトリクス API を提供する TCP アドレスを渡します。この機能はまだ実験的です。そのため、この機能を使うためには、実験的モードでデーモンを実行する必要があります。

メトリクス API を localhost:9323 で提供するには、 --metrics-addr 127.0.0.1:9323 を指定します。これにより、 127.0.0.1:9323/metrics の API にリクエストを送ると、 prometheus 形式でメトリクスを受信できます。

ポート 9323 は Docker メトリクスに関連づけられているデフォルトのポート であり、他の prometheus exporter とサービスと衝突しないようにしています。

prometheus サーバを実行中であれば、このアドレスを使って Docker 上のメトリクスを prometheus が収集できるようスクレイプを設定できます。prometheus の詳しい情報は prometheus のウェブサイト をご覧ください。

scrape_configs:
  - job_name: 'docker'
    static_configs:
      - targets: ['127.0.0.1:9323']

この機能は実験的な段階であり、メトリクスとメトリクス名は実験的な機能である間に変わる可能性があるのでご注意ください。API での収集に関するフィードバックを提供ください。

ノードに属する(node generic) リソース

--node-generic-resources オプションはキーバリューのペア（ key=value ）を指定子、swarm クラスタ内にユーザ定義リソースを 通知します(advertise) 。

現時点で想定している使用例は、 NVIDIA GPU の通知です。 NVIDIA-GPU=[0-16] を要求するサービスは、タスクを実行可能なノート上での処理を可能にします。

使用例：

{
  "node-generic-resources": [
    "NVIDIA-GPU=UUID1",
    "NVIDIA-GPU=UUID2"
  ]
}

デーモン設定ファイル

--config-file オプションを使えば、デーモンに対する設定オプションを JSON 形式で指定できます。このファイルでは、フラグと同じ名前をキーとします。ただし、複数の項目を指定可能なフラグの場合は、キーを複数形で指定します（例： label フラグの指定は labels になります ）。

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

Linux の場合

デフォルトは、 Linux の場合は /etc/docker/daemon.json にある設定ファイルを Docker が読み込もうとします。デフォルトではない場所の指定に --config-file オプションが使えます。

次の例は、Linux で利用可能な全てのオプションをファイルに記述したものです。

{
  "allow-nondistributable-artifacts": [],
  "api-cors-header": "",
  "authorization-plugins": [],
  "bip": "",
  "bridge": "",
  "cgroup-parent": "",
  "cluster-advertise": "",
  "cluster-store": "",
  "cluster-store-opts": {},
  "containerd": "/run/containerd/containerd.sock",
  "containerd-namespace": "docker",
  "containerd-plugin-namespace": "docker-plugins",
  "data-root": "",
  "debug": true,
  "default-address-pools": [
    {
      "base": "172.30.0.0/16",
      "size": 24
    },
    {
      "base": "172.31.0.0/16",
      "size": 24
    }
  ],
  "default-cgroupns-mode": "private",
  "default-gateway": "",
  "default-gateway-v6": "",
  "default-runtime": "runc",
  "default-shm-size": "64M",
  "default-ulimits": {
    "nofile": {
      "Hard": 64000,
      "Name": "nofile",
      "Soft": 64000
    }
  },
  "dns": [],
  "dns-opts": [],
  "dns-search": [],
  "exec-opts": [],
  "exec-root": "",
  "experimental": false,
  "features": {},
  "fixed-cidr": "",
  "fixed-cidr-v6": "",
  "group": "",
  "hosts": [],
  "icc": false,
  "init": false,
  "init-path": "/usr/libexec/docker-init",
  "insecure-registries": [],
  "ip": "0.0.0.0",
  "ip-forward": false,
  "ip-masq": false,
  "iptables": false,
  "ip6tables": false,
  "ipv6": false,
  "labels": [],
  "live-restore": true,
  "log-driver": "json-file",
  "log-level": "",
  "log-opts": {
    "cache-disabled": "false",
    "cache-max-file": "5",
    "cache-max-size": "20m",
    "cache-compress": "true",
    "env": "os,customer",
    "labels": "somelabel",
    "max-file": "5",
    "max-size": "10m"
  },
  "max-concurrent-downloads": 3,
  "max-concurrent-uploads": 5,
  "max-download-attempts": 5,
  "mtu": 0,
  "no-new-privileges": false,
  "node-generic-resources": [
    "NVIDIA-GPU=UUID1",
    "NVIDIA-GPU=UUID2"
  ],
  "oom-score-adjust": -500,
  "pidfile": "",
  "raw-logs": false,
  "registry-mirrors": [],
  "runtimes": {
    "cc-runtime": {
      "path": "/usr/bin/cc-runtime"
    },
    "custom": {
      "path": "/usr/local/bin/my-runc-replacement",
      "runtimeArgs": [
        "--debug"
      ]
    }
  },
  "seccomp-profile": "",
  "selinux-enabled": false,
  "shutdown-timeout": 15,
  "storage-driver": "",
  "storage-opts": [],
  "swarm-default-advertise-addr": "",
  "tls": true,
  "tlscacert": "",
  "tlscert": "",
  "tlskey": "",
  "tlsverify": true,
  "userland-proxy": false,
  "userland-proxy-path": "/usr/libexec/docker-proxy",
  "userns-remap": ""
}

注釈

デーモンの起動時に既にフラグが指定されていると、 daemon.json オプションを指定できません。 systemd を使って Docker デーモンを起動するシステム上では、 -H が既に設定されているため、リッスンしているアドレスに加え、 daemon.json で hosts キーを使えません。 任意の docker デーモン・オプション(custom-docker-daemon-options) にある、 systemd 投入ファイルでの処理方法をご覧ください。

Windows の場合

デフォルトは、 Windows の場合は %programdata%\docker\config\daemon.json にある設定ファイルを Docker が読み込もうとします。デフォルトではない場所の指定に --config-file オプションが使えます。

次の例は、Windows で利用可能な全てのオプションをファイルに記述したものです。

{
  "allow-nondistributable-artifacts": [],
  "authorization-plugins": [],
  "bridge": "",
  "cluster-advertise": "",
  "cluster-store": "",
  "containerd": "\\\\.\\pipe\\containerd-containerd",
  "containerd-namespace": "docker",
  "containerd-plugin-namespace": "docker-plugins",
  "data-root": "",
  "debug": true,
  "default-runtime": "",
  "default-ulimits": {},
  "dns": [],
  "dns-opts": [],
  "dns-search": [],
  "exec-opts": [],
  "experimental": false,
  "features": {},
  "fixed-cidr": "",
  "group": "",
  "hosts": [],
  "insecure-registries": [],
  "labels": [],
  "log-driver": "",
  "log-level": "",
  "max-concurrent-downloads": 3,
  "max-concurrent-uploads": 5,
  "max-download-attempts": 5,
  "mtu": 0,
  "pidfile": "",
  "raw-logs": false,
  "registry-mirrors": [],
  "shutdown-timeout": 15,
  "storage-driver": "",
  "storage-opts": [],
  "swarm-default-advertise-addr": "",
  "tlscacert": "",
  "tlscert": "",
  "tlskey": "",
  "tlsverify": true
}

機能のオプション

daemon.json のオプション・フィールド features により、ユーザは特定のデーモン機能を有効または無効にできます。あとえば、 {"features":{"buildkit": true}} はデフォルトの docker イメージ・ビルダとして buildkit を有効にします。

現時点でサポートしている機能のオプションは、以下の通りです。

• buildkit ： true を指定すると、デフォルトのビルダとして buildkit を有効化し、 false では無効化します。このオプションはデーモンの設定ファイル中で明示できないため、どのビルダ使うかは、処理するコマンドライン・クライアントに依存します。

設定を再読込時の挙動

---

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

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

• debug ：true を設定したら、デーモンをデバッグ・モードにします。

• cluster-store ：新しいアドレスにディスカバリ・ストアを読み込み直します。

• cluster-store-opts ：ディスカバリ・ストアを読み込む時の新しいオプションを指定します。

• cluster-advertise ：再起動後のアドバタイズド・アドレスを指定します。

• labels ：デーモンのラベルを新しく設定したものに変えます。

• live-restore ：デーモンの停止期間中もコンテナ実行を維持 :doc:` </config/containers/live-restore>` を有効化します。

• max-concurrent-downloads ：pull ごとの最大同時ダウンロード数を更新します。

• max-concurrent-uploads ：push ごとの最大同時アップロード数を更新します。

• default-runtime ：デフォルトのランタイム（コンテナ作成時にランタイムの指定がない場合）を更新します。「デフォルト」とは Docker 公式パッケージに含まれるランタイムを意味します。

• runtimes ：コンテナ実行時に利用可能な OCI ランタイムの一覧です。

• authorization-plugin ：使用する認証プラグインを指定します。

• allow-nondistributable-artifacts ：レジストリの設定を置き換え、デーモンが配布不可能なアーティファクトを、新しいレジストリのセットに送信できるようにします。

• insecure-registries ：デーモンの安全ではないレジストリを、新しいセットの安全ではないレジストリに置き換えます。デーモンの設定を読み込み直した時、かつて設定していた安全ではないレジストリが存在していなければ、デーモンの設定から既存のものが削除されます。

• registry-mirrors ：デーモンのレジストリ・ミラーを、新しいセットのレジストリ・ミラーに置き換えます。デーモンの設定を読み込み直した時、かつて設定していたレジストリ・ミラーが存在していなければ、デーモンの設定から既存のものが削除されます。

• shuwdown-timeout ：全てのコンテナを停止するための、デーモンの既存のタイムアウト設定を、新しいタイムアウトに置き換えます。

• features ：特定の機能を有効化または無効化します。

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

複数のデーモンを実行

注釈

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

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

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

-b, --bridge=                          Attach containers to a network bridge
--exec-root=/var/run/docker            Root of the Docker execdriver
--data-root=/var/lib/docker            Root of persisted Docker data
-p, --pidfile=/var/run/docker.pid      Path to use for daemon PID file
-H, --host=[]                          Daemon socket(s) to connect to
--iptables=true                        Enable addition of iptables rules
--config-file=/etc/docker/daemon.json  Daemon configuration file
--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

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

• -b, --bridge= フラグはデフォルトのブリッジ・ネットワークとして docker0 を指定します。これは Docker インストール時に自動作成されます。デフォルトで使いたくなければ、手動で何らかのブリッジを作成して設定するか、あるいは none を --bridge=none で指定します。

• --exec-root はコンテナの状態を補完するパスです。デフォルトの値は /var/run/docker です。ここで docker デーモンを実行するパスを指定します。

• --data-root はイメージ、ボリューム、クラスタ状態を保存する場所です。デフォルト値は /var/lib/docker です。デーモンごとに別々のパラメータを指定し、重複しないようにする必要があります。

• -p, --pidfile=/var/run/docker.pid はデーモンのプロセス ID を保存する場所です。PID ファイルのパスを指定します。

• --host=[] には、 Docker デーモンがクライアントからの接続をリッスンする場所を指定します。指定しなければ、デフォルトは /var/run/docker.sock です。

• --iptables=false は、Docker デーモンが iptables へのルール追加を阻止します。複数のデーモンが iptables ルールを管理すると、既存のルールが他のデーモンによって上書きされてしまう可能性があります。このオプションを無効化すると、コンテナのポートを公開するためには、手動で iptables のルールを追加する必要があります。 Docker が iptables のルール追加を防止すると、 --ip-masq を true にしていたとしても、 IP マスカレードのルールを追加できず、Docker コンテナは外部ホストへ接続できなかったり、デフォルトのブリッジ以外を使うインターネットに接続できなくなります。

• --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

参考

docker daemon

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