dockerd
読む時間の目安: 28 分
デーモン
利用方法: dockerd <コマンド>
コンテナーに対する独立したランタイム。
オプション:
--add-runtime runtime OCI 準拠の追加ランタイムを登録します。(デフォルトは [])
--allow-nondistributable-artifacts list 配布制限のある成果物を指定レジストリにプッシュします。(デフォルトは [])
--api-cors-header string Engine API において CORS ヘッダーを設定します。
--authorization-plugin list 利用する認証プラグインを指定します。(デフォルトは [])
--bip string ネットワークブリッジ IP を指定します。
-b, --bridge string コンテナーにネットワークブリッジを割り当てます。
--cgroup-parent string 全コンテナーに親 cgroup を設定します。
--cluster-advertise string 通知(advertise)するアドレスまたはインターフェース名。
--cluster-store string 分散ストレージバックエンドの URL。
--cluster-store-opt map クラスターストアオプションを設定します。(デフォルトは map[])
--config-file string デーモン設定ファイル。(デフォルトは "/etc/docker/daemon.json")
--containerd string containerd ソケットへのパス。
--cpu-rt-period int マイクロ秒で指定される CPU のリアルタイム時間(real-time period)を制限します。
--cpu-rt-runtime int マイクロ秒で指定される CPU のリアルタイムランタイム(real-time runtime)を制限します。
--data-root string 永続的な Docker 状態ファイルのルートディレクトリ。(デフォルトは "/var/lib/docker")
-D, --debug デバッグモードを有効にします。
--default-gateway ip コンテナーデフォルトゲートウェイの IPv4 アドレス。
--default-gateway-v6 ip コンテナーデフォルトゲートウェイの IPv6 アドレス。
--default-address-pool ローカルのノードネットワークに対してデフォルトのアドレスプールを設定します。
--default-runtime string コンテナーに対するデフォルトの OCI ランタイム。(デフォルトは "runc")
--default-ulimit ulimit コンテナーにデフォルト ulimit を設定します。(デフォルトは [])
--dns list 利用する DNS サーバー。(デフォルトは [])
--dns-opt list 利用する DNS オプション。(デフォルトは [])
--dns-search list 利用する DNS 検索ドメイン。(デフォルトは [])
--exec-opt list ランタイム実行オプション。(デフォルトは [])
--exec-root string 実行状態ファイルのルートディレクトリ。(デフォルトは "/var/run/docker))
--experimental 試験的機能(experimental features)を有効にします。
--fixed-cidr string 固定 IP に対する IPv4 サブネット。
--fixed-cidr-v6 string 固定 IP に対する IPv6 サブネット。
-G, --group string unix ソケットのグループ。(デフォルトは"docker")
--help 利用方法を表示します。
-H, --host list 接続するデーモンソケット。(デフォルトは [])
--icc コンテナー間の通信を有効にします。(デフォルトは true)
--init コンテナー内に init を実行し、シグナル転送とプロセス回収(reap)を行います。
--init-path string docker-init バイナリへのパス。
--insecure-registry list セキュアでないレジストリとのやりとりを有効にします。(デフォルトは [])
--ip ip コンテナーポートをバインドする際のデフォルト IP。(デフォルトは 0.0.0.0)
--ip-forward net.ipv4.ip_forward を有効にします。(デフォルトは true)
--ip-masq IP マスカレードを有効にします。(デフォルトは true)
--iptables iptables ルールの追加を許可します。(デフォルトは true)
--ipv6 IPv6 ネットワークを有効にします。
--label list デーモンに対してキーバリューラベルを設定します。(デフォルトは [])
--live-restore コンテナー実行中でのライブリストアを有効にします。
--log-driver string コンテナーログに対するデフォルトドライバー。(デフォルトは "json-file")
-l, --log-level string ログ出力レベルを設定します。("debug", "info", "warn", "error", "fatal")(デフォルトは "info")
--log-opt map コンテナーに対するデフォルトのログドライバーオプション。(デフォルトは map[])
--max-concurrent-downloads int プルごとの最大同時ダウンロード数を設定します。(デフォルト 3)
--max-concurrent-uploads int プッシュごとの最大同時ダウンロード数を設定します。(デフォルト 5)
--metrics-addr string メトリックス API を提供するデフォルトのアドレスとポートを指定します。
--mtu int コンテナーネットワークに MTU を設定します。
--node-generic-resources list ユーザー定義のリソースを通知します。
--no-new-privileges 新たなコンテナーに対してデフォルトで no-new-privileges を設定します。
--oom-score-adjust int デーモンに対して oom_score_adj を設定します。(デフォルトは -500)
-p, --pidfile string デーモン PID ファイルへのパス。(デフォルトは "/var/run/docker.pid")
--raw-logs ANSI カラーなしのフルタイムスタンプ。
--registry-mirror list 指定したい Docker レジストリミラー。(デフォルトは [])
--seccomp-profile string seccomp プロファイルへのパス。
--selinux-enabled selinux サポートを有効にします。
--shutdown-timeout int デフォルトのシャットダウンタイムアウトを設定します。(デフォルトは 15)
-s, --storage-driver string 利用するストレージドライバー。
--storage-opt list ストレージドライバーのオプション。(デフォルトは [])
--swarm-default-advertise-addr string Swarm の通知アドレスに対してデフォルトのアドレスまたはインターフェースを設定します。
--tls TLS の利用。暗に --tlsverify を含みます。
--tlscacert string この CA によってのみ署名された信頼できる証明局。(デフォルトは "~/.docker/ca.pem")
--tlscert string TLS 証明書ファイルへのパス。(デフォルトは "~/.docker/cert.pem")
--tlskey string TLS 鍵ファイルへのパス。(デフォルトは "~/.docker/key.pem")
--tlsverify TLS を利用しリモートを確認します。
--userland-proxy ループバックトラフィックに対してユーザーランドプロキシーを利用します。(デフォルトは true)
--userland-proxy-path string ユーザーランドプロキシーのバイナリへのパス。
--userns-remap string ユーザー名前空間に対するユーザー/グループの設定。
-v, --version バージョン情報を表示して終了します。
Usage: dockerd COMMAND
A self-sufficient runtime for containers.
Options:
--add-runtime runtime Register an additional OCI compatible runtime (default [])
--allow-nondistributable-artifacts list Push nondistributable artifacts to specified registries (default [])
--api-cors-header string Set CORS headers in the Engine API
--authorization-plugin list Authorization plugins to load (default [])
--bip string Specify network bridge IP
-b, --bridge string Attach containers to a network bridge
--cgroup-parent string Set parent cgroup for all containers
--cluster-advertise string Address or interface name to advertise
--cluster-store string URL of the distributed storage backend
--cluster-store-opt map Set cluster store options (default map[])
--config-file string Daemon configuration file (default "/etc/docker/daemon.json")
--containerd string Path to containerd socket
--cpu-rt-period int Limit the CPU real-time period in microseconds
--cpu-rt-runtime int Limit the CPU real-time runtime in microseconds
--data-root string Root directory of persistent Docker state (default "/var/lib/docker")
-D, --debug Enable debug mode
--default-gateway ip Container default gateway IPv4 address
--default-gateway-v6 ip Container default gateway IPv6 address
--default-address-pool Set the default address pool for local node networks
--default-runtime string Default OCI runtime for containers (default "runc")
--default-ulimit ulimit Default ulimits for containers (default [])
--dns list DNS server to use (default [])
--dns-opt list DNS options to use (default [])
--dns-search list DNS search domains to use (default [])
--exec-opt list Runtime execution options (default [])
--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 (default [])
--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 (default [])
--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)
--ipv6 Enable IPv6 networking
--label list Set key=value labels to the daemon (default [])
--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)
--metrics-addr string Set default address and port to serve the metrics api on
--mtu int Set the containers network MTU
--node-generic-resources list Advertise user-defined resource
--no-new-privileges Set no-new-privileges by default for new containers
--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 (default [])
--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 (default [])
--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
-v, --version Print version information and quit
オプションにおいて [] が書かれているものは、複数個の指定が可能です。
内容説明
dockerd
はコンテナー管理を行う常駐プロセスです。
Docker ではデーモンとクライアントのそれぞれに対して異なる実行バイナリを利用します。
デーモンを実行するにはdockerd
を入力します。
デーモン実行においてデバッグ出力を行うには、dockerd -D
を実行します。
あるいはdaemon.json
ファイルに"debug": true
を追加します。
メモ
Docker 1.13 およびそれ以降において試験的機能(experimental features)を有効にするには、
dockerd
に--experimental
フラグをつけて実行するか、daemon.json
ファイルに"experimental": true
を追加します。 それ以前の Docker バージョンにおいて試験的機能を有効にするには、特別にビルドされたものを利用することが必要でした。
利用例
デーモンソケットオプション
Docker デーモンは Docker Engine API リクエストを待ち受けます。
その際には 3 種類のタイプのソケット、つまりunix
、tcp
、fd
が利用されます。
unix
デーモンソケット(あるいは IPC ソケット)は、デフォルトで/var/run/docker.sock
に生成されます。
実行にはroot
権限、またはdocker
グループメンバー権限を必要とします。
Docker デーモンにリモートからアクセスする必要がある場合はtcp
ソケットの有効化が必要です。
デフォルトの設定では暗号化や認証がなく、Docker デーモンに直接アクセスできるようになっているので注意してください。
これは HTTPS 暗号化ソケットを用いた方式 を行うか、あるいはセキュアなウェブプロキシーを介するようにして、安全化を図ることが必要です。
すべてのネットワークインターフェースに対しては、ポート2375
から-H tcp://0.0.0.0:2375
のようにアクセスします。
また特定のネットワークインターフェースに対しては、IP アドレスを使って-H tcp://0.0.0.0:2375
のようにします。
慣例として、デーモンとの通信が暗号化されていない場合にはポート2375
、暗号化されている場合はポート2376
を利用します。
メモ
HTTPS による暗号化されたソケットを利用する場合、サポートされるのが TLS1.0 またはそれ以降であることに注意してください。 セキュリティに関する理由により、プロトコル SSLv3 またはそれ以下はサポートされません。
Systemd に基づいたシステムにおいては、デーモンに対しては Systemd の ソケットアクティベーション(socket activation)を通じてdockerd -H fd://
のようにしてやりとりができます。
fd://
と指定すればどのような環境でもほぼ間違いなく動作しますが、dockerd -H fd://3
のようにして個別のソケットを指定することもできます。
指定したソケットアクティベーションのファイルが見つからなかった場合、Docker は終了します。
Docker と Systemd を使ったソケットアクティベーションの利用例については Docker source tree において見ることができます。
Docker デーモンに対して複数ソケットを同時に待ち受けるようにするには-H
オプションを複数指定します。
# デフォルトのunixソケットを利用、合わせて当ホスト上の指定IPアドレス2つを待ち受ける
$ sudo 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 18.09 以降では 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
バイナリ 18.09 またはそれ以降が必要です。
別ホスト/ポートあるいは Unix ソケットへの Docker のバインド
警告
docker
デーモンはデフォルトで、TCP ポートあるいは Unix のユーザーグループdocker
へバインドされていますが、これを変更すると、非 root ユーザーによってホスト上の root 権限が取得されるというセキュリティリスクが発生します。docker
へのアクセスは適切に制御してください。 1 つの TCP ポートにバインドした場合、そのポートに他者がアクセスすれば Docker のすべてにアクセスできるということです。 したがってオープンなネットワーク上において、これを行うことはお勧めしません。
-H
オプションを使えば Docker デーモンが特定の 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
がデフォルトです。
-H
によるホストとポートの割り当ては、以下の書式に従います。
tcp://[host]:[port][path] または unix://path
たとえば以下のとおりです。
tcp://
は127.0.0.1
への TCP 接続であり、TLS 暗号化が有効な場合は2376
ポート、通信が平文による場合は2375
ポートを利用します。tcp://host:2375
は host:2375 への TCP 接続です。tcp://host:2375/path
は host:2375 への TCP 接続であり、すべてのリクエストに path を追加します。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 &
# ubuntu イメージのダウンロードにあたって、デフォルトの Unix ソケットを利用します。
$ docker pull ubuntu
# あるいは TCP ポートを利用します。
$ docker -H tcp://127.0.0.1:2375 pull ubuntu
デーモンのストレージドライバー
Linux 上の Docker デーモンは、イメージレイヤーに対するストレージドライバーをいくつかサポートしています。
aufs
、devicemapper
、btrfs
、zfs
、overlay
、overlay2
といったものです。
aufs
ドライバーは中でも古いものです。
Linux カーネルのパッチセットの形式になっていますが、Linux のソースにマージされることはまずありません。
なおこのパッチセットは重大なカーネルクラッシュを引き起こす場合があることが知られています。
ただしaufs
を用いると、コンテナーが実行モジュールや共有ライブラリのメモリを共有することができます。
したがって同一プログラムまたは同一ライブラリを利用するコンテナーが何千にも及ぶような状況では、便利なドライバーです。
devicemapper
ドライバーはシンプロビジョニング(thin provisioning)とコピーオンライト(Copy on Write; CoW)スナップショットを利用します。
devicemapper のグラフの場所ごと、通常は/var/lib/docker/devicemapper
において、2 つのブロックデバイスに基づいたシンプールが生成されます。
その 2 つとは、1 つがデータ用、もう 1 つがメタデータ用です。
これらのブロックデバイスはデフォルトでは、自動生成されるスパースファイルへのループバックマウントを利用して自動生成されます。
この設定のカスタマイズ方法については、以下に示す Devicemapper オプション を参照してください。
以下の記事 ~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 オプション に説明しているzfs.fsname
オプションを利用します。
overlay
は非常に高速のユニオンファイルシステムです。
これは Linux カーネルの 3.18.0 からマージされるようになりました。
overlay
はページキャッシュ共有もサポートします。
これはつまり、複数のコンテナーが同一ファイルにアクセスした場合でも、単一のページキャッシュエントリーを共有できることになります。
これによってoverlay
はaufs
ドライバーと同様に、メモリを効率よく活用します。
利用するにはdockerd -s overlay
とします。
メモ
overlay
は優れた機能ですが、まだ開発されたばかりなので、本番環境では利用しないでください。 特にoverlay
を利用した場合に inode の消費が過剰に発生する場合があります(特にイメージ数が増えるほど)。 また RPM 使用との互換性がありません。
overlay2
は同じく高速のユニオンファイルシステムを用いますが、Linux カーネル 4.0 において加えられた 追加機能 を活用します。
利用するにはdockerd -s overlay2
とします。
メモ
overlay
とoverlay2
は、ともに現時点においてbtrfs
に対して、あるいはコピーオンライト(Copy on Write)ファイルシステムにおいてはサポートされていません。 したがってこれらはext4
パーティションに対してのみ用いてください。
Windows において Docker デーモンは、イメージプラットフォームに応じて単一のイメージレイヤー向けストレージドライバーを提供します。
Windows イメージに対してはwindowsfilter
、Windows 上の Linux コンテナーに対してはlcow
です。
各ストレージドライバーのオプション
特定のストレージドライバーに対するオプションは--storage-opt
フラグを使って設定することができます。
devicemapper
用のオプション名はdm
で始まります。
同様にzfs
用はzfs
、btrfs
用はbtrfs
、lcow
用はlcow
でそれぞれ始まります。
devicemapper 用オプション
以下の例は Linux 上における devicemapper 用設定ファイルです。
{
"storage-driver": "devicemapper",
"storage-opts": [
"dm.thinpooldev=/dev/mapper/thin-pool",
"dm.use_deferred_deletion=true",
"dm.use_deferred_removal=true"
]
}
dm.thinpooldev
オプション
シンプール(thin pool)を利用するカスタムブロックストレージデバイスを指定します。
device mapper ストレージに対してブロックデバイスを利用する場合は、シンプールボリュームを生成して管理するためにlvm
を利用するのが最適です。
このボリュームはその後に Docker に受け渡されて、イメージやコンテナーに必要となるスナップショットボリュームを生成するために利用されます。
シンプールの管理を Engine 外部で行なえば、豊富な機能を実現することができます。 つまり Docker コンテナーに対するバックストレージとして、デバイスマッパーのシンプロビジョニングが利用できます。 lvm ベースのシンプール管理機能の主な特徴は以下のものです。 自動的および対話的なシンプールのリサイズ機能のサポート、動的なシンプール変更機能、lvm によるシンプールアクティブ時の自動的シンプールメタデータチェック機能、などです。
シンプールが提供されない状態では、これよりも劣るループバックファイルが生成されます。
ループバックは処理が遅いかわりに、前もってストレージ設定を行わずに利用することができます。
このループバックは本番環境において利用することはお勧めできません。
したがって Engine デーモンに、引数--storage-opt dm.thinpooldev
が設定されていることを十分に確認してください。
利用例
$ sudo dockerd --storage-opt dm.thinpooldev=/dev/mapper/thin-pool
dm.directlvm_device
オプション
上に示したシンプールを利用するものとは別の方法として、ブロックデバイスを設定することができます。
利用例
$ 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
が、利用容量を自動拡張するにあたってのシンプール増量率を設定します。
(100 は無効を意味します。)
利用例
$ sudo dockerd --storage-opt dm.thinp_autoextend_percent=20
dm.basesize
オプション
ベースデバイスの生成に用いるサイズを指定します。 これはイメージやコンテナーのサイズを制限するものです。 デフォルト値は 10 G です。 なおシンデバイスは基本的に「スパース」(sparse)であるため、デバイス上の 10 G はほとんどが空となり、プール上において 10 G を占有するものではありません。 ただしデバイスが大きくなればなるほど、ファイルシステムが扱う空データはより多くなります。
ベースデバイスのサイズは、デーモンの再起動によって増えます。 これを行えば、今後生成されるイメージやコンテナー(その新たなイメージに基づくもの)は、新たなベースデバイスサイズに基づいて生成されます。
利用例
$ sudo dockerd --storage-opt dm.basesize=50G
上のコマンドはベースデバイスサイズを 50 G に増やすものです。 ベースデバイスサイズが元から 50 G よりも大きかった場合には、Docker デーモンはエラーを出力します。 このオプションによってベースデバイスサイズを拡張することができますが、逆に縮小はできません。
この設定はシステム全体にわたって、「ベース」となっている空のファイルシステムに影響を与えます。 そこにはすでに初期化を済ませたものもあり、プルイメージから継承されたものも含みます。 通常この値を変更する場合には、以下のような手順を経て変更を適用します。
$ sudo service docker stop
$ sudo rm -rf /var/lib/docker
$ sudo service docker start
dm.loopdatasize
オプション
メモ
本オプションは devicemapper のループバックを設定するものです。 これを本番環境では利用しないでください。
ループバックファイルを「データ」デバイスとして生成する際に用いられるサイズを指定します。 「データ」デバイスはシンプールのために利用されます。 デフォルトサイズは 100G です。 ファイルはスパースであるため、それだけの容量を初めから占有するわけではありません。
利用例
$ sudo dockerd --storage-opt dm.loopdatasize=200G
dm.loopmetadatasize
オプション
メモ
本オプションは devicemapper のループバックを設定するものです。 これを本番環境では利用しないでください。
シンプール用に用いられる「メタデータ」デバイスに対して、ループバックファイルが生成される際の利用サイズを指定します。 デフォルトサイズは 2G です。 ファイルはスパースであるため、それだけの容量を初めから占有するわけではありません。
利用例
$ sudo dockerd --storage-opt dm.loopmetadatasize=4G
dm.fs
オプション
ベースデバイスに対して利用するファイルシステムタイプを指定します。 サポートされるオプションは「ext4」と「xfs」です。 デフォルトは「xfs」です。
利用例
$ sudo dockerd --storage-opt dm.fs=ext4
dm.mkfsarg
オプション
ベースデバイス生成時に用いられる追加の mkfs 引数を指定します。
利用例
$ sudo dockerd --storage-opt "dm.mkfsarg=-O ^has_journal"
dm.mountopt
シンデバイスマウント時に用いられる追加のマウントオプションを指定します。
利用例
$ sudo dockerd --storage-opt dm.mountopt=nodiscard
dm.datadev
(廃止予定であるため、dm.thinpooldev
を利用してください。)
シンプール用のデータとして利用するカスタムブロックデバイスを指定します。
device mapper ストレージにブロックデバイスを利用する場合は、原則としてdatadev
とmetadatadev
を指定することによって、完全にループバックデバイスが利用されないようにしてください。
利用例
$ sudo dockerd \
--storage-opt dm.datadev=/dev/sdb1 \
--storage-opt dm.metadatadev=/dev/sdc1
dm.metadatadev
(廃止予定であるため、dm.thinpooldev
を利用してください。)
シンプールとして、メタデータに利用されるカスタムなブロックデバイスを指定します。
性能を最大限確保するために、メタデータを通常データとは異なるディスクに配置してください。 SSD 上に置くのが、より適切です。
新たにメタデータプールを設定する際には、それが適正であることが必要になります。 これは空のメタデータであることを示すために、先頭の 4K をゼロで埋めることで実現できます。
$ dd if=/dev/zero of=$metadata_dev bs=4096 count=1
利用例
$ sudo dockerd \
--storage-opt dm.datadev=/dev/sdb1 \
--storage-opt dm.metadatadev=/dev/sdc1
dm.blocksize
オプション
シンプールで利用するカスタムブロックサイズを指定します。 デフォルトのブロックサイズは 64K です。
利用例
$ sudo dockerd --storage-opt dm.blocksize=512K
dm.blkdiscard
オプション
devicemapper デバイスの削除時に、blkdiscard
の利用を許可するかしないかを指定します。
これはループバックデバイス利用時(のみ)、デフォルトは有効です。
ループバックファイルの場合は、イメージやコンテナーの削除時に再度スパースとする必要があるからです。
ループバックに対してこれを無効にした場合は、コンテナーの削除時間が 大きく 削減できます。
ただしコンテナーが削除されても、/var/lib/docker
ディレクトリに割り当てられていた領域は、他プロセスが利用できる状態に戻されることはありません。
利用例
$ sudo dockerd --storage-opt dm.blkdiscard=false
dm.override_udev_sync_check
オプション
devicemapper
とudev
の間におけるudev
同期確認(synchronization checks)をオーバーライドします。
udev
は Linux カーネルにおける device manager です。
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 に設定してください。
$ sudo dockerd --storage-opt dm.override_udev_sync_check=true
この設定値がtrue
である場合、devicemapper
はエラーが発生したことを単に警告するだけで処理を継続します。
メモ
理想的には、
udev
との同期をサポートするdocker
デーモンおよび環境を目指すべきところです。 これに関してのさらなるトピックが docker#4036 に示されています。 これができない限りは、既存の Docker デーモンが動作する環境上において、正常動作するように本フラグを設定してください。
dm.use_deferred_removal
オプション
libdm
とカーネルドライバーが遅延デバイス無効化(deferred device removal)の機能をサポートしていれば、その機能を有効にします。
遅延デバイス無効化とは、デバイスの無効化による削除が行われる際にそのデバイスがビジーであると、そのデバイスに対して遅延無効化がスケジュールされるものです。 その後にデバイスの最終ユーザーの利用が終了すると、自動的にデバイスが無効化されます。
たとえばコンテナーが処理終了すると、関連するシンデバイスは無効化されます。 このデバイスが別のマウント名前空間に割り振られていると、無効化することができません。 それでもコンテナーは正常終了します。 そして本オプションによって、システムがこのデバイスを遅延無効化の対象としてスケジュールします。 デバイスがビジーであるからといって、処理ループに入って無効化完了を待つようなことはありません。
利用例
$ sudo dockerd --storage-opt dm.use_deferred_removal=true
dm.use_deferred_deletion
オプション
シンプールデバイスに対して、遅延デバイス削除(deferred device 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
この 2 つのオプションが有効になっていると、ドライバーがコンテナー削除を行う際にデバイスがビジーであっても、ドライバーはそのデバイスを削除対象として印をつけておき、後にそのデバイスが使われなくなったら削除します。
一般的にこのオプションは、デフォルトで有効にしておいても安全です。 意図せずにマウントポイントが複数のマウント名前空間にわたって広がってしまうことが避けられます。
dm.min_free_space
オプション
新たなデバイスを新規に生成するために必要となる、シンプール内の空き領域の最小率を指定します。 これは、データとメタデータの両方の空き領域を確認します。 有効な値は 0% から 99% です。 0% を指定すると、空き領域の確認処理を無効にします。 ユーザーによってこのオプションが指定されなかった場合、Engine はデフォルト値 10% を用います。
新たなシンプールデバイスが生成される際(docker pull
の処理中、あるいはコンテナー生成中)には、必ず Engine が最低どれだけの空き領域が利用可能かを確認します。
十分な空き領域がなかった場合、デバイス生成処理は失敗して、これに関連したdocker
処理もすべて失敗します。
上のエラーを解消するためには、シンプール内により多くの空き領域を生成しておくことが必要です。 イメージやコンテナーをいくつかシンプールから削除すれば、空き領域は確保されます。 あるいはシンプールに対して、より多くのストレージを割り当てる方法もあります。
LVM(logical volume management)上のシンプールに容量追加を行うなら、シンプールがあるボリュームグループに対してストレージ追加を行ないます。 そうするだけでエラーは自動解消されます。 ループデバイスを利用するように設定している場合は、いったん Engine デーモンを停止させて、ループファイルのサイズを増やした上でデーモンを再起動すれば、エラーは解消します。
利用例
$ sudo dockerd --storage-opt dm.min_free_space=10%
dm.xfs_nospace_max_retries
オプション
対応しているストレージドライバーから ENOSPC(スペースなし)エラーが返された際に、XFS が I/O 完了を繰り返す最大回数を指定します。
デフォルトで XFS は I/O が完了するまで無限に試行し続けます。 そうなってしまうと kill できないプロセスとなってしまいます。 この動作を変更するには、たとえば xfs_nospace_max_retries に 0 を指定します。 そうすると XFS は ENOSPC を受け取った後は試行を行わず、ファイルシステムをシャットダウンします。
利用例
$ sudo dockerd --storage-opt dm.xfs_nospace_max_retries=0
dm.libdm_log_level
オプション
libdm
の最大ログレベルを指定します。
これはdockerd
ログ(--log-level
で指定される)に受け渡されます。
このオプションが主に用いられるのは、libdm
に関係した問題をデバッグする場合です。
この設定をデフォルト値以外にすると、誤って警告ログが検出される場合があります。
指定する値は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 用オプション
zfs.fsname
オプション
Docker が独自のデータセットを生成する場所となる zfs ファイルシステムを指定します。
Docker はデフォルトでは、Docker グラフ(/var/lib/docker
)が置かれている zfs ファイルシステムを利用します。
利用例
$ sudo dockerd -s zfs --storage-opt zfs.fsname=zroot/docker
Btrfs 用オプション
btrfs.min_space
オプション
コンテナーが利用するサブボリュームを生成するにあたっての最小サイズを指定します。 btrfs 上においてユーザーにディスククォータが利用されている場合に、コンテナーの生成および起動に --storage-opt size オプションを利用すると、Docker はその size が btrfs.min_space よりも小さくならないようにします。
利用例
$ sudo dockerd -s btrfs --storage-opt btrfs.min_space=10G
Overlay2 用オプション
overlay2.override_kernel_check
オプション
Linux カーネル版の overlay2 チェック機能をオーバーライドします。 overlay2 では複数の下位ディレクトリを必要としますが、この指定をサポートする機能が Linux カーネル 4.0.0 には加えられています。 ただしカーネルバージョンが古い場合に OverlayFS に対して、複数の下位ディレクトリサポートを追加するためのパッチが適用されている場合があります。 本オプションは、カーネル内にそのサポート機能が存在していることを確認した上でのみ、その機能を利用するようにします。 このサポート機能を持っていないカーネルに対して本オプションを指定すると、マウント処理時にエラーとなります。
overlay2.size
オプション
コンテナーのデフォルト最大サイズを設定します。
これはファイルシステムがxfs
であって、pquota
マウントオプションを使ってマウントされている場合にのみサポートされます。
この条件下であれば、ファイルシステムサイズの範囲内でどのようなサイズでも指定が可能です。
利用例
$ sudo dockerd -s overlay2 --storage-opt overlay2.size=1G
Windowsfilter 用オプション
size
オプション
コンテナーが利用するサンドボックスを生成するために用いるサイズを指定します。 デフォルトは 20G です。
利用例
C:\> dockerd --storage-opt size=40G
LCOW(Linux Containers on Windows)用オプション
lcow.globalmode
オプション
デーモンが必要に応じてユーティリティー VM インスタンスを初期化するかどうか(これが推奨され、省略時のデフォルトです)、あるいは単一のグローバルユーティリティー VM を利用するか(パフォーマンスは向上しますが、セキュリティに影響があるため、本番環境へのデプロイには推奨されません)、このいずれかを指定します。
利用例
C:\> dockerd --storage-opt lcow.globalmode=false
lcow.kirdpath
オプション
ユーティリティー VM をブートするために利用される 2 つのファイル、つまりカーネルと initrd ファイルが置かれているフォルダーパスを指定します。
デフォルトは%ProgramFiles%\Linux Containers
です。
利用例
C:\> dockerd --storage-opt lcow.kirdpath=c:\path\to\files
lcow.kernel
オプション
lcow.kirdpath
で指定したパス内にあるカーネルファイル名を指定します。
デフォルトはbootx64.efi
です。
利用例
C:\> dockerd --storage-opt lcow.kernel=kernel.efi
lcow.initrd
オプション
lcow.kirdpath
で指定したパス内にある initrd ファイル名を指定します。
デフォルトはinitrd.img
です。
利用例
C:\> dockerd --storage-opt lcow.initrd=myinitrd.img
lcow.bootparameters
カーネル/initrd モードであるときに、ユーティリティー VM をブートするにあたっての追加のブートパラメーターを指定します。 ユーティリティー VM が VHD からブートされる場合には無視されます。 この設定はカーネル固有のものです。
利用例
C:\> dockerd --storage-opt "lcow.bootparameters='option=value'"
lcow.vhdx
ユーティリティー VM をブートするために カーネルおよび initrd ではなく、カスタム 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 カーネルのnamespaces
、cgroups
、SELinux
へのインターフェースとして動作します。
デフォルトで Docker デーモンは自動的にcontainerd
を起動します。
containerd
の起動を制御したい場合は、containerd
を手動で起動するようにし、--containerd
フラグへはcontainerd
ソケットへのパスを指定します。
$ sudo dockerd --containerd /var/run/dev/docker-containerd.sock
ランタイムはデーモンに登録することができます。
これは設定ファイルか、あるいはコマンドライン引数--add-runtime
を使って行います。
以下に示すのは、設定ファイルを使って 2 つのランタイムを追加する例です。
{
"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
がつきます。
利用可能なオプションは、ただ 1 つnative.cgroupdriver
オプションです。
native.cgroupdriver
オプションは、コンテナーの cgroup に対する管理方法を指定します。
指定できるのはcgroupfs
またはsystemd
のいずれかです。
systemd
を指定してもそれが利用できなかった場合は、システムエラーとなります。
native.cgroupdriver
オプションを省略するとcgroupfs
が利用されます。
以下の例はcgroupdriver
にsystemd
を設定するものです。
$ sudo dockerd --exec-opt native.cgroupdriver=systemd
このオプションを設定すると、デーモンが起動するコンテナーすべてに適用されます。
また Windows コンテナーにおいては、この--exec-opt
を特別な目的で利用します。
Docker ユーザーがこれを使って、デフォルトのコンテナー分離技術(isolation technology)を指定できます。
> dockerd --exec-opt isolation=hyperv
上のコマンドは、Windows 上においてデフォルトの分離技術をhyperv
とします。
デーモン起動時に分離技術の指定が行われなかった場合、Windows クライアントではデフォルトをhyperv
とします。
また Windows Server ではデフォルトはprocess
となります。
デーモンの DNS オプション
Docker コンテナーすべてに対して DNS サーバーを設定するには、以下のようにします。
$ sudo dockerd --dns 8.8.8.8
Docker コンテナーすべてに対して DNS 検索ドメインを設定するには、以下のようにします。
$ sudo dockerd --dns-search example.com
配布制限のある成果物のプッシュ
イメージの中には(たとえば Windows ベースイメージのように)ライセンスによって配布が制限されているものがあります。 そのようなイメージをレジストリにプッシュした場合、制限された製品をレジストリに含めることはできません。
指定するレジストリに対して上記の動作をオーバーライドするには--allow-nondistributable-artifacts
オプションを用います。
その際の書式は以下のいずれかです。
--allow-nondistributable-artifacts myregistry:5000
と指定すると、Docker デーモンに対して配布制限のある成果物(nondistributable artifacts)を myregistry:5000 へプッシュする指示となります。--allow-nondistributable-artifacts 10.1.0.0/16
と指定すると、Docker デーモンに対して配布制限のある成果物を、IP アドレスが CIDR 記述に表現されたサブネットに含まれるレジストリにプッシュする指示となります。
このオプションは複数個指定することができます。
このオプションが活用できるのは、エアギャップなネットワーク上のレジストリに、配布制限された成果物を含むイメージをプッシュするような場合です。 そのネットワーク上のホストからは、別のサーバーに接続することなくイメージをプルすることができます。
警告
配布制限のある成果物は、これを配布し共有する方法や場所に関しての制約があります。 本機能を利用して成果物をプッシュするのはプライベートリポジトリに行うものとしてください。 また配布制限のある成果物の再配布に関しては、必ずその条件に準拠してください。
セキュアでないレジストリ
Docker におけるプライベートリポジトリは、セキュアとセキュアでないもののいずれも扱われます。
この節に示す レジストリ とは プライベートリポジトリ のことであるとします。
そしてプライベートリポジトリの例としてmyregistry:5000
を用いることにします。
セキュアなレジストリでは TLS が用いられます。
そして CA 証明書のコピーが Docker ホスト上の/etc/docker/certs.d/myregistry:5000/ca.crt
に置かれます。
一方セキュアでないレジストリとは、TLS を利用していないもの(つまり HTTP を平文でやりとりするもの)か、あるいは TLS を利用してはいるものの、デーモンがその CA 証明書を識別できない状態にあるものを指します。
後者の例は、/etc/docker/certs.d/myregistry:5000/
の配下に証明書が見つからなかった場合や、証明書の照合に失敗した(証明書が誤っているなどの)場合に発生します。
デフォルトで Docker はローカルのレジストリであれば、それはすべてセキュアであるとみなします(ローカルレジストリについては後述を参照してください)。
Docker がセキュアでないレジストリをセキュアであるとみなしてしまうと、そのときにはそのレジストリとの通信が不能となります。
セキュアでないレジストリとの通信を行うためには、Docker デーモンに--insecure-registry
の指定が必要です。
その場合、以下の 2 つの書式のいずれかを用います。
--insecure-registry myregistry:5000
と指定すると、Docker デーモンに対して myregistry:5000 がセキュアでないことを指示します。--insecure-registry 10.1.0.0/16
と指定すると、Docker デーモンに対して、レジストリのドメインの IP アドレスが CIDR 記述に表現されたサブネットに含まれるようなレジストリについて、そのすべてがセキュアでないことを指示します。
このフラグは複数個指定することが可能であり、複数のレジストリをセキュアでないものとして指定できます。
セキュアでないレジストリをセキュアでないと指定しておかないと、docker pull
、docker push
、docker search
がエラーになります。
その際にはセキュアなレジストリとするか、あるいは上で示したように Docker デーモンに対して--insecure-registry
フラグを指定するようにします。
Docker 1.3.2 以降において、ローカルレジストリの IP アドレスが 127.0.0.0/8 の範囲にある場合、このレジストリはセキュアではないと扱われます。 ただしこれに期待するのは適切ではありません。 将来的にこの扱いは変更されるかもしれないからです。
--insecure-registry
を有効にするということは、つまり暗号化されていない通信、あるいは信頼できない通信を可能にするということです。
これはローカルレジストリを運用している場合には便利です。
ただしこれを利用するとセキュリティぜい弱性を生み出してしまうため、これを有効にするのはテスト目的のみとしてください。
セキュリティを向上させるためには、--insecure-registry
を有効とするのではなく、システムの信頼できる CA リストに CA を加えるようにしてください。
古いレジストリ
古い v1 プロトコルのみに対応するレジストリへの操作は、Docker 17.12 からはサポートされません。
特にデーモンは v1 レジストリに対してのpush
、pull
、login
を行ないません。
ただしsearch
だけは例外であり、v1 レジストリに対してもこの操作は利用できます。
設定オプションdisable-legacy-registry
は削除されました。
したがってこれを利用した場合、デーモンの起動時にエラーが発生します。
HTTPS_PROXY のもとでの Docker デーモン実行
HTTPS
プロキシーを用いる LAN 内においてデーモンを起動している場合、Docker Hub の証明書はプロキシーの証明書に置き換えられます。
したがってその証明書を Docker ホストの設定に追加しておくことが必要になります。
- 利用するディストリビューションの
ca-certificates
パッケージをインストールします。 - ネットワーク管理者からプロキシーの CA 証明書の情報を得て、これを
/etc/pki/tls/certs/ca-bundle.crt
に追加します。 - そして Docker を
HTTPS_PROXY=http://username:password@proxy:port/ dockerd
として実行します。username:
とpassword@
は任意です。 これはプロキシー認証を行う設定になっている場合にのみ必要となります。
これは Docker デーモンのリクエストに対して、プロキシーと認証の情報を追加するだけです。
一方docker build
コマンドや実行中コンテナーにとっては、プロキシーを利用するための情報がさらに必要となります。
デフォルトのulimit
設定
--default-ulimit
は、すべてのコンテナーが利用するデフォルトのulimit
オプションを指定するものです。
docker run
には同じオプションとして--ulimit
があります。
これらに対してデフォルトが設定されていなかった場合は、ulimit
の設定が受け継がれます。
docker run
において設定されていなければ Docker デーモンから引き継ぎます。
docker run
において指定された--ulimit
オプションは、すべてそのデフォルト値をオーバーライドします。
ulimit
フラグを使ってnproc
を設定する場合には注意が必要です。
nproc
は利用可能なプロセスの最大数を設定するものとして Linux 上において設計されていますが、利用可能であるのはユーザーであってコンテナーではないからです。
詳しくは run リファレンスを参照してください。
ノード検出
--cluster-advertise
オプションはhost:port
またはinterface:port
という組み合わせにより指定されます。
これは特定のデーモンインスタンスが、自分自身をクラスターに通知(advertise)する際に用います。
リモートホストはこの値を通じてデーモンに到達します。
インターフェースを指定する場合は、実際の Docker ホストの IP アドレスを含めてください。
docker-machine
を通じて設定された Engine では、通常このインターフェースはeth1
となります。
デーモンにおいては、クラスター内部のノードを通知するために libkv が用いられています。
キーバリューを保持するバックエンドにおいては、相互 TLS(mutual TLS)をサポートするものがあります。
デーモンにおいて用いられるクライアント側の TLS 設定を変更するには--cluster-store-opt
フラグを用います。
そしてそこでは PEM エンコードファイルへのパスを指定します。
$ sudo 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
現時点においてサポートされているクラスターストアのオプションは以下です。
オプション | 内容説明 |
---|---|
discovery.heartbeat |
ハートビートタイマーを秒単位で指定します。これはデーモンがkeepalive メカニズムにおいて用いるものであり、ノード検出モジュールによりクラスター内のノードが生きているかどうかの確認に利用されます。設定されていない場合、デフォルト値は 20 秒です。 |
discovery.ttl |
TTL(time-to-live)を秒単位で指定します。これはノード検出モジュールが用いるものであり、設定されている ttl 値の範囲内で正常なハートビートが受信できなかった場合、どのノードをタイムアウトします。設定されていない場合、デフォルト値は 60 秒です。 |
kv.cacertfile |
PEM エンコードされた CA 証明書を使ったローカルファイルへのパスを指定します。 |
kv.certfile |
PEM エンコードされた証明書を使ったローカルファイルへのパスを指定します。この証明書は、クライアント証明書として、キーバリューストアを使った通信に利用されます。 |
kv.keyfile |
PEM エンコードされた秘密鍵を使ったローカルファイルへのパスを指定します。この秘密鍵は、クライアント鍵として、キーバリューストアを使った通信に利用されます。 |
kv.path |
キーバリューストア内のパスを指定します。設定されていない場合のデフォルト値は’docker/nodes’です。 |
アクセス認証
Docker のアクセス認証は、認証プラグインによって拡張することができます。
この認証プラグインは、所属組織が購入して利用する場合や独自にビルドする場合があります。
Docker のdaemon
起動時には複数の認証プラグインを設定することが可能であり、その際には--authorization-plugin=PLUGIN_ID
オプションを用います。
$ sudo dockerd --authorization-plugin=plugin1 --authorization-plugin=plugin2,...
PLUGIN_ID
値にはプラグイン名か、あるいはその仕様ファイルへのパスを指定します。
プラグイン名またはパスを指定できるかどうかは、そのプラグインの実装によって定まります。
プラグインが利用可能かどうかの情報は、Docker 管理者に問い合わせてください。
プラグインを設定しておけば、コマンドラインあるいは Docker Engine API からのリクエストによって、そのプラグイン利用を許可するかしないかを指示できます。 複数のプラグインを設定している場合、指定された順で個々のプラグインは、リクエストの完了を許可する必要があります。
認証プラグインの生成方法については、Docker の拡張機能を説明する項の 認証プラグイン の節を参照してください。
デーモンのユーザー名前空間オプション
Linux カーネルの ユーザー名前空間サポート は、1 つのプロセスを有効にして追加のセキュリティ機能を提供します。
したがってコンテナーでは独自のユーザーおよびグループの ID 範囲を持つものであり、ホストシステムにおいて利用される従来のユーザーおよびグループとは切り離されます。
最も重要なセキュリティ向上となるのは、デフォルトでroot
ユーザーとして実行されるコンテナープロセスが、コンテナー内部において期待どおりに管理権限で動作する(一部に制約もある)という点です。
しかもこれはホストから見れば、実際には非特権ユーザーのuid
にマップされるということです。
この機能の利用方法および制約については ユーザー名前空間によるコンテナーの分離 を参照してください。
その他のオプション
IP マスカレードを利用するとアドレス変換が可能となり、公開 IP アドレスを持たないコンテナーであっても、インターネット上の別マシンとやりとりができるようになります。
これは一部のネットワークトポロジーと干渉する場合があるため、--ip-masq=false
によって無効化できます。
Docker データディレクトリ(/var/lib/docker
)と一時ディレクトリ/var/lib/docker/tmp
に対して Docker はソフトリンクをサポートしています。
たとえばDOCKER_TMPDIR
とデータディレクトリは、以下のようにして設定することができます。
DOCKER_TMPDIR=/mnt/disk2/tmp /usr/local/bin/dockerd -D -g /var/lib/docker -H unix:// > /var/lib/docker-machine/docker.log 2>&1
# or
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 はスライス(slice)による階層構造により表現され、そのスライス名はツリー内の場所をエンコードしています。
したがって 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
オプションには tcp アドレスを指定し、これによりメトリックス API を提供します。
この機能は今も試験的なものであり、したがって本機能利用のためにはデーモンを試験的モード(experimental mode)で実行する必要があります。
localhost:9323
によってメトリックス API を提供する場合は、--metrics-addr 127.0.0.1:9323
と指定します。
こうしておくことで127.0.0.1:9323/metrics
という API リクエストを行って、prometheus 書式のメトリックスを受信することができます。
ポート9323
は Docker メトリックスに関連づいたデフォルトポート であり、他の prometheus エクスポーターやサービスとの衝突を回避するものです。
prometheus サーバーを実行している場合は、このアドレスを scrape 設定に追加することで、Docker 上において prometheus によるメトリックス収集を行うことができます。 prometheus の詳細は こちら のウェブサイトを参照してください。
scrape_configs:
- job_name: 'docker'
static_configs:
- targets: ['127.0.0.1:9323']
この機能はメトリックスと同様に試験的と位置づけられている点に注意してください。 またメトリックス名は、試験的機能の扱いの中で変更されるかもしれません。 API を用いてどのような情報を集めたいか、ぜひフィードバックをお寄せください。
ノードジェネリックリソース
--node-generic-resources
オプションはキーバリューペア(key=value
)をとり、Swarm クラスター内にユーザー定義リソースを通知(advertise)します。
現時点において想定される利用例は NVIDIA GPU を通知するものです。
サービスがNVIDIA-GPU=[0-16]
を要求すると、タスク実行に必要となる十分な GPU を持ったノードに割り振られます。
Example of usage:
{
"node-generic-resources": ["NVIDIA-GPU=UUID1", "NVIDIA-GPU=UUID2"]
}
デーモン設定ファイル
--config-file
オプションを使うと、デーモンに対するどの設定オプションでも JSON 形式のファイルから与えられます。
このファイル内では、フラグ名をそのままキーとして指定します。
ただし複数項目の指定が可能なフラグの場合は、フラグ名を複数形とします。
たとえばlabel
フラグはlabels
とします。
設定ファイルから設定するオプションは、フラグを通じて設定するオプションと競合してはなりません。
設定ファイルとフラグとの間で重複するオプションがあった場合には、その設定値には関係なく Docker デーモンは起動に失敗します。
このようにしているのは、設定ファイルによって再設定が行われ、その変更が何も表示されずに無視されるような状況を防ぐためです。
たとえば設定ファイル内にデーモンの labels を設定し、かつ--label
フラグを使ってデーモンラベルを指定した場合には、デーモンは起動に失敗します。
設定ファイル内に指定されなかったオプションは、デーモン起動時に無視されます。
Linux の場合
設定ファイルのデフォルトは Linux の場合/etc/docker/daemon.json
です。
--config-file
フラグを利用すれば、デフォルト以外の場所を指定することができます。
以下は Linux 上での設定ファイルに記述可能なオプションの一覧です。
{
"authorization-plugins": [],
"data-root": "",
"dns": [],
"dns-opts": [],
"dns-search": [],
"exec-opts": [],
"exec-root": "",
"experimental": false,
"features": {},
"storage-driver": "",
"storage-opts": [],
"labels": [],
"live-restore": true,
"log-driver": "json-file",
"log-opts": {
"max-size": "10m",
"max-file":"5",
"labels": "somelabel",
"env": "os,customer"
},
"mtu": 0,
"pidfile": "",
"cluster-store": "",
"cluster-store-opts": {},
"cluster-advertise": "",
"max-concurrent-downloads": 3,
"max-concurrent-uploads": 5,
"default-shm-size": "64M",
"shutdown-timeout": 15,
"debug": true,
"hosts": [],
"log-level": "",
"tls": true,
"tlsverify": true,
"tlscacert": "",
"tlscert": "",
"tlskey": "",
"swarm-default-advertise-addr": "",
"api-cors-header": "",
"selinux-enabled": false,
"userns-remap": "",
"group": "",
"cgroup-parent": "",
"default-ulimits": {
"nofile": {
"Name": "nofile",
"Hard": 64000,
"Soft": 64000
}
},
"init": false,
"init-path": "/usr/libexec/docker-init",
"ipv6": false,
"iptables": false,
"ip-forward": false,
"ip-masq": false,
"userland-proxy": false,
"userland-proxy-path": "/usr/libexec/docker-proxy",
"ip": "0.0.0.0",
"bridge": "",
"bip": "",
"fixed-cidr": "",
"fixed-cidr-v6": "",
"default-gateway": "",
"default-gateway-v6": "",
"icc": false,
"raw-logs": false,
"allow-nondistributable-artifacts": [],
"registry-mirrors": [],
"seccomp-profile": "",
"insecure-registries": [],
"no-new-privileges": false,
"default-runtime": "runc",
"oom-score-adjust": -500,
"node-generic-resources": ["NVIDIA-GPU=UUID1", "NVIDIA-GPU=UUID2"],
"runtimes": {
"cc-runtime": {
"path": "/usr/bin/cc-runtime"
},
"custom": {
"path": "/usr/local/bin/my-runc-replacement",
"runtimeArgs": [
"--debug"
]
}
},
"default-address-pools":[
{"base":"172.80.0.0/16","size":24},
{"base":"172.90.0.0/16","size":24}
]
}
メモ
デーモン起動時のフラグとしてすでに設定しているオプションは、
daemon.json
に設定することはできません。systemd
を利用して Docker デーモンを起動しているシステムの場合-H
が設定されているため、daemon.json
内において、待ち受けるアドレスを追加するhosts
キーを利用することはできません。 systemd のドロップインファイルを使ってこのタスクを実行する方法については Docker デーモンオプションのカスタマイズ を参照してください。
Windows の場合
設定ファイルのデフォルトは Windows の場合%programdata%\docker\config\daemon.json
です。
--config-file
フラグを利用すれば、デフォルト以外の場所を指定することができます。
以下は Windows 上での設定ファイルに記述可能なオプションの一覧です。
{
"authorization-plugins": [],
"data-root": "",
"dns": [],
"dns-opts": [],
"dns-search": [],
"exec-opts": [],
"experimental": false,
"features":{},
"storage-driver": "",
"storage-opts": [],
"labels": [],
"log-driver": "",
"mtu": 0,
"pidfile": "",
"cluster-store": "",
"cluster-advertise": "",
"max-concurrent-downloads": 3,
"max-concurrent-uploads": 5,
"shutdown-timeout": 15,
"debug": true,
"hosts": [],
"log-level": "",
"tlsverify": true,
"tlscacert": "",
"tlscert": "",
"tlskey": "",
"swarm-default-advertise-addr": "",
"group": "",
"default-ulimits": {},
"bridge": "",
"fixed-cidr": "",
"raw-logs": false,
"allow-nondistributable-artifacts": [],
"registry-mirrors": [],
"insecure-registries": []
}
feature オプション
daemon.json
内の任意設定項目であるfeatures
は、デーモンの特定機能の有効無効を指定します。
たとえば{"features":{"buildkit": true}}
は、デフォルトの Docker イメージビルダーとしてbuildkit
を有効にします。
現時点においてサポートされている feature オプションは以下のとおりです。
buildkit
= デフォルトのビルダーとしてbuildkit
を有効にするにはtrue
を設定し、無効にするにはfalse
を設定します。 なおこのオプションがデーモンの設定ファイルに明示されなかった場合は、クライアント上の CLI からどのビルダーを実行するかによって決定します。
設定再読み込みに関する動作
オプションの中には、デーモンが起動中であってもプロセス再起動をすることなく設定変更を行えるものがあります。
設定再読み込みのため、Linux ではSIGHUP
シグナル、Windows ではグローバルイベントのキーGlobal\docker-daemon-config-$PID
を使います。
このオプションは設定ファイルを使って変更することもできます。
その場合はフラグ指定されたものと競合していないかがチェックされます。
競合していた場合、デーモンの再設定そのものは失敗しますが、実行停止することはありません。
再設定が可能なものとして、現時点でサポートされるオプションは以下のとおりです。
debug
: true に設定するとデーモンをデバッグモードに変更します。cluster-store
: 新たなアドレスを利用してディスカバリーストア(discovery store)を再読み込みします。cluster-store-opts
: ディスカバリーストアの再読み込みに利用する新たなオプションを指定します。cluster-advertise
: 再読み込み後に通知されるアドレスを変更します。labels
: デーモンラベルを別の新たなラベルに置き換えます。live-restore
: デーモン停止時のコンテナー継続起動 を有効にします。max-concurrent-downloads
: プルごとの最大同時ダウンロード数を変更します。max-concurrent-uploads
: プッシュごとの最大同時ダウンロード数を変更します。default-runtime
: コンテナー生成時に指定のなかったランタイムを変更します。デフォルトは「default」であり、これは公式の Docker パッケージが提供するランタイムです。runtimes
: コンテナー実行に用いられる利用可能な OCI ランタイムの一覧を変更します。authorization-plugin
: 利用する認証プラグインを指定します。allow-nondistributable-artifacts
: 配布制限のある成果物をデーモンがプッシュするレジストリの一覧を変更します。insecure-registries
: デーモンのセキュアではいレジストリ一覧を新たなものに変更します。デーモン設定に存在していたセキュアでないレジストリが、新たにロードされたレジストリ内になかった場合、そのレジストリはデーモン設定から削除されます。registry-mirrors
: デーモンのレジストリミラーを新たなものに変更します。デーモン設定に存在していたレジストリミラーが、新たにロードされたレジストリミラー内になかった場合、そのレジストリミラーはデーモン設定から削除されます。shutdown-timeout
: コンテナーすべてをシャットダウンする際のタイムアウトに関して、デーモンの設定を変更します。features
: 特定の機能を明示的に有効または無効にします。
クラスター関連の設定、つまり--cluster-store
、--cluster-advertise
、--cluster-store-opts
を変更および再読み込みしても、それが有効になるのは、その設定がそれまで設定されていなかった場合に限ります。
--cluster-store
をフラグとして指定しcluster-advertise
はフラグとして指定しなかった場合、cluster-advertise
の設定は--cluster-store
がなくても設定ファイルに含めることができます。
設定の再読み込みを行った際に、それまでのクラスター設定に変更があった場合には、警告メッセージがログ出力されます。
複数デーモンの実行
メモ
単一ホスト上に複数デーモンを実行することは「試験的」機能という扱いです。 ここには未解決の問題がある点に注意してください。 この機能は正しく動作しないことがあります。 これは現在も開発途上のものであり、近いうちに正式提供される予定です。
この節では、単一ホスト上において複数の Docker デーモンを起動する方法を示します。 複数デーモンの起動にあたっては、同一ホスト上においてデーモン同士が互いに衝突することがないように設定しなければなりません。 オプション設定はフラグとして行う場合と デーモン設定ファイル を用いる場合のいずれでも可能です。
以下に示すオプションは、デーモンごとに設定する必要があります。
-b, --bridge= コンテナーにネットワークブリッジを割り当てます。
--exec-root=/var/run/docker Docker の実行ドライバー(execdriver)のルートパス。
--data-root=/var/lib/docker Docker の永続的データのルートパス。
-p, --pidfile=/var/run/docker.pid デーモンの PID ファイルを配置するパス。
-H, --host=[] 接続するデーモンソケット。
--iptables=true iptables ルールの追加を許可します。
--config-file=/etc/docker/daemon.json デーモン設定ファイル。
--tlscacert="~/.docker/ca.pem" この CA によってのみ署名された信頼できる証明局。
--tlscert="~/.docker/cert.pem" TLS 証明書ファイルへのパス。
--tlskey="~/.docker/key.pem" TLS 鍵ファイルへのパス。
--tlskey="~/.docker/key.pem" TLS 鍵ファイルへのパス。
複数実行しているデーモンにおいてこういったフラグに別々の値を設定していても、同一ホスト上で複数デーモンは問題なく動作します。 それぞれのオプションの意味を正しく理解して、適切に利用することが重要です。
-b, --bridge=
フラグは、デフォルトのブリッジネットワークとしてdocker0
が設定されています。 これは Docker をインストールしたときに自動的に生成されるものです。 デフォルトを利用しない場合には、ブリッジを生成し設定することが必要です。 あるいは不要であればnone
とする、つまり--bridge=none
と設定します。--exec-root
はコンテナー状態の保存場所を示すパスです。 デフォルトは/var/run/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
に設定していても Docker は IP マスカレードルールも追加しません。 IP マスカレードルールがないとしたら、デフォルトのブリッジネットワーク以外を利用している場合には、Docker コンテナーは外部ホストやインターネットには接続できません。--config-file=/etc/docker/daemon.json
は、設定ファイルを保存するパスです。 デーモンフラグの代わりにこれを利用することができます。 このパスはデーモンごとに設定してください。--tls*
は Docker デーモンが--tlsverify
モードをサポートするようにします。 このモードではリモートに対して暗号化および認証された接続が求められます。--tls*
オプションはデーモンごとに、特定証明書の利用を可能にします。
以下に示すのは、ネットワークを利用しない Docker デーモンの個別「ブートストラップ」インスタンスを実行するスクリプト例です。
$ sudo dockerd \
-H unix:///var/run/docker-bootstrap.sock \
-p /var/run/docker-bootstrap.pid \
--iptables=false \
--ip-masq=false \
--bridge=none \
--data-root=/var/lib/docker-bootstrap \
--exec-root=/var/run/docker-bootstrap