daemon¶
Usage: docker daemon [OPTIONS]
A self-sufficient runtime for linux containers.
Options:
--api-cors-header="" Set CORS headers in the remote API
-b, --bridge="" Attach containers to a network bridge
--bip="" Specify network bridge IP
-D, --debug=false Enable debug mode
--default-gateway="" Container default gateway IPv4 address
--default-gateway-v6="" Container default gateway IPv6 address
--cluster-store="" URL of the distributed storage backend
--cluster-advertise="" Address of the daemon instance on the cluster
--cluster-store-opt=map[] Set cluster options
--dns=[] DNS server to use
--dns-opt=[] DNS options to use
--dns-search=[] DNS search domains to use
--default-ulimit=[] Set default ulimit settings for containers
-e, --exec-driver="native" Exec driver to use
--exec-opt=[] Set exec driver options
--exec-root="/var/run/docker" Root of the Docker execdriver
--fixed-cidr="" IPv4 subnet for fixed IPs
--fixed-cidr-v6="" IPv6 subnet for fixed IPs
-G, --group="docker" Group for the unix socket
-g, --graph="/var/lib/docker" Root of the Docker runtime
-H, --host=[] Daemon socket(s) to connect to
--help=false Print usage
--icc=true Enable inter-container communication
--insecure-registry=[] Enable insecure registry communication
--ip=0.0.0.0 Default IP when binding container ports
--ip-forward=true Enable net.ipv4.ip_forward
--ip-masq=true Enable IP masquerading
--iptables=true Enable addition of iptables rules
--ipv6=false Enable IPv6 networking
-l, --log-level="info" Set the logging level
--label=[] Set key=value labels to the daemon
--log-driver="json-file" Default driver for container logs
--log-opt=[] Log driver specific options
--mtu=0 Set the containers network MTU
--disable-legacy-registry=false Do not contact legacy registries
-p, --pidfile="/var/run/docker.pid" Path to use for daemon PID file
--registry-mirror=[] Preferred Docker registry mirror
-s, --storage-driver="" Storage driver to use
--selinux-enabled=false Enable selinux support
--storage-opt=[] Set storage driver options
--tls=false Use TLS; implied by --tlsverify
--tlscacert="~/.docker/ca.pem" Trust certs signed only by this CA
--tlscert="~/.docker/cert.pem" Path to TLS certificate file
--tlskey="~/.docker/key.pem" Path to TLS key file
--tlsverify=false Use TLS and verify the remote
--userland-proxy=true Use userland proxy for loopback traffic
[] が付いているオプションは、複数回指定できます。
Docker デーモンはコンテナを管理するために常駐するプロセスです。Docker はデーモンもクライアントも同じバイナリを使います。デーモンを起動するには docker daemon
を入力します。
デーモンでデバッグ出力を行うには、 docker daemon -D
を使います。
デーモン・ソケットのオプション¶
Docker デーモンは Docker リモート API
をリッスンできます。3種類のソケット、 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 ソケット・アクティベーション を通して、 docker damon -H fd://
で通信が可能です。 fd://
は大部分のセットアップで動作しますが、個々のソケットを docker daemon -H fd://3
のように指定できます。もし指定したソケットが見つからない婆は、Docker は終了します。Docker で Systemd ソケット・アクティベーションを使う例は Docker のソース・ツリー をご覧ください。
Docker デーモンは複数の -H
オプションを使い、複数のソケットをリッスンできます。
# デフォルトの unix ソケットと、ホスト上の2つの IP アドレスをリッスンする
docker daemon -H unix:///var/run/docker.sock -H tcp://192.168.59.106 -H tcp://10.10.10.2
Docker クライアントは DOCKER_HOST
環境変数か -H
フラグで接続できるようになります。
$ docker -H tcp://0.0.0.0:2375 ps
# あるいは
$ export DOCKER_HOST="tcp://0.0.0.0:2375"
$ docker ps
# どちらも同じです
DOCKER_TLS_VERIFY
環境変数が設定してあれば、コマンド実行時に --tlsverify
フラグを都度指定するのと同じです。以下はいずれも同じです。
$ docker --tlsverify ps
# または
$ export DOCKER_TLS_VERIFY=1
$ docker ps
Docker クライアントは HTTP_PROXY
、 HTTPS_PROXY
、 NO_PROXY
環境変数を(あるいは小文字でも)使えます。 HTTPS_PROXY
は HTTP_PROXY
よりも上位です。
デーモンのストレージ・ドライバ用オプション¶
Docker デーモンは様々に異なるイメージ・レイヤ・ストレージ・ドライバをサポートしています。ドライバは、 aufs
、 devicemapper
、 btrfs
、 zfs
、 overlay
です。
aufs
ドライバは最も古いものですが、Linux カーネルに対するパッチ群が基になっています。ここにはメイン・カネールにマージされなかったものも含まれます。そのため、深刻なカーネルのクラッシュを引き起こすことも分かっています。しかしながら、 aufs
はコンテナの共有実行と共有ライブラリ・メモリが使える唯一のストレージ・ドライバでもあります。そのため、同じプログラムやライブラリで数千ものコンテナを実行する時は便利な選択でしょう。
devicemapper
ドライバはシン・プロビジョニング(thin provisioning)とコピー・オン・ライト(Copy on Write)スナップショットを使います。各 devicemapper が位置する場所は、典型的なのは /var/lib/docker/devicemapper
です。シン(thin)プールは2つのブロックデバイス上に作られます。1つはデータであり、もう1つはメタデータです。デフォルトでは、これらのブロック・デバイスは、別々のファイルとして自動されたループバックのマウントをもとに、自動的に作成されます。セットアップのカスタマイズ方法は、以下にある ストレージ・ドライバのオプション をご覧ください。 jpetazzo/Resizing Docker containers with the Device Mapper plugin の記事に、オプションを使わない調整のしかたについて説明があります。
btrfs
ドライバは docker build
が非常に高速です。しかし、 devicemapper
のようにデバイス間の実行メモリを共有しません。使うには docker daemon -s btrfs -g /mnt/btrfs_partition
とします。
zfs
ドライバは btrfs
ほど速くありませんが、安定さのためレコードを長く追跡します。 Single Copy ARC
のおかげで、クローン間の共有ブロックが1度キャッシュされます。使うには docker daemon -s zfs
を指定します。異なる zfs ファイルシステムセットを選択するには、 zfs.fsname
オプションを ストレージ・ドライバのオプション で指定します。
overlay
は非常に高速なユニオン・ファイル・システムです。ようやく Linux カーネル 3.18.0 でメインにマージされました。使うには docker daemon -s overlay
を指定します。
注釈
前途有望な overlay
は、機能がまだ若く、プロダクションで使うべきではありません。とりわけ、 overlay
を使うと過度の inode 消費を引き起こしますし(特にイメージが大きく成長すると)、RPM との互換性がありません。
注釈
現在のサポートされていない btrfs
やコピー・オン・ライトのファイルシステムは、 ext4
パーティション上のみで使うべきです。
ストレージ・ドライバのオプション¶
個々のストレージドライバは --storage-opt
フラグでオプションを設定できます。 devicemapper
用のオプションは dm
で始まり、 zfs
用のオプションは zfs
で始まります。
dm.thinpooldev
シン・プール用に使うカスタム・ブロックストレージ・デバイスを指定します。
ブロック・デバイスをデバイスマッパー・ストレージに使う場合、lvm
を使った thin プール・ボリュームの作成・管理がベストです。その後、このボリュームは Docker により、イメージまたはコンテナで、排他的なスナップショット用ボリュームを作成するために使われます。
シン・プールの管理を Docker の外で行うため、最も機能豊富な手法をもたらします。Docker コンテナの背後にあるストレージとして、Docker はデバイスマッパーによる シン・プロビジョニングを活用するからです。lvm をベースにしたシン・プール管理機能に含まれるハイライトは、自動もしくはインタラクティブなシン・プールの容量変更のサポートです。動的にシン・プールを変更する機能とは、lvm が シン・プールをアクティブにする時、自動的にメタデータのチェックを行います。
シン・プールが割り当てられなければフェイルバックします。このとき、ループバックのファイルが作成されます。ループバックは非常に遅いものですが、ストレージの再設定を行わなくても利用可能になります。プロダクション環境においては、ループバックを使わない事を強く推奨します。Docker デーモンで --storage-opt dm.thinpooldev
が指定されていること確認してください。
使用例:
$ docker daemon \
--storage-opt dm.thinpooldev=/dev/mapper/thin-pool
dm.basesize
ベース・デバイス作成時の容量を指定します。これはイメージとコンテナのサイズの上限にあたります。デフォルトの値は 100GB です。シン・デバイスは本質的に「希薄」(sparse)なのを覚えて置いてください。そのため、100GB のデバイスの大半がカラッポで未使用だったとしても、100GB の領域がプールされます。しかしながら、ファイルシステムがより大きなデバイスであれば、カラッポだとしても多くの容量を使うでしょう。
システム全体の「ベース」となるカラッポのファイルシステムに対して、設定値が影響を与えます。これは、既に初期化されているか、取得しているイメージから継承している場合です。とりわけ、この値の変更時には、反映させるために追加の手順が必要です。
$ sudo service docker stop
$ sudo rm -rf /var/lib/docker
$ sudo service docker start
使用例:
$ docker daemon --storage-opt dm.basesize=20G
dm.loopdatasize
注釈
この設定はデバイスマッパーのループバックを変更するものです。プロダクションで使うべきではありません。
「データ」デバイスがシン・プール用に使うためのループバック・ファイルの作成時、この容量の指定に使います。デフォルトの容量は 100GB です。ファイルは希薄なため、初期段階ではさほど容量を使いません。
使用例:
$ docker daemon --storage-opt dm.loopdatasize=200G
dm.loopmetadatasize
注釈
この設定はデバイスマッパーのループバックを変更するものです。プロダクションで使うべきではありません。
「メタデータ」デバイスがシン・プール用に使うためのループバック・ファイルの作成時、この容量の指定に使います。デフォルトの容量は 2GB です。ファイルは希薄なため、初期段階ではさほど容量を使いません。
使用例:
$ docker daemon –storage-opt dm.loopmetadatasize=4G
dm.fs
ベース・デバイスで使用するファイルシステムの種類を指定します。サポートされているオプションは「ext4」と「xfs」です。デフォルトは「xfs」です。
使用例:
$ docker daemon --storage-opt dm.fs=ext4
dm.mkfsarg
ベース・デバイスの作成時に mkfs に対する追加の引数を指定します。
使用例:
$ docker daemon --storage-opt "dm.mkfsarg=-O ^has_journal"
dm.mountopt
シン・デバイスをマウントするときに使う、追加マウントオプションを指定します。
使用例:
$ docker daemon –storage-opt dm.mountopt=nodiscard
dm.datadev
(廃止されました。 dm.thinpooldev
をお使いください )
シン・プール用のブロック・デバイスが使うデータを指定します。
デバイスマッパー用のストレージにブロック・デバイスを使う時、datadev と metadatadev の両方がループバック・デバイスを完全に使わないようにするのが理想です。
使用例:
$ docker daemon \
--storage-opt dm.datadev=/dev/sdb1 \
--storage-opt dm.metadatadev=/dev/sdc1
dm.metadatadev
(廃止されました。 dm.thinpooldev
をお使いください )
シン・プール用のブロック・デバイスが使うメタデータを指定します。
最も性能の高いメタデータとは、データとは軸が異なる場所にあるもので、あるいは SSD を使うのが望ましいでしょう。
新しいメタデータ・プールのセットアップには有効化が必要です。次のように、ゼロ値を使い、始めから 4096 までカラッポのメタデータを作ります。
$ dd if=/dev/zero of=$metadata_dev bs=4096 count=1
使用例:
$ docker daemon \
--storage-opt dm.datadev=/dev/sdb1 \
--storage-opt dm.metadatadev=/dev/sdc1
dm.blocksize
シン・プールで使うカスタム・ブロックサイズを指定します。デフォルトのブロックサイズは 64K です。
使用例:
$ docker daemon --storage-opt dm.blocksize=512K
dm.blkdiscard
デバイスマッパー・デバイスの削除時に blkdiscard を使うか使わないかを指定します。デフォルトは有効であり、ループバック・デバイスを使っているのであれば、イメージやコンテナ削除時にループバック・ファイルを再希薄化させるために使います。
このループバックを無効にすると、コンテナの削除時間がより早くなります。しかし、 /var/lib/docker
ディレクトリで使用している領域量は、コンテナが削除された時点で使っていた領域を返してしまいます。
使用例:
$ docker daemon --storage-opt dm.blkdiscard=false
dm.override_udev_sync_check
devicemapper
と udev
間における udev
同期確認の設定を上書きします。 udev
は Linux カーネル用のデバイスマッパーです。
Docker デーモンが udev
同期をサポートしているかどうかは、 devicemapper
ドライバを使い確認します。
$ docker info
[...]
Udev Sync Supported: true
[...]
udev
同期サポートが true
であれば、 devicemapper
と udev を組み合わせ、コンテナ向けのデバイスを有効化(activation)・無効化(deactivation)します。
udev
同期サポートが false
であれば、 devicemapper
と udev
間で作成・クリーンアップ時に競合を引き起こします。競合状態の結果、エラーが発生して失敗します(の失敗に関する詳しい情報は docker#4036 をご覧ください。)
docker
デーモンを開始するには、 udev
同期をサポートしているかどうかに関わらず、 dm.override_udev_sync_check
を true にします。
$ docker daemon --storage-opt dm.override_udev_sync_check=true
この値が true
の場合、 devicemaper
はエラーが発生しても簡単に警告を表示するだけで、処理を継続します。
注釈
docker
デーモンと環境を追跡するという考えは、 udev
の同期機能をサポートするためのものでした。このトピックに関しては docker#4036 をご覧下さい。一方で、既存の Docker デーモンを、サポートされている別の環境に移行する時のフラグとしても使います。
dm.use_deferred_removal
libdm
やカーネル・ドライバがサポートしている仕組みがあれば、デバイス削除の遅延を有効化します。
デバイス削除の遅延が意味するのは、デバイスを無効化・非アクティブ化しようとしてもビジー(使用中)であれば、デバイス上で遅延削除が予定されます。そして、最後にデバイスを使っているユーザが終了すると、自動的に削除します。
例えば、コンテナを終了すると、関連づけられているシン・デバイスも削除されます。デバイスが他のマウント名前空間も利用しているの場合は、削除できません。コンテナの終了が成功したら、このオプションが有効であれば、システムがデバイスの遅延削除をスケジュールします。使用中のデバイスが削除できるまで、ループを繰り返すことはありません。
使用例:
$ docker daemon --storage-opt dm.use_deferred_removal=true
dm.use_deferred_deletion
シン・プール用デバイスの遅延削除を有効化するのに使います。デフォルトでは、シン・プールの削除は同期します。コンテナを削除する前に、Docker デーモンは関連するデバイスを削除します。ストレージ・ドライバがデバイスを削除できなければ、コンテナの削除は失敗し、デーモンはエラーを表示します。
この失敗を避けるには、デバイス遅延削除(deletion)と、デバイス遅延廃止(removal)をデーモンで有効化します。
$ docker daemon \
--storage-opt dm.use_deferred_deletion=true \
--storage-opt dm.use_deferred_removal=true
この2つのオプションが有効であれば、ドライバがコンテナを削除する時にデバイスが使用中でも、ドライバはデバイスを削除対象としてマークします。その後、デバイスが使えなくなったら、ドライバはデバイスを削除します。
通常、安全のためにデフォルトでこのオプションを有効化すべきです。複数のマウント名前空間にまたがり、マウントポイントの意図しないリークが発生したときに役立つでしょう。
現時点で zfs
がサポートしているオプション:
zfs.fsname
Docker が自身のデータセットとして、どの zfs ファイルシステムを使うか指定します。デフォルトの Docker は docker グラフ( /var/lib/docker
)がある場所を zfs ファイルシステムとして用います。
使用例:
$ docker daemon -s zfs --storage-opt zfs.fsname=zroot/docker
Docker 実行ドライバのオプション¶
Docker デーモンは Linux カーネルの namespaces
、 cgroups
、 SELinux
に対するインターフェースとして、特別に作られた libcontainer
実行ドライバを使います。
lxc
実行ドライバを通して、オリジナルの LXC 名前空間ツール もレガシーとしてサポートします。しかし、新機能を追加するための重要な開発対象ではなくなっています。 -e lxc
をデーモンのフラグに追加し、 lxc
実行ドライバを使えます。
ネイティブ実行ドライバのオプション¶
native
(libcontainer) 実行ドライバは、 --exec-opt
フラグを使ってオプションを指定できます。全てのオプションのフラグには、先頭に native
が付きます。 native.cgroupdriver
オプションが利用可能です。
native.cgroupdriver
オプションはコンテナの cgroups 管理を指定します。 systemd
の cgroupfs
で指定可能です。 systemd
で指定した時、対象が利用可能でなければ、システムは cgroupfs
を使います。デフォルトでは、オプションの指定がない場合、実行ドライバはまず systemd
と cgroupfs
のフェイルバックを試みます。次の例は cgroupfs
を実行ドライバに設定します。
$ sudo docker daemon --exec-opt native.cgroupdriver=cgroupfs
このオプション設定は、デーモンが起動した全てのコンテナに対して適用されます。
デーモンの DNS オプション¶
全ての Docker コンテナに向けての DNS サーバを設定するには、 docker damon --dns 8.8.8.8
を使います。
全ての Docker コンテナに向けて DNS 検索ドメインを設定するには、 docker daemon --dns-search example.com
を使います。
安全ではないレジストリ¶
Docker はプライベート・レジストリが安全かそうでないかを確認します。このセクションでは、 レジストリ として プライベート・レジストリ (private registry) を使い、例としてプライベート・レジストリが myregistry:5000
で動作しているものとします。
安全なレジストリは、TLS を使い、CA 証明書のコピーが /etc/docker/certs.d/myregistry:5000/ca.crt
にあります。安全ではないレジストリとは、TLS を使っていない場合(例:平文の HTTP をリッスン)や、TLS を使っていても Docker デーモンが知らない CA 証明書を使う場合を指します。後者であれば、証明書が /etc/docker/certs.d/myregistry:5000/
以下に存在しないか、証明書の照合に失敗しています(例:CA が違う)。
デフォルトでは、Docker はローカルにあるレジストリ(以下のローカル・レジストリについてをご覧ください)は安全であるとみなします。Docker はレジストリが安全とみなさない限り、安全ではないレジストリとの通信はできません。安全ではないレジストリと通信できるようにするには、Docker デーモンに --insecure-registry
という2つの形式のオプションが必要です。
--insecure-registry myregistry:5000
Docker デーモンに対して、myregistry:5000 は安全ではないと考えられると伝えます。--insecure-registry 10.1.0.0/16
は Docker デーモンに対して、ドメインを逆引きすると、CIDR 構文で記述した対象のサブネット上の IP アドレスを持つ全てが安全ではないと伝えます。
このフラグは、複数のレジストリに対して安全ではないと複数回指定できます。
安全ではないレジストリを「安全ではない」と指定しなければ、 docker 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 ホストの設定に追加する必要があります。
- 各ディストリビューションに対応する
ca-certificates
パッケージをインストールします。
- ネットワーク管理者にプロキシの CA 証明書を訊き、
/etc/pki/tls/certs/ca-bundle.crt
に追加します。
- Docker デーモンに
HTTPS_PROXY=http://username:password@proxy:port/ docker daemon
を付けて起動します。username:
とpassword@
はオプションです。そして、プロ指揮の認証設定も必要であれば追加します。
これは Docker デーモンのリクエストに対してプロキシと認証の設定を追加しただけです。 docker build
でコンテナを実行する時は、プロキシを使うために更なる追加設定が必要です。
Ulimits のデフォルト¶
--default-uliit
を使い、全てのコンテナに対するデフォルトの 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 エンコード・ファイルのパスを指定します。実行例:
docker daemon \
--cluster-advertise 192.168.1.2:2376 \
--cluster-store etcd://192.168.1.2:2379 \
--cluster-store-opt kv.cacertfile=/path/to/ca.pem \
--cluster-store-opt kv.certfile=/path/to/cert.pem \
--cluster-store-opt kv.keyfile=/path/to/key.pem
現在サポートされているクラスタ・ストアのオプションは:
kv.cacertfile
信頼すべき CA 証明書がエンコードされた PEM のローカル・パスを指定します。
kv.certfile
証明書でエンコードされた PEM のローカル・パスを指定。この証明書はクライアントがキーバリュー・ストアとの通信の証明に使います。
kv.keyfile
秘密鍵がエンコードされた PEM のローカル・パスを指定します。この秘密鍵はクライアントがキーバリュー・ストアと通信時に鍵として使います。
その他のオプション¶
IP マスカレードはコンテナがパブリック IP を持っていなくても、インターネット上の他のマシンと通信するための仕組みです。これにより、インターフェースは服宇スのネットワーク・トポロジを持ちますが、 --ip-masq=false
を使って無効化できます。
Docker は Docker データ/ディレクトリ( /var/lib/docker
)と /var/lib/docker/tmp
に対するソフトリンクをサポートしています。 DOCKER_TMPDIR
を使っても、データディレクトリを次のように指定可能です。
DOCKER_TMPDIR=/mnt/disk2/tmp /usr/local/bin/docker daemon -D -g /var/lib/docker -H unix:// > /var/lib/docker-machine/docker.log 2>&1
# あるいは
export DOCKER_TMPDIR=/mnt/disk2/tmp
/usr/local/bin/docker daemon -D -g /var/lib/docker -H unix:// > /var/lib/docker-machine/docker.log 2>&1