path: root/devdocs/docker/engine%2Freference%2Fcommandline%2Fdockerd%2Findex.html

<h1>dockerd</h1> <h2 id="daemon">daemon</h2> <div class="highlight"><pre class="highlight" data-language="">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
  -v, --version                               Print version information and quit
</pre></div> <p>Options with [] may be specified multiple times.</p> <h2 id="description">Description</h2> <p><code class="language-plaintext highlighter-rouge">dockerd</code> is the persistent process that manages containers. Docker uses different binaries for the daemon and client. To run the daemon you type <code class="language-plaintext highlighter-rouge">dockerd</code>.</p> <p>To run the daemon with debug output, use <code class="language-plaintext highlighter-rouge">dockerd --debug</code> or add <code class="language-plaintext highlighter-rouge">"debug": true</code> to <a href="#daemon-configuration-file">the <code class="language-plaintext highlighter-rouge">daemon.json</code> file</a>.</p> <blockquote> <p><strong>Enabling experimental features</strong></p> <p>Enable experimental features by starting <code class="language-plaintext highlighter-rouge">dockerd</code> with the <code class="language-plaintext highlighter-rouge">--experimental</code> flag or adding <code class="language-plaintext highlighter-rouge">"experimental": true</code> to the <code class="language-plaintext highlighter-rouge">daemon.json</code> file.</p> </blockquote> <h3 id="environment-variables">Environment variables</h3> <p>For easy reference, the following list of environment variables are supported by the <code class="language-plaintext highlighter-rouge">dockerd</code> command line:</p> <ul> <li>
<code class="language-plaintext highlighter-rouge">DOCKER_DRIVER</code> The graph driver to use.</li> <li>
<code class="language-plaintext highlighter-rouge">DOCKER_NOWARN_KERNEL_VERSION</code> Prevent warnings that your Linux kernel is unsuitable for Docker.</li> <li>
<code class="language-plaintext highlighter-rouge">DOCKER_RAMDISK</code> If set this will disable ‘pivot_root’.</li> <li>
<code class="language-plaintext highlighter-rouge">DOCKER_TMPDIR</code> Location for temporary Docker files.</li> <li>
<code class="language-plaintext highlighter-rouge">MOBY_DISABLE_PIGZ</code> Do not use <a href="https://linux.die.net/man/1/pigz"><code class="language-plaintext highlighter-rouge">unpigz</code></a> to decompress layers in parallel when pulling images, even if it is installed.</li> </ul> <h2 id="examples">Examples</h2> <h3 id="daemon-socket-option">Daemon socket option</h3> <p>The Docker daemon can listen for <a href="../../../api/index">Docker Engine API</a> requests via three different types of Socket: <code class="language-plaintext highlighter-rouge">unix</code>, <code class="language-plaintext highlighter-rouge">tcp</code>, and <code class="language-plaintext highlighter-rouge">fd</code>.</p> <p>By default, a <code class="language-plaintext highlighter-rouge">unix</code> domain socket (or IPC socket) is created at <code class="language-plaintext highlighter-rouge">/var/run/docker.sock</code>, requiring either <code class="language-plaintext highlighter-rouge">root</code> permission, or <code class="language-plaintext highlighter-rouge">docker</code> group membership.</p> <p>If you need to access the Docker daemon remotely, you need to enable the <code class="language-plaintext highlighter-rouge">tcp</code> Socket. Beware that the default setup provides un-encrypted and un-authenticated direct access to the Docker daemon - and should be secured either using the <a href="../../../security/protect-access/index">built in HTTPS encrypted socket</a>, or by putting a secure web proxy in front of it. You can listen on port <code class="language-plaintext highlighter-rouge">2375</code> on all network interfaces with <code class="language-plaintext highlighter-rouge">-H tcp://0.0.0.0:2375</code>, or on a particular network interface using its IP address: <code class="language-plaintext highlighter-rouge">-H tcp://192.168.59.103:2375</code>. It is conventional to use port <code class="language-plaintext highlighter-rouge">2375</code> for un-encrypted, and port <code class="language-plaintext highlighter-rouge">2376</code> for encrypted communication with the daemon.</p> <blockquote> <p><strong>Note</strong></p> <p>If you’re using an HTTPS encrypted socket, keep in mind that only TLS1.0 and greater are supported. Protocols SSLv3 and under are not supported anymore for security reasons.</p> </blockquote> <p>On Systemd based systems, you can communicate with the daemon via <a href="https://0pointer.de/blog/projects/socket-activation.html">Systemd socket activation</a>, use <code class="language-plaintext highlighter-rouge">dockerd -H fd://</code>. Using <code class="language-plaintext highlighter-rouge">fd://</code> will work perfectly for most setups but you can also specify individual sockets: <code class="language-plaintext highlighter-rouge">dockerd -H fd://3</code>. If the specified socket activated files aren’t found, then Docker will exit. You can find examples of using Systemd socket activation with Docker and Systemd in the <a href="https://github.com/docker/docker/tree/master/contrib/init/systemd/">Docker source tree</a>.</p> <p>You can configure the Docker daemon to listen to multiple sockets at the same time using multiple <code class="language-plaintext highlighter-rouge">-H</code> options:</p> <p>The example below runs the daemon listenin on the default unix socket, and on 2 specific IP addresses on this host:</p> <div class="highlight"><pre class="highlight" data-language="">$ sudo dockerd -H unix:///var/run/docker.sock -H tcp://192.168.59.106 -H tcp://10.10.10.2
</pre></div> <p>The Docker client will honor the <code class="language-plaintext highlighter-rouge">DOCKER_HOST</code> environment variable to set the <code class="language-plaintext highlighter-rouge">-H</code> flag for the client. Use <strong>one</strong> of the following commands:</p> <div class="highlight"><pre class="highlight" data-language="">$ docker -H tcp://0.0.0.0:2375 ps
</pre></div> <div class="highlight"><pre class="highlight" data-language="">$ export DOCKER_HOST="tcp://0.0.0.0:2375"

$ docker ps
</pre></div> <p>Setting the <code class="language-plaintext highlighter-rouge">DOCKER_TLS_VERIFY</code> environment variable to any value other than the empty string is equivalent to setting the <code class="language-plaintext highlighter-rouge">--tlsverify</code> flag. The following are equivalent:</p> <div class="highlight"><pre class="highlight" data-language="">$ docker --tlsverify ps
# or
$ export DOCKER_TLS_VERIFY=1
$ docker ps
</pre></div> <p>The Docker client will honor the <code class="language-plaintext highlighter-rouge">HTTP_PROXY</code>, <code class="language-plaintext highlighter-rouge">HTTPS_PROXY</code>, and <code class="language-plaintext highlighter-rouge">NO_PROXY</code> environment variables (or the lowercase versions thereof). <code class="language-plaintext highlighter-rouge">HTTPS_PROXY</code> takes precedence over <code class="language-plaintext highlighter-rouge">HTTP_PROXY</code>.</p> <p>The Docker client supports connecting to a remote daemon via SSH:</p> <div class="highlight"><pre class="highlight" data-language="">$ docker -H ssh://me@example.com:22 ps
$ docker -H ssh://me@example.com ps
$ docker -H ssh://example.com ps
</pre></div> <p>To use SSH connection, you need to set up <code class="language-plaintext highlighter-rouge">ssh</code> so that it can reach the remote host with public key authentication. Password authentication is not supported. If your key is protected with passphrase, you need to set up <code class="language-plaintext highlighter-rouge">ssh-agent</code>.</p> <h4 id="bind-docker-to-another-hostport-or-a-unix-socket">Bind Docker to another host/port or a Unix socket</h4> <blockquote class="warning"> <p><strong>Warning</strong></p> <p>Changing the default <code class="language-plaintext highlighter-rouge">docker</code> daemon binding to a TCP port or Unix <em>docker</em> user group will increase your security risks by allowing non-root users to gain <em>root</em> access on the host. Make sure you control access to <code class="language-plaintext highlighter-rouge">docker</code>. If you are binding to a TCP port, anyone with access to that port has full Docker access; so it is not advisable on an open network.</p> </blockquote> <p>With <code class="language-plaintext highlighter-rouge">-H</code> it is possible to make the Docker daemon to listen on a specific IP and port. By default, it will listen on <code class="language-plaintext highlighter-rouge">unix:///var/run/docker.sock</code> to allow only local connections by the <em>root</em> user. You <em>could</em> set it to <code class="language-plaintext highlighter-rouge">0.0.0.0:2375</code> or a specific host IP to give access to everybody, but that is <strong>not recommended</strong> because then it is trivial for someone to gain root access to the host where the daemon is running.</p> <p>Similarly, the Docker client can use <code class="language-plaintext highlighter-rouge">-H</code> to connect to a custom port. The Docker client will default to connecting to <code class="language-plaintext highlighter-rouge">unix:///var/run/docker.sock</code> on Linux, and <code class="language-plaintext highlighter-rouge">tcp://127.0.0.1:2376</code> on Windows.</p> <p><code class="language-plaintext highlighter-rouge">-H</code> accepts host and port assignment in the following format:</p> <div class="highlight"><pre class="highlight" data-language="">tcp://[host]:[port][path] or unix://path
</pre></div> <p>For example:</p> <ul> <li>
<code class="language-plaintext highlighter-rouge">tcp://</code> -&gt; TCP connection to <code class="language-plaintext highlighter-rouge">127.0.0.1</code> on either port <code class="language-plaintext highlighter-rouge">2376</code> when TLS encryption is on, or port <code class="language-plaintext highlighter-rouge">2375</code> when communication is in plain text.</li> <li>
<code class="language-plaintext highlighter-rouge">tcp://host:2375</code> -&gt; TCP connection on host:2375</li> <li>
<code class="language-plaintext highlighter-rouge">tcp://host:2375/path</code> -&gt; TCP connection on host:2375 and prepend path to all requests</li> <li>
<code class="language-plaintext highlighter-rouge">unix://path/to/socket</code> -&gt; Unix socket located at <code class="language-plaintext highlighter-rouge">path/to/socket</code>
</li> </ul> <p><code class="language-plaintext highlighter-rouge">-H</code>, when empty, will default to the same value as when no <code class="language-plaintext highlighter-rouge">-H</code> was passed in.</p> <p><code class="language-plaintext highlighter-rouge">-H</code> also accepts short form for TCP bindings: <code class="language-plaintext highlighter-rouge">host:</code> or <code class="language-plaintext highlighter-rouge">host:port</code> or <code class="language-plaintext highlighter-rouge">:port</code></p> <p>Run Docker in daemon mode:</p> <div class="highlight"><pre class="highlight" data-language="">$ sudo &lt;path to&gt;/dockerd -H 0.0.0.0:5555 &amp;
</pre></div> <p>Download an <code class="language-plaintext highlighter-rouge">ubuntu</code> image:</p> <div class="highlight"><pre class="highlight" data-language="">$ docker -H :5555 pull ubuntu
</pre></div> <p>You can use multiple <code class="language-plaintext highlighter-rouge">-H</code>, for example, if you want to listen on both TCP and a Unix socket</p> <div class="highlight"><pre class="highlight" data-language="">$ sudo dockerd -H tcp://127.0.0.1:2375 -H unix:///var/run/docker.sock &amp;
# Download an ubuntu image, use default Unix socket
$ docker pull ubuntu
# OR use the TCP port
$ docker -H tcp://127.0.0.1:2375 pull ubuntu
</pre></div> <h3 id="daemon-storage-driver">Daemon storage-driver</h3> <p>On Linux, the Docker daemon has support for several different image layer storage drivers: <code class="language-plaintext highlighter-rouge">aufs</code>, <code class="language-plaintext highlighter-rouge">devicemapper</code>, <code class="language-plaintext highlighter-rouge">btrfs</code>, <code class="language-plaintext highlighter-rouge">zfs</code>, <code class="language-plaintext highlighter-rouge">overlay</code>, <code class="language-plaintext highlighter-rouge">overlay2</code>, and <code class="language-plaintext highlighter-rouge">fuse-overlayfs</code>.</p> <p>The <code class="language-plaintext highlighter-rouge">aufs</code> driver is the oldest, but is based on a Linux kernel patch-set that is unlikely to be merged into the main kernel. These are also known to cause some serious kernel crashes. However <code class="language-plaintext highlighter-rouge">aufs</code> allows containers to share executable and shared library memory, so is a useful choice when running thousands of containers with the same program or libraries.</p> <p>The <code class="language-plaintext highlighter-rouge">devicemapper</code> driver uses thin provisioning and Copy on Write (CoW) snapshots. For each devicemapper graph location – typically <code class="language-plaintext highlighter-rouge">/var/lib/docker/devicemapper</code> – a thin pool is created based on two block devices, one for data and one for metadata. By default, these block devices are created automatically by using loopback mounts of automatically created sparse files. Refer to <a href="#devicemapper-options">Devicemapper options</a> below for a way how to customize this setup. <a href="https://jpetazzo.github.io/2014/01/29/docker-device-mapper-resize/">~jpetazzo/Resizing Docker containers with the Device Mapper plugin</a> article explains how to tune your existing setup without the use of options.</p> <p>The <code class="language-plaintext highlighter-rouge">btrfs</code> driver is very fast for <code class="language-plaintext highlighter-rouge">docker build</code> - but like <code class="language-plaintext highlighter-rouge">devicemapper</code> does not share executable memory between devices. Use <code class="language-plaintext highlighter-rouge">dockerd --storage-driver btrfs --data-root /mnt/btrfs_partition</code>.</p> <p>The <code class="language-plaintext highlighter-rouge">zfs</code> driver is probably not as fast as <code class="language-plaintext highlighter-rouge">btrfs</code> but has a longer track record on stability. Thanks to <code class="language-plaintext highlighter-rouge">Single Copy ARC</code> shared blocks between clones will be cached only once. Use <code class="language-plaintext highlighter-rouge">dockerd -s zfs</code>. To select a different zfs filesystem set <code class="language-plaintext highlighter-rouge">zfs.fsname</code> option as described in <a href="#zfs-options">ZFS options</a>.</p> <p>The <code class="language-plaintext highlighter-rouge">overlay</code> is a very fast union filesystem. It is now merged in the main Linux kernel as of <a href="https://lkml.org/lkml/2014/10/26/137">3.18.0</a>. <code class="language-plaintext highlighter-rouge">overlay</code> also supports page cache sharing, this means multiple containers accessing the same file can share a single page cache entry (or entries), it makes <code class="language-plaintext highlighter-rouge">overlay</code> as efficient with memory as <code class="language-plaintext highlighter-rouge">aufs</code> driver. Call <code class="language-plaintext highlighter-rouge">dockerd -s overlay</code> to use it.</p> <p>The <code class="language-plaintext highlighter-rouge">overlay2</code> uses the same fast union filesystem but takes advantage of <a href="https://lkml.org/lkml/2015/2/11/106">additional features</a> added in Linux kernel 4.0 to avoid excessive inode consumption. Call <code class="language-plaintext highlighter-rouge">dockerd -s overlay2</code> to use it.</p> <blockquote> <p><strong>Note</strong></p> <p>The <code class="language-plaintext highlighter-rouge">overlay</code> storage driver can cause excessive inode consumption (especially as the number of images grows). We recommend using the <code class="language-plaintext highlighter-rouge">overlay2</code> storage driver instead.</p> </blockquote> <blockquote> <p><strong>Note</strong></p> <p>Both <code class="language-plaintext highlighter-rouge">overlay</code> and <code class="language-plaintext highlighter-rouge">overlay2</code> are currently unsupported on <code class="language-plaintext highlighter-rouge">btrfs</code> or any Copy on Write filesystem and should only be used over <code class="language-plaintext highlighter-rouge">ext4</code> partitions.</p> </blockquote> <p>The <code class="language-plaintext highlighter-rouge">fuse-overlayfs</code> driver is similar to <code class="language-plaintext highlighter-rouge">overlay2</code> but works in userspace. The <code class="language-plaintext highlighter-rouge">fuse-overlayfs</code> driver is expected to be used for <a href="../../../security/rootless/index">Rootless mode</a>.</p> <p>On Windows, the Docker daemon supports a single image layer storage driver depending on the image platform: <code class="language-plaintext highlighter-rouge">windowsfilter</code> for Windows images, and <code class="language-plaintext highlighter-rouge">lcow</code> for Linux containers on Windows.</p> <h3 id="options-per-storage-driver">Options per storage driver</h3> <p>Particular storage-driver can be configured with options specified with <code class="language-plaintext highlighter-rouge">--storage-opt</code> flags. Options for <code class="language-plaintext highlighter-rouge">devicemapper</code> are prefixed with <code class="language-plaintext highlighter-rouge">dm</code>, options for <code class="language-plaintext highlighter-rouge">zfs</code> start with <code class="language-plaintext highlighter-rouge">zfs</code>, options for <code class="language-plaintext highlighter-rouge">btrfs</code> start with <code class="language-plaintext highlighter-rouge">btrfs</code> and options for <code class="language-plaintext highlighter-rouge">lcow</code> start with <code class="language-plaintext highlighter-rouge">lcow</code>.</p> <h4 id="devicemapper-options">Devicemapper options</h4> <p>This is an example of the configuration file for devicemapper on Linux:</p> <div class="highlight"><pre class="highlight" data-language="">{
  "storage-driver": "devicemapper",
  "storage-opts": [
    "dm.thinpooldev=/dev/mapper/thin-pool",
    "dm.use_deferred_deletion=true",
    "dm.use_deferred_removal=true"
  ]
}
</pre></div> <h5 id="dmthinpooldev"><code class="language-plaintext highlighter-rouge">dm.thinpooldev</code></h5> <p>Specifies a custom block storage device to use for the thin pool.</p> <p>If using a block device for device mapper storage, it is best to use <code class="language-plaintext highlighter-rouge">lvm</code> to create and manage the thin-pool volume. This volume is then handed to Docker to exclusively create snapshot volumes needed for images and containers.</p> <p>Managing the thin-pool outside of Engine makes for the most feature-rich method of having Docker utilize device mapper thin provisioning as the backing storage for Docker containers. The highlights of the lvm-based thin-pool management feature include: automatic or interactive thin-pool resize support, dynamically changing thin-pool features, automatic thinp metadata checking when lvm activates the thin-pool, etc.</p> <p>As a fallback if no thin pool is provided, loopback files are created. Loopback is very slow, but can be used without any pre-configuration of storage. It is strongly recommended that you do not use loopback in production. Ensure your Engine daemon has a <code class="language-plaintext highlighter-rouge">--storage-opt dm.thinpooldev</code> argument provided.</p> <h6 id="example">Example:</h6> <div class="highlight"><pre class="highlight" data-language="">$ sudo dockerd --storage-opt dm.thinpooldev=/dev/mapper/thin-pool
</pre></div> <h5 id="dmdirectlvm_device"><code class="language-plaintext highlighter-rouge">dm.directlvm_device</code></h5> <p>As an alternative to providing a thin pool as above, Docker can setup a block device for you.</p> <h6 id="example-1">Example:</h6> <div class="highlight"><pre class="highlight" data-language="">$ sudo dockerd --storage-opt dm.directlvm_device=/dev/xvdf
</pre></div> <h5 id="dmthinp_percent"><code class="language-plaintext highlighter-rouge">dm.thinp_percent</code></h5> <p>Sets the percentage of passed in block device to use for storage.</p> <h6 id="example-2">Example:</h6> <div class="highlight"><pre class="highlight" data-language="">$ sudo dockerd --storage-opt dm.thinp_percent=95
</pre></div> <h5 id="dmthinp_metapercent"><code class="language-plaintext highlighter-rouge">dm.thinp_metapercent</code></h5> <p>Sets the percentage of the passed in block device to use for metadata storage.</p> <h6 id="example-3">Example:</h6> <div class="highlight"><pre class="highlight" data-language="">$ sudo dockerd --storage-opt dm.thinp_metapercent=1
</pre></div> <h5 id="dmthinp_autoextend_threshold"><code class="language-plaintext highlighter-rouge">dm.thinp_autoextend_threshold</code></h5> <p>Sets the value of the percentage of space used before <code class="language-plaintext highlighter-rouge">lvm</code> attempts to autoextend the available space [100 = disabled]</p> <h6 id="example-4">Example:</h6> <div class="highlight"><pre class="highlight" data-language="">$ sudo dockerd --storage-opt dm.thinp_autoextend_threshold=80
</pre></div> <h5 id="dmthinp_autoextend_percent"><code class="language-plaintext highlighter-rouge">dm.thinp_autoextend_percent</code></h5> <p>Sets the value percentage value to increase the thin pool by when <code class="language-plaintext highlighter-rouge">lvm</code> attempts to autoextend the available space [100 = disabled]</p> <h6 id="example-5">Example:</h6> <div class="highlight"><pre class="highlight" data-language="">$ sudo dockerd --storage-opt dm.thinp_autoextend_percent=20
</pre></div> <h5 id="dmbasesize"><code class="language-plaintext highlighter-rouge">dm.basesize</code></h5> <p>Specifies the size to use when creating the base device, which limits the size of images and containers. The default value is 10G. Note, thin devices are inherently “sparse”, so a 10G device which is mostly empty doesn’t use 10 GB of space on the pool. However, the filesystem will use more space for the empty case the larger the device is.</p> <p>The base device size can be increased at daemon restart which will allow all future images and containers (based on those new images) to be of the new base device size.</p> <h6 id="examples-1">Examples</h6> <div class="highlight"><pre class="highlight" data-language="">$ sudo dockerd --storage-opt dm.basesize=50G
</pre></div> <p>This will increase the base device size to 50G. The Docker daemon will throw an error if existing base device size is larger than 50G. A user can use this option to expand the base device size however shrinking is not permitted.</p> <p>This value affects the system-wide “base” empty filesystem that may already be initialized and inherited by pulled images. Typically, a change to this value requires additional steps to take effect:</p> <div class="highlight"><pre class="highlight" data-language="">$ sudo service docker stop

$ sudo rm -rf /var/lib/docker

$ sudo service docker start
</pre></div> <h5 id="dmloopdatasize"><code class="language-plaintext highlighter-rouge">dm.loopdatasize</code></h5> <blockquote> <p><strong>Note</strong></p> <p>This option configures devicemapper loopback, which should not be used in production.</p> </blockquote> <p>Specifies the size to use when creating the loopback file for the “data” device which is used for the thin pool. The default size is 100G. The file is sparse, so it will not initially take up this much space.</p> <h6 id="example-6">Example</h6> <div class="highlight"><pre class="highlight" data-language="">$ sudo dockerd --storage-opt dm.loopdatasize=200G
</pre></div> <h5 id="dmloopmetadatasize"><code class="language-plaintext highlighter-rouge">dm.loopmetadatasize</code></h5> <blockquote> <p><strong>Note</strong></p> <p>This option configures devicemapper loopback, which should not be used in production.</p> </blockquote> <p>Specifies the size to use when creating the loopback file for the “metadata” device which is used for the thin pool. The default size is 2G. The file is sparse, so it will not initially take up this much space.</p> <h6 id="example-7">Example</h6> <div class="highlight"><pre class="highlight" data-language="">$ sudo dockerd --storage-opt dm.loopmetadatasize=4G
</pre></div> <h5 id="dmfs"><code class="language-plaintext highlighter-rouge">dm.fs</code></h5> <p>Specifies the filesystem type to use for the base device. The supported options are “ext4” and “xfs”. The default is “xfs”</p> <h6 id="example-8">Example</h6> <div class="highlight"><pre class="highlight" data-language="">$ sudo dockerd --storage-opt dm.fs=ext4
</pre></div> <h5 id="dmmkfsarg"><code class="language-plaintext highlighter-rouge">dm.mkfsarg</code></h5> <p>Specifies extra mkfs arguments to be used when creating the base device.</p> <h6 id="example-9">Example</h6> <div class="highlight"><pre class="highlight" data-language="">$ sudo dockerd --storage-opt "dm.mkfsarg=-O ^has_journal"
</pre></div> <h5 id="dmmountopt"><code class="language-plaintext highlighter-rouge">dm.mountopt</code></h5> <p>Specifies extra mount options used when mounting the thin devices.</p> <h6 id="example-10">Example</h6> <div class="highlight"><pre class="highlight" data-language="">$ sudo dockerd --storage-opt dm.mountopt=nodiscard
</pre></div> <h5 id="dmdatadev"><code class="language-plaintext highlighter-rouge">dm.datadev</code></h5> <p>(Deprecated, use <code class="language-plaintext highlighter-rouge">dm.thinpooldev</code>)</p> <p>Specifies a custom blockdevice to use for data for the thin pool.</p> <p>If using a block device for device mapper storage, ideally both <code class="language-plaintext highlighter-rouge">datadev</code> and <code class="language-plaintext highlighter-rouge">metadatadev</code> should be specified to completely avoid using the loopback device.</p> <h6 id="example-11">Example</h6> <div class="highlight"><pre class="highlight" data-language="">$ sudo dockerd \
      --storage-opt dm.datadev=/dev/sdb1 \
      --storage-opt dm.metadatadev=/dev/sdc1
</pre></div> <h5 id="dmmetadatadev"><code class="language-plaintext highlighter-rouge">dm.metadatadev</code></h5> <p>(Deprecated, use <code class="language-plaintext highlighter-rouge">dm.thinpooldev</code>)</p> <p>Specifies a custom blockdevice to use for metadata for the thin pool.</p> <p>For best performance the metadata should be on a different spindle than the data, or even better on an SSD.</p> <p>If setting up a new metadata pool it is required to be valid. This can be achieved by zeroing the first 4k to indicate empty metadata, like this:</p> <div class="highlight"><pre class="highlight" data-language="">$ dd if=/dev/zero of=$metadata_dev bs=4096 count=1
</pre></div> <h6 id="example-12">Example</h6> <div class="highlight"><pre class="highlight" data-language="">$ sudo dockerd \
      --storage-opt dm.datadev=/dev/sdb1 \
      --storage-opt dm.metadatadev=/dev/sdc1
</pre></div> <h5 id="dmblocksize"><code class="language-plaintext highlighter-rouge">dm.blocksize</code></h5> <p>Specifies a custom blocksize to use for the thin pool. The default blocksize is 64K.</p> <h6 id="example-13">Example</h6> <div class="highlight"><pre class="highlight" data-language="">$ sudo dockerd --storage-opt dm.blocksize=512K
</pre></div> <h5 id="dmblkdiscard"><code class="language-plaintext highlighter-rouge">dm.blkdiscard</code></h5> <p>Enables or disables the use of <code class="language-plaintext highlighter-rouge">blkdiscard</code> when removing devicemapper devices. This is enabled by default (only) if using loopback devices and is required to resparsify the loopback file on image/container removal.</p> <p>Disabling this on loopback can lead to <em>much</em> faster container removal times, but will make the space used in <code class="language-plaintext highlighter-rouge">/var/lib/docker</code> directory not be returned to the system for other use when containers are removed.</p> <h6 id="examples-2">Examples</h6> <div class="highlight"><pre class="highlight" data-language="">$ sudo dockerd --storage-opt dm.blkdiscard=false
</pre></div> <h5 id="dmoverride_udev_sync_check"><code class="language-plaintext highlighter-rouge">dm.override_udev_sync_check</code></h5> <p>Overrides the <code class="language-plaintext highlighter-rouge">udev</code> synchronization checks between <code class="language-plaintext highlighter-rouge">devicemapper</code> and <code class="language-plaintext highlighter-rouge">udev</code>. <code class="language-plaintext highlighter-rouge">udev</code> is the device manager for the Linux kernel.</p> <p>To view the <code class="language-plaintext highlighter-rouge">udev</code> sync support of a Docker daemon that is using the <code class="language-plaintext highlighter-rouge">devicemapper</code> driver, run:</p> <div class="highlight"><pre class="highlight" data-language="">$ docker info
&lt;...&gt;
Udev Sync Supported: true
&lt;...&gt;
</pre></div> <p>When <code class="language-plaintext highlighter-rouge">udev</code> sync support is <code class="language-plaintext highlighter-rouge">true</code>, then <code class="language-plaintext highlighter-rouge">devicemapper</code> and udev can coordinate the activation and deactivation of devices for containers.</p> <p>When <code class="language-plaintext highlighter-rouge">udev</code> sync support is <code class="language-plaintext highlighter-rouge">false</code>, a race condition occurs between the<code class="language-plaintext highlighter-rouge">devicemapper</code> and <code class="language-plaintext highlighter-rouge">udev</code> during create and cleanup. The race condition results in errors and failures. (For information on these failures, see <a href="https://github.com/docker/docker/issues/4036">docker#4036</a>)</p> <p>To allow the <code class="language-plaintext highlighter-rouge">docker</code> daemon to start, regardless of <code class="language-plaintext highlighter-rouge">udev</code> sync not being supported, set <code class="language-plaintext highlighter-rouge">dm.override_udev_sync_check</code> to true:</p> <div class="highlight"><pre class="highlight" data-language="">$ sudo dockerd --storage-opt dm.override_udev_sync_check=true
</pre></div> <p>When this value is <code class="language-plaintext highlighter-rouge">true</code>, the <code class="language-plaintext highlighter-rouge">devicemapper</code> continues and simply warns you the errors are happening.</p> <blockquote> <p><strong>Note</strong></p> <p>The ideal is to pursue a <code class="language-plaintext highlighter-rouge">docker</code> daemon and environment that does support synchronizing with <code class="language-plaintext highlighter-rouge">udev</code>. For further discussion on this topic, see <a href="https://github.com/docker/docker/issues/4036">docker#4036</a>. Otherwise, set this flag for migrating existing Docker daemons to a daemon with a supported environment.</p> </blockquote> <h5 id="dmuse_deferred_removal"><code class="language-plaintext highlighter-rouge">dm.use_deferred_removal</code></h5> <p>Enables use of deferred device removal if <code class="language-plaintext highlighter-rouge">libdm</code> and the kernel driver support the mechanism.</p> <p>Deferred device removal means that if device is busy when devices are being removed/deactivated, then a deferred removal is scheduled on device. And devices automatically go away when last user of the device exits.</p> <p>For example, when a container exits, its associated thin device is removed. If that device has leaked into some other mount namespace and can’t be removed, the container exit still succeeds and this option causes the system to schedule the device for deferred removal. It does not wait in a loop trying to remove a busy device.</p> <h6 id="example-14">Example</h6> <div class="highlight"><pre class="highlight" data-language="">$ sudo dockerd --storage-opt dm.use_deferred_removal=true
</pre></div> <h5 id="dmuse_deferred_deletion"><code class="language-plaintext highlighter-rouge">dm.use_deferred_deletion</code></h5> <p>Enables use of deferred device deletion for thin pool devices. By default, thin pool device deletion is synchronous. Before a container is deleted, the Docker daemon removes any associated devices. If the storage driver can not remove a device, the container deletion fails and daemon returns.</p> <div class="highlight"><pre class="highlight" data-language="">Error deleting container: Error response from daemon: Cannot destroy container
</pre></div> <p>To avoid this failure, enable both deferred device deletion and deferred device removal on the daemon.</p> <div class="highlight"><pre class="highlight" data-language="">$ sudo dockerd \
      --storage-opt dm.use_deferred_deletion=true \
      --storage-opt dm.use_deferred_removal=true
</pre></div> <p>With these two options enabled, if a device is busy when the driver is deleting a container, the driver marks the device as deleted. Later, when the device isn’t in use, the driver deletes it.</p> <p>In general it should be safe to enable this option by default. It will help when unintentional leaking of mount point happens across multiple mount namespaces.</p> <h5 id="dmmin_free_space"><code class="language-plaintext highlighter-rouge">dm.min_free_space</code></h5> <p>Specifies the min free space percent in a thin pool require for new device creation to succeed. This check applies to both free data space as well as free metadata space. Valid values are from 0% - 99%. Value 0% disables free space checking logic. If user does not specify a value for this option, the Engine uses a default value of 10%.</p> <p>Whenever a new a thin pool device is created (during <code class="language-plaintext highlighter-rouge">docker pull</code> or during container creation), the Engine checks if the minimum free space is available. If sufficient space is unavailable, then device creation fails and any relevant <code class="language-plaintext highlighter-rouge">docker</code> operation fails.</p> <p>To recover from this error, you must create more free space in the thin pool to recover from the error. You can create free space by deleting some images and containers from the thin pool. You can also add more storage to the thin pool.</p> <p>To add more space to a LVM (logical volume management) thin pool, just add more storage to the volume group container thin pool; this should automatically resolve any errors. If your configuration uses loop devices, then stop the Engine daemon, grow the size of loop files and restart the daemon to resolve the issue.</p> <h6 id="example-15">Example</h6> <div class="highlight"><pre class="highlight" data-language="">$ sudo dockerd --storage-opt dm.min_free_space=10%
</pre></div> <h5 id="dmxfs_nospace_max_retries"><code class="language-plaintext highlighter-rouge">dm.xfs_nospace_max_retries</code></h5> <p>Specifies the maximum number of retries XFS should attempt to complete IO when ENOSPC (no space) error is returned by underlying storage device.</p> <p>By default XFS retries infinitely for IO to finish and this can result in unkillable process. To change this behavior one can set xfs_nospace_max_retries to say 0 and XFS will not retry IO after getting ENOSPC and will shutdown filesystem.</p> <h6 id="example-16">Example</h6> <div class="highlight"><pre class="highlight" data-language="">$ sudo dockerd --storage-opt dm.xfs_nospace_max_retries=0
</pre></div> <h5 id="dmlibdm_log_level"><code class="language-plaintext highlighter-rouge">dm.libdm_log_level</code></h5> <p>Specifies the maxmimum <code class="language-plaintext highlighter-rouge">libdm</code> log level that will be forwarded to the <code class="language-plaintext highlighter-rouge">dockerd</code> log (as specified by <code class="language-plaintext highlighter-rouge">--log-level</code>). This option is primarily intended for debugging problems involving <code class="language-plaintext highlighter-rouge">libdm</code>. Using values other than the defaults may cause false-positive warnings to be logged.</p> <p>Values specified must fall within the range of valid <code class="language-plaintext highlighter-rouge">libdm</code> log levels. At the time of writing, the following is the list of <code class="language-plaintext highlighter-rouge">libdm</code> log levels as well as their corresponding levels when output by <code class="language-plaintext highlighter-rouge">dockerd</code>.</p> <table> <thead> <tr> <th>
<code class="language-plaintext highlighter-rouge">libdm</code> Level</th> <th style="text-align: right">Value</th> <th><code class="language-plaintext highlighter-rouge">--log-level</code></th> </tr> </thead> <tbody> <tr> <td><code class="language-plaintext highlighter-rouge">_LOG_FATAL</code></td> <td style="text-align: right">2</td> <td>error</td> </tr> <tr> <td><code class="language-plaintext highlighter-rouge">_LOG_ERR</code></td> <td style="text-align: right">3</td> <td>error</td> </tr> <tr> <td><code class="language-plaintext highlighter-rouge">_LOG_WARN</code></td> <td style="text-align: right">4</td> <td>warn</td> </tr> <tr> <td><code class="language-plaintext highlighter-rouge">_LOG_NOTICE</code></td> <td style="text-align: right">5</td> <td>info</td> </tr> <tr> <td><code class="language-plaintext highlighter-rouge">_LOG_INFO</code></td> <td style="text-align: right">6</td> <td>info</td> </tr> <tr> <td><code class="language-plaintext highlighter-rouge">_LOG_DEBUG</code></td> <td style="text-align: right">7</td> <td>debug</td> </tr> </tbody> </table> <h6 id="example-17">Example</h6> <div class="highlight"><pre class="highlight" data-language="">$ sudo dockerd \
      --log-level debug \
      --storage-opt dm.libdm_log_level=7
</pre></div> <h4 id="zfs-options">ZFS options</h4> <h5 id="zfsfsname"><code class="language-plaintext highlighter-rouge">zfs.fsname</code></h5> <p>Set zfs filesystem under which docker will create its own datasets. By default docker will pick up the zfs filesystem where docker graph (<code class="language-plaintext highlighter-rouge">/var/lib/docker</code>) is located.</p> <h6 id="example-18">Example</h6> <div class="highlight"><pre class="highlight" data-language="">$ sudo dockerd -s zfs --storage-opt zfs.fsname=zroot/docker
</pre></div> <h4 id="btrfs-options">Btrfs options</h4> <h5 id="btrfsmin_space"><code class="language-plaintext highlighter-rouge">btrfs.min_space</code></h5> <p>Specifies the minimum size to use when creating the subvolume which is used for containers. If user uses disk quota for btrfs when creating or running a container with <strong>--storage-opt size</strong> option, docker should ensure the <strong>size</strong> cannot be smaller than <strong>btrfs.min_space</strong>.</p> <h6 id="example-19">Example</h6> <div class="highlight"><pre class="highlight" data-language="">$ sudo dockerd -s btrfs --storage-opt btrfs.min_space=10G
</pre></div> <h4 id="overlay2-options">Overlay2 options</h4> <h5 id="overlay2override_kernel_check"><code class="language-plaintext highlighter-rouge">overlay2.override_kernel_check</code></h5> <p>Overrides the Linux kernel version check allowing overlay2. Support for specifying multiple lower directories needed by overlay2 was added to the Linux kernel in 4.0.0. However, some older kernel versions may be patched to add multiple lower directory support for OverlayFS. This option should only be used after verifying this support exists in the kernel. Applying this option on a kernel without this support will cause failures on mount.</p> <h5 id="overlay2size"><code class="language-plaintext highlighter-rouge">overlay2.size</code></h5> <p>Sets the default max size of the container. It is supported only when the backing fs is <code class="language-plaintext highlighter-rouge">xfs</code> and mounted with <code class="language-plaintext highlighter-rouge">pquota</code> mount option. Under these conditions the user can pass any size less then the backing fs size.</p> <h6 id="example-20">Example</h6> <div class="highlight"><pre class="highlight" data-language="">$ sudo dockerd -s overlay2 --storage-opt overlay2.size=1G
</pre></div> <h4 id="windowsfilter-options">Windowsfilter options</h4> <h5 id="size"><code class="language-plaintext highlighter-rouge">size</code></h5> <p>Specifies the size to use when creating the sandbox which is used for containers. Defaults to 20G.</p> <h6 id="example-21">Example</h6> <div class="highlight"><pre class="highlight" data-language="">C:\&gt; dockerd --storage-opt size=40G
</pre></div> <h4 id="lcow-linux-containers-on-windows-options">LCOW (Linux Containers on Windows) options</h4> <h5 id="lcowglobalmode"><code class="language-plaintext highlighter-rouge">lcow.globalmode</code></h5> <p>Specifies whether the daemon instantiates utility VM instances as required (recommended and default if omitted), or uses single global utility VM (better performance, but has security implications and not recommended for production deployments).</p> <h6 id="example-22">Example</h6> <div class="highlight"><pre class="highlight" data-language="">C:\&gt; dockerd --storage-opt lcow.globalmode=false
</pre></div> <h5 id="lcowkirdpath"><code class="language-plaintext highlighter-rouge">lcow.kirdpath</code></h5> <p>Specifies the folder path to the location of a pair of kernel and initrd files used for booting a utility VM. Defaults to <code class="language-plaintext highlighter-rouge">%ProgramFiles%\Linux Containers</code>.</p> <h6 id="example-23">Example</h6> <div class="highlight"><pre class="highlight" data-language="">C:\&gt; dockerd --storage-opt lcow.kirdpath=c:\path\to\files
</pre></div> <h5 id="lcowkernel"><code class="language-plaintext highlighter-rouge">lcow.kernel</code></h5> <p>Specifies the filename of a kernel file located in the <code class="language-plaintext highlighter-rouge">lcow.kirdpath</code> path. Defaults to <code class="language-plaintext highlighter-rouge">bootx64.efi</code>.</p> <h6 id="example-24">Example</h6> <div class="highlight"><pre class="highlight" data-language="">C:\&gt; dockerd --storage-opt lcow.kernel=kernel.efi
</pre></div> <h5 id="lcowinitrd"><code class="language-plaintext highlighter-rouge">lcow.initrd</code></h5> <p>Specifies the filename of an initrd file located in the <code class="language-plaintext highlighter-rouge">lcow.kirdpath</code> path. Defaults to <code class="language-plaintext highlighter-rouge">initrd.img</code>.</p> <h6 id="example-25">Example</h6> <div class="highlight"><pre class="highlight" data-language="">C:\&gt; dockerd --storage-opt lcow.initrd=myinitrd.img
</pre></div> <h5 id="lcowbootparameters"><code class="language-plaintext highlighter-rouge">lcow.bootparameters</code></h5> <p>Specifies additional boot parameters for booting utility VMs when in kernel/ initrd mode. Ignored if the utility VM is booting from VHD. These settings are kernel specific.</p> <h6 id="example-26">Example</h6> <div class="highlight"><pre class="highlight" data-language="">C:\&gt; dockerd --storage-opt "lcow.bootparameters='option=value'"
</pre></div> <h5 id="lcowvhdx"><code class="language-plaintext highlighter-rouge">lcow.vhdx</code></h5> <p>Specifies a custom VHDX to boot a utility VM, as an alternate to kernel and initrd booting. Defaults to <code class="language-plaintext highlighter-rouge">uvm.vhdx</code> under <code class="language-plaintext highlighter-rouge">lcow.kirdpath</code>.</p> <h6 id="example-27">Example</h6> <div class="highlight"><pre class="highlight" data-language="">C:\&gt; dockerd --storage-opt lcow.vhdx=custom.vhdx
</pre></div> <h5 id="lcowtimeout"><code class="language-plaintext highlighter-rouge">lcow.timeout</code></h5> <p>Specifies the timeout for utility VM operations in seconds. Defaults to 300.</p> <h6 id="example-28">Example</h6> <div class="highlight"><pre class="highlight" data-language="">C:\&gt; dockerd --storage-opt lcow.timeout=240
</pre></div> <h5 id="lcowsandboxsize"><code class="language-plaintext highlighter-rouge">lcow.sandboxsize</code></h5> <p>Specifies the size in GB to use when creating the sandbox which is used for containers. Defaults to 20. Cannot be less than 20.</p> <h6 id="example-29">Example</h6> <div class="highlight"><pre class="highlight" data-language="">C:\&gt; dockerd --storage-opt lcow.sandboxsize=40
</pre></div> <h3 id="docker-runtime-execution-options">Docker runtime execution options</h3> <p>The Docker daemon relies on a <a href="https://github.com/opencontainers/runtime-spec">OCI</a> compliant runtime (invoked via the <code class="language-plaintext highlighter-rouge">containerd</code> daemon) as its interface to the Linux kernel <code class="language-plaintext highlighter-rouge">namespaces</code>, <code class="language-plaintext highlighter-rouge">cgroups</code>, and <code class="language-plaintext highlighter-rouge">SELinux</code>.</p> <p>By default, the Docker daemon automatically starts <code class="language-plaintext highlighter-rouge">containerd</code>. If you want to control <code class="language-plaintext highlighter-rouge">containerd</code> startup, manually start <code class="language-plaintext highlighter-rouge">containerd</code> and pass the path to the <code class="language-plaintext highlighter-rouge">containerd</code> socket using the <code class="language-plaintext highlighter-rouge">--containerd</code> flag. For example:</p> <div class="highlight"><pre class="highlight" data-language="">$ sudo dockerd --containerd /var/run/dev/docker-containerd.sock
</pre></div> <p>Runtimes can be registered with the daemon either via the configuration file or using the <code class="language-plaintext highlighter-rouge">--add-runtime</code> command line argument.</p> <p>The following is an example adding 2 runtimes via the configuration:</p> <div class="highlight"><pre class="highlight" data-language="">{
  "default-runtime": "runc",
  "runtimes": {
    "custom": {
      "path": "/usr/local/bin/my-runc-replacement",
      "runtimeArgs": [
        "--debug"
      ]
    },
    "runc": {
      "path": "runc"
    }
  }
}
</pre></div> <p>This is the same example via the command line:</p> <div class="highlight"><pre class="highlight" data-language="">$ sudo dockerd --add-runtime runc=runc --add-runtime custom=/usr/local/bin/my-runc-replacement
</pre></div> <blockquote> <p><strong>Note</strong></p> <p>Defining runtime arguments via the command line is not supported.</p> </blockquote> <h4 id="options-for-the-runtime">Options for the runtime</h4> <p>You can configure the runtime using options specified with the <code class="language-plaintext highlighter-rouge">--exec-opt</code> flag. All the flag’s options have the <code class="language-plaintext highlighter-rouge">native</code> prefix. A single <code class="language-plaintext highlighter-rouge">native.cgroupdriver</code> option is available.</p> <p>The <code class="language-plaintext highlighter-rouge">native.cgroupdriver</code> option specifies the management of the container’s cgroups. You can only specify <code class="language-plaintext highlighter-rouge">cgroupfs</code> or <code class="language-plaintext highlighter-rouge">systemd</code>. If you specify <code class="language-plaintext highlighter-rouge">systemd</code> and it is not available, the system errors out. If you omit the <code class="language-plaintext highlighter-rouge">native.cgroupdriver</code> option,<code class="language-plaintext highlighter-rouge">cgroupfs</code> is used on cgroup v1 hosts, <code class="language-plaintext highlighter-rouge">systemd</code> is used on cgroup v2 hosts with systemd available.</p> <p>This example sets the <code class="language-plaintext highlighter-rouge">cgroupdriver</code> to <code class="language-plaintext highlighter-rouge">systemd</code>:</p> <div class="highlight"><pre class="highlight" data-language="">$ sudo dockerd --exec-opt native.cgroupdriver=systemd
</pre></div> <p>Setting this option applies to all containers the daemon launches.</p> <p>Also Windows Container makes use of <code class="language-plaintext highlighter-rouge">--exec-opt</code> for special purpose. Docker user can specify default container isolation technology with this, for example:</p> <div class="highlight"><pre class="highlight" data-language="">&gt; dockerd --exec-opt isolation=hyperv
</pre></div> <p>Will make <code class="language-plaintext highlighter-rouge">hyperv</code> the default isolation technology on Windows. If no isolation value is specified on daemon start, on Windows client, the default is <code class="language-plaintext highlighter-rouge">hyperv</code>, and on Windows server, the default is <code class="language-plaintext highlighter-rouge">process</code>.</p> <h3 id="daemon-dns-options">Daemon DNS options</h3> <p>To set the DNS server for all Docker containers, use:</p> <div class="highlight"><pre class="highlight" data-language="">$ sudo dockerd --dns 8.8.8.8
</pre></div> <p>To set the DNS search domain for all Docker containers, use:</p> <div class="highlight"><pre class="highlight" data-language="">$ sudo dockerd --dns-search example.com
</pre></div> <h3 id="allow-push-of-nondistributable-artifacts">Allow push of nondistributable artifacts</h3> <p>Some images (e.g., Windows base images) contain artifacts whose distribution is restricted by license. When these images are pushed to a registry, restricted artifacts are not included.</p> <p>To override this behavior for specific registries, use the <code class="language-plaintext highlighter-rouge">--allow-nondistributable-artifacts</code> option in one of the following forms:</p> <ul> <li>
<code class="language-plaintext highlighter-rouge">--allow-nondistributable-artifacts myregistry:5000</code> tells the Docker daemon to push nondistributable artifacts to myregistry:5000.</li> <li>
<code class="language-plaintext highlighter-rouge">--allow-nondistributable-artifacts 10.1.0.0/16</code> tells the Docker daemon to push nondistributable artifacts to all registries whose resolved IP address is within the subnet described by the CIDR syntax.</li> </ul> <p>This option can be used multiple times.</p> <p>This option is useful when pushing images containing nondistributable artifacts to a registry on an air-gapped network so hosts on that network can pull the images without connecting to another server.</p> <blockquote> <p><strong>Warning</strong>: Nondistributable artifacts typically have restrictions on how and where they can be distributed and shared. Only use this feature to push artifacts to private registries and ensure that you are in compliance with any terms that cover redistributing nondistributable artifacts.</p> </blockquote> <h3 id="insecure-registries">Insecure registries</h3> <p>Docker considers a private registry either secure or insecure. In the rest of this section, <em>registry</em> is used for <em>private registry</em>, and <code class="language-plaintext highlighter-rouge">myregistry:5000</code> is a placeholder example for a private registry.</p> <p>A secure registry uses TLS and a copy of its CA certificate is placed on the Docker host at <code class="language-plaintext highlighter-rouge">/etc/docker/certs.d/myregistry:5000/ca.crt</code>. An insecure registry is either not using TLS (i.e., listening on plain text HTTP), or is using TLS with a CA certificate not known by the Docker daemon. The latter can happen when the certificate was not found under <code class="language-plaintext highlighter-rouge">/etc/docker/certs.d/myregistry:5000/</code>, or if the certificate verification failed (i.e., wrong CA).</p> <p>By default, Docker assumes all, but local (see local registries below), registries are secure. Communicating with an insecure registry is not possible if Docker assumes that registry is secure. In order to communicate with an insecure registry, the Docker daemon requires <code class="language-plaintext highlighter-rouge">--insecure-registry</code> in one of the following two forms:</p> <ul> <li>
<code class="language-plaintext highlighter-rouge">--insecure-registry myregistry:5000</code> tells the Docker daemon that myregistry:5000 should be considered insecure.</li> <li>
<code class="language-plaintext highlighter-rouge">--insecure-registry 10.1.0.0/16</code> tells the Docker daemon that all registries whose domain resolve to an IP address is part of the subnet described by the CIDR syntax, should be considered insecure.</li> </ul> <p>The flag can be used multiple times to allow multiple registries to be marked as insecure.</p> <p>If an insecure registry is not marked as insecure, <code class="language-plaintext highlighter-rouge">docker pull</code>, <code class="language-plaintext highlighter-rouge">docker push</code>, and <code class="language-plaintext highlighter-rouge">docker search</code> will result in an error message prompting the user to either secure or pass the <code class="language-plaintext highlighter-rouge">--insecure-registry</code> flag to the Docker daemon as described above.</p> <p>Local registries, whose IP address falls in the 127.0.0.0/8 range, are automatically marked as insecure as of Docker 1.3.2. It is not recommended to rely on this, as it may change in the future.</p> <p>Enabling <code class="language-plaintext highlighter-rouge">--insecure-registry</code>, i.e., allowing un-encrypted and/or untrusted communication, can be useful when running a local registry. However, because its use creates security vulnerabilities it should ONLY be enabled for testing purposes. For increased security, users should add their CA to their system’s list of trusted CAs instead of enabling <code class="language-plaintext highlighter-rouge">--insecure-registry</code>.</p> <h4 id="legacy-registries">Legacy Registries</h4> <p>Operations against registries supporting only the legacy v1 protocol are no longer supported. Specifically, the daemon will not attempt <code class="language-plaintext highlighter-rouge">push</code>, <code class="language-plaintext highlighter-rouge">pull</code> and <code class="language-plaintext highlighter-rouge">login</code> to v1 registries. The exception to this is <code class="language-plaintext highlighter-rouge">search</code> which can still be performed on v1 registries.</p> <h3 id="running-a-docker-daemon-behind-an-https_proxy">Running a Docker daemon behind an HTTPS_PROXY</h3> <p>When running inside a LAN that uses an <code class="language-plaintext highlighter-rouge">HTTPS</code> proxy, the Docker Hub certificates will be replaced by the proxy’s certificates. These certificates need to be added to your Docker host’s configuration:</p> <ol> <li>Install the <code class="language-plaintext highlighter-rouge">ca-certificates</code> package for your distribution</li> <li>Ask your network admin for the proxy’s CA certificate and append them to <code class="language-plaintext highlighter-rouge">/etc/pki/tls/certs/ca-bundle.crt</code>
</li> <li>Then start your Docker daemon with <code class="language-plaintext highlighter-rouge">HTTPS_PROXY=http://username:password@proxy:port/ dockerd</code>. The <code class="language-plaintext highlighter-rouge">username:</code> and <code class="language-plaintext highlighter-rouge">password@</code> are optional - and are only needed if your proxy is set up to require authentication.</li> </ol> <p>This will only add the proxy and authentication to the Docker daemon’s requests - your <code class="language-plaintext highlighter-rouge">docker build</code>s and running containers will need extra configuration to use the proxy</p> <h3 id="default-ulimit-settings">Default <code class="language-plaintext highlighter-rouge">ulimit</code> settings</h3> <p><code class="language-plaintext highlighter-rouge">--default-ulimit</code> allows you to set the default <code class="language-plaintext highlighter-rouge">ulimit</code> options to use for all containers. It takes the same options as <code class="language-plaintext highlighter-rouge">--ulimit</code> for <code class="language-plaintext highlighter-rouge">docker run</code>. If these defaults are not set, <code class="language-plaintext highlighter-rouge">ulimit</code> settings will be inherited, if not set on <code class="language-plaintext highlighter-rouge">docker run</code>, from the Docker daemon. Any <code class="language-plaintext highlighter-rouge">--ulimit</code> options passed to <code class="language-plaintext highlighter-rouge">docker run</code> will overwrite these defaults.</p> <p>Be careful setting <code class="language-plaintext highlighter-rouge">nproc</code> with the <code class="language-plaintext highlighter-rouge">ulimit</code> flag as <code class="language-plaintext highlighter-rouge">nproc</code> is designed by Linux to set the maximum number of processes available to a user, not to a container. For details please check the <a href="../run/index">run</a> reference.</p> <h3 id="node-discovery">Node discovery</h3> <p>The <code class="language-plaintext highlighter-rouge">--cluster-advertise</code> option specifies the <code class="language-plaintext highlighter-rouge">host:port</code> or <code class="language-plaintext highlighter-rouge">interface:port</code> combination that this particular daemon instance should use when advertising itself to the cluster. The daemon is reached by remote hosts through this value. If you specify an interface, make sure it includes the IP address of the actual Docker host. For Engine installation created through <code class="language-plaintext highlighter-rouge">docker-machine</code>, the interface is typically <code class="language-plaintext highlighter-rouge">eth1</code>.</p> <p>The daemon uses <a href="https://github.com/docker/libkv/">libkv</a> to advertise the node within the cluster. Some key-value backends support mutual TLS. To configure the client TLS settings used by the daemon can be configured using the <code class="language-plaintext highlighter-rouge">--cluster-store-opt</code> flag, specifying the paths to PEM encoded files. For example:</p> <div class="highlight"><pre class="highlight" data-language="">$ 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
</pre></div> <p>The currently supported cluster store options are:</p> <table> <thead> <tr> <th style="text-align: left">Option</th> <th style="text-align: left">Description</th> </tr> </thead> <tbody> <tr> <td style="text-align: left"><code class="language-plaintext highlighter-rouge">discovery.heartbeat</code></td> <td style="text-align: left">Specifies the heartbeat timer in seconds which is used by the daemon as a <code class="language-plaintext highlighter-rouge">keepalive</code> mechanism to make sure discovery module treats the node as alive in the cluster. If not configured, the default value is 20 seconds.</td> </tr> <tr> <td style="text-align: left"><code class="language-plaintext highlighter-rouge">discovery.ttl</code></td> <td style="text-align: left">Specifies the TTL (time-to-live) in seconds which is used by the discovery module to timeout a node if a valid heartbeat is not received within the configured ttl value. If not configured, the default value is 60 seconds.</td> </tr> <tr> <td style="text-align: left"><code class="language-plaintext highlighter-rouge">kv.cacertfile</code></td> <td style="text-align: left">Specifies the path to a local file with PEM encoded CA certificates to trust.</td> </tr> <tr> <td style="text-align: left"><code class="language-plaintext highlighter-rouge">kv.certfile</code></td> <td style="text-align: left">Specifies the path to a local file with a PEM encoded certificate. This certificate is used as the client cert for communication with the Key/Value store.</td> </tr> <tr> <td style="text-align: left"><code class="language-plaintext highlighter-rouge">kv.keyfile</code></td> <td style="text-align: left">Specifies the path to a local file with a PEM encoded private key. This private key is used as the client key for communication with the Key/Value store.</td> </tr> <tr> <td style="text-align: left"><code class="language-plaintext highlighter-rouge">kv.path</code></td> <td style="text-align: left">Specifies the path in the Key/Value store. If not configured, the default value is ‘docker/nodes’.</td> </tr> </tbody> </table> <h3 id="access-authorization">Access authorization</h3> <p>Docker’s access authorization can be extended by authorization plugins that your organization can purchase or build themselves. You can install one or more authorization plugins when you start the Docker <code class="language-plaintext highlighter-rouge">daemon</code> using the <code class="language-plaintext highlighter-rouge">--authorization-plugin=PLUGIN_ID</code> option.</p> <div class="highlight"><pre class="highlight" data-language="">$ sudo dockerd --authorization-plugin=plugin1 --authorization-plugin=plugin2,...
</pre></div> <p>The <code class="language-plaintext highlighter-rouge">PLUGIN_ID</code> value is either the plugin’s name or a path to its specification file. The plugin’s implementation determines whether you can specify a name or path. Consult with your Docker administrator to get information about the plugins available to you.</p> <p>Once a plugin is installed, requests made to the <code class="language-plaintext highlighter-rouge">daemon</code> through the command line or Docker’s Engine API are allowed or denied by the plugin. If you have multiple plugins installed, each plugin, in order, must allow the request for it to complete.</p> <p>For information about how to create an authorization plugin, refer to the <a href="../../../extend/plugins_authorization/index">authorization plugin</a> section.</p> <h3 id="daemon-user-namespace-options">Daemon user namespace options</h3> <p>The Linux kernel <a href="https://man7.org/linux/man-pages/man7/user_namespaces.7.html">user namespace support</a> provides additional security by enabling a process, and therefore a container, to have a unique range of user and group IDs which are outside the traditional user and group range utilized by the host system. Potentially the most important security improvement is that, by default, container processes running as the <code class="language-plaintext highlighter-rouge">root</code> user will have expected administrative privilege (with some restrictions) inside the container but will effectively be mapped to an unprivileged <code class="language-plaintext highlighter-rouge">uid</code> on the host.</p> <p>For details about how to use this feature, as well as limitations, see <a href="../../../security/userns-remap/index">Isolate containers with a user namespace</a>.</p> <h3 id="miscellaneous-options">Miscellaneous options</h3> <p>IP masquerading uses address translation to allow containers without a public IP to talk to other machines on the Internet. This may interfere with some network topologies and can be disabled with <code class="language-plaintext highlighter-rouge">--ip-masq=false</code>.</p> <p>Docker supports softlinks for the Docker data directory (<code class="language-plaintext highlighter-rouge">/var/lib/docker</code>) and for <code class="language-plaintext highlighter-rouge">/var/lib/docker/tmp</code>. The <code class="language-plaintext highlighter-rouge">DOCKER_TMPDIR</code> and the data directory can be set like this:</p> <div class="highlight"><pre class="highlight" data-language="">$ DOCKER_TMPDIR=/mnt/disk2/tmp /usr/local/bin/dockerd --data-root /var/lib/docker -H unix:// &gt; /var/lib/docker-machine/docker.log 2&gt;&amp;1
</pre></div> <p>or</p> <div class="highlight"><pre class="highlight" data-language="">$ export DOCKER_TMPDIR=/mnt/disk2/tmp
$ /usr/local/bin/dockerd --data-root /var/lib/docker -H unix:// &gt; /var/lib/docker-machine/docker.log 2&gt;&amp;1
</pre></div> <h4 id="default-cgroup-parent">Default cgroup parent</h4> <p>The <code class="language-plaintext highlighter-rouge">--cgroup-parent</code> option allows you to set the default cgroup parent to use for containers. If this option is not set, it defaults to <code class="language-plaintext highlighter-rouge">/docker</code> for fs cgroup driver and <code class="language-plaintext highlighter-rouge">system.slice</code> for systemd cgroup driver.</p> <p>If the cgroup has a leading forward slash (<code class="language-plaintext highlighter-rouge">/</code>), the cgroup is created under the root cgroup, otherwise the cgroup is created under the daemon cgroup.</p> <p>Assuming the daemon is running in cgroup <code class="language-plaintext highlighter-rouge">daemoncgroup</code>, <code class="language-plaintext highlighter-rouge">--cgroup-parent=/foobar</code> creates a cgroup in <code class="language-plaintext highlighter-rouge">/sys/fs/cgroup/memory/foobar</code>, whereas using <code class="language-plaintext highlighter-rouge">--cgroup-parent=foobar</code> creates the cgroup in <code class="language-plaintext highlighter-rouge">/sys/fs/cgroup/memory/daemoncgroup/foobar</code></p> <p>The systemd cgroup driver has different rules for <code class="language-plaintext highlighter-rouge">--cgroup-parent</code>. Systemd represents hierarchy by slice and the name of the slice encodes the location in the tree. So <code class="language-plaintext highlighter-rouge">--cgroup-parent</code> for systemd cgroups should be a slice name. A name can consist of a dash-separated series of names, which describes the path to the slice from the root slice. For example, <code class="language-plaintext highlighter-rouge">--cgroup-parent=user-a-b.slice</code> means the memory cgroup for the container is created in <code class="language-plaintext highlighter-rouge">/sys/fs/cgroup/memory/user.slice/user-a.slice/user-a-b.slice/docker-&lt;id&gt;.scope</code>.</p> <p>This setting can also be set per container, using the <code class="language-plaintext highlighter-rouge">--cgroup-parent</code> option on <code class="language-plaintext highlighter-rouge">docker create</code> and <code class="language-plaintext highlighter-rouge">docker run</code>, and takes precedence over the <code class="language-plaintext highlighter-rouge">--cgroup-parent</code> option on the daemon.</p> <h4 id="daemon-metrics">Daemon metrics</h4> <p>The <code class="language-plaintext highlighter-rouge">--metrics-addr</code> option takes a tcp address to serve the metrics API. This feature is still experimental, therefore, the daemon must be running in experimental mode for this feature to work.</p> <p>To serve the metrics API on <code class="language-plaintext highlighter-rouge">localhost:9323</code> you would specify <code class="language-plaintext highlighter-rouge">--metrics-addr 127.0.0.1:9323</code>, allowing you to make requests on the API at <code class="language-plaintext highlighter-rouge">127.0.0.1:9323/metrics</code> to receive metrics in the <a href="https://prometheus.io/docs/instrumenting/exposition_formats/">prometheus</a> format.</p> <p>Port <code class="language-plaintext highlighter-rouge">9323</code> is the <a href="https://github.com/prometheus/prometheus/wiki/Default-port-allocations">default port associated with Docker metrics</a> to avoid collisions with other prometheus exporters and services.</p> <p>If you are running a prometheus server you can add this address to your scrape configs to have prometheus collect metrics on Docker. For more information on prometheus refer to the <a href="https://prometheus.io/">prometheus website</a>.</p> <div class="highlight"><pre class="highlight" data-language="">scrape_configs:
  - job_name: 'docker'
    static_configs:
      - targets: ['127.0.0.1:9323']
</pre></div> <p>Please note that this feature is still marked as experimental as metrics and metric names could change while this feature is still in experimental. Please provide feedback on what you would like to see collected in the API.</p> <h4 id="node-generic-resources">Node Generic Resources</h4> <p>The <code class="language-plaintext highlighter-rouge">--node-generic-resources</code> option takes a list of key-value pair (<code class="language-plaintext highlighter-rouge">key=value</code>) that allows you to advertise user defined resources in a swarm cluster.</p> <p>The current expected use case is to advertise NVIDIA GPUs so that services requesting <code class="language-plaintext highlighter-rouge">NVIDIA-GPU=[0-16]</code> can land on a node that has enough GPUs for the task to run.</p> <p>Example of usage:</p> <div class="highlight"><pre class="highlight" data-language="">{
  "node-generic-resources": [
    "NVIDIA-GPU=UUID1",
    "NVIDIA-GPU=UUID2"
  ]
}
</pre></div> <h3 id="daemon-configuration-file">Daemon configuration file</h3> <p>The <code class="language-plaintext highlighter-rouge">--config-file</code> option allows you to set any configuration option for the daemon in a JSON format. This file uses the same flag names as keys, except for flags that allow several entries, where it uses the plural of the flag name, e.g., <code class="language-plaintext highlighter-rouge">labels</code> for the <code class="language-plaintext highlighter-rouge">label</code> flag.</p> <p>The options set in the configuration file must not conflict with options set via flags. The docker daemon fails to start if an option is duplicated between the file and the flags, regardless their value. We do this to avoid silently ignore changes introduced in configuration reloads. For example, the daemon fails to start if you set daemon labels in the configuration file and also set daemon labels via the <code class="language-plaintext highlighter-rouge">--label</code> flag. Options that are not present in the file are ignored when the daemon starts.</p> <h5 id="on-linux">On Linux</h5> <p>The default location of the configuration file on Linux is <code class="language-plaintext highlighter-rouge">/etc/docker/daemon.json</code>. The <code class="language-plaintext highlighter-rouge">--config-file</code> flag can be used to specify a non-default location.</p> <p>This is a full example of the allowed configuration options on Linux:</p> <div class="highlight"><pre class="highlight" data-language="">{
  "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": ""
}
</pre></div> <blockquote> <p><strong>Note:</strong></p> <p>You cannot set options in <code class="language-plaintext highlighter-rouge">daemon.json</code> that have already been set on daemon startup as a flag. On systems that use <code class="language-plaintext highlighter-rouge">systemd</code> to start the Docker daemon, <code class="language-plaintext highlighter-rouge">-H</code> is already set, so you cannot use the <code class="language-plaintext highlighter-rouge">hosts</code> key in <code class="language-plaintext highlighter-rouge">daemon.json</code> to add listening addresses. See <a href="https://docs.docker.com/config/daemon/systemd/#custom-docker-daemon-options">“custom Docker daemon options”</a> for how to accomplish this task with a systemd drop-in file.</p> </blockquote> <h5 id="on-windows">On Windows</h5> <p>The default location of the configuration file on Windows is <code class="language-plaintext highlighter-rouge">%programdata%\docker\config\daemon.json</code>. The <code class="language-plaintext highlighter-rouge">--config-file</code> flag can be used to specify a non-default location.</p> <p>This is a full example of the allowed configuration options on Windows:</p> <div class="highlight"><pre class="highlight" data-language="">{
  "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-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
}
</pre></div> <h4 id="feature-options">Feature options</h4> <p>The optional field <code class="language-plaintext highlighter-rouge">features</code> in <code class="language-plaintext highlighter-rouge">daemon.json</code> allows users to enable or disable specific daemon features. For example, <code class="language-plaintext highlighter-rouge">{"features":{"buildkit": true}}</code> enables <code class="language-plaintext highlighter-rouge">buildkit</code> as the default docker image builder.</p> <p>The list of currently supported feature options:</p> <ul> <li>
<code class="language-plaintext highlighter-rouge">buildkit</code>: It enables <code class="language-plaintext highlighter-rouge">buildkit</code> as default builder when set to <code class="language-plaintext highlighter-rouge">true</code> or disables it by <code class="language-plaintext highlighter-rouge">false</code>. Note that if this option is not explicitly set in the daemon config file, then it is up to the cli to determine which builder to invoke.</li> </ul> <h4 id="configuration-reload-behavior">Configuration reload behavior</h4> <p>Some options can be reconfigured when the daemon is running without requiring to restart the process. We use the <code class="language-plaintext highlighter-rouge">SIGHUP</code> signal in Linux to reload, and a global event in Windows with the key <code class="language-plaintext highlighter-rouge">Global\docker-daemon-config-$PID</code>. The options can be modified in the configuration file but still will check for conflicts with the provided flags. The daemon fails to reconfigure itself if there are conflicts, but it won’t stop execution.</p> <p>The list of currently supported options that can be reconfigured is this:</p> <ul> <li>
<code class="language-plaintext highlighter-rouge">debug</code>: it changes the daemon to debug mode when set to true.</li> <li>
<code class="language-plaintext highlighter-rouge">cluster-store</code>: it reloads the discovery store with the new address.</li> <li>
<code class="language-plaintext highlighter-rouge">cluster-store-opts</code>: it uses the new options to reload the discovery store.</li> <li>
<code class="language-plaintext highlighter-rouge">cluster-advertise</code>: it modifies the address advertised after reloading.</li> <li>
<code class="language-plaintext highlighter-rouge">labels</code>: it replaces the daemon labels with a new set of labels.</li> <li>
<code class="language-plaintext highlighter-rouge">live-restore</code>: Enables <a href="https://docs.docker.com/config/containers/live-restore/">keeping containers alive during daemon downtime</a>.</li> <li>
<code class="language-plaintext highlighter-rouge">max-concurrent-downloads</code>: it updates the max concurrent downloads for each pull.</li> <li>
<code class="language-plaintext highlighter-rouge">max-concurrent-uploads</code>: it updates the max concurrent uploads for each push.</li> <li>
<code class="language-plaintext highlighter-rouge">max-download-attempts</code>: it updates the max download attempts for each pull.</li> <li>
<code class="language-plaintext highlighter-rouge">default-runtime</code>: it updates the runtime to be used if not is specified at container creation. It defaults to “default” which is the runtime shipped with the official docker packages.</li> <li>
<code class="language-plaintext highlighter-rouge">runtimes</code>: it updates the list of available OCI runtimes that can be used to run containers.</li> <li>
<code class="language-plaintext highlighter-rouge">authorization-plugin</code>: it specifies the authorization plugins to use.</li> <li>
<code class="language-plaintext highlighter-rouge">allow-nondistributable-artifacts</code>: Replaces the set of registries to which the daemon will push nondistributable artifacts with a new set of registries.</li> <li>
<code class="language-plaintext highlighter-rouge">insecure-registries</code>: it replaces the daemon insecure registries with a new set of insecure registries. If some existing insecure registries in daemon’s configuration are not in newly reloaded insecure registries, these existing ones will be removed from daemon’s config.</li> <li>
<code class="language-plaintext highlighter-rouge">registry-mirrors</code>: it replaces the daemon registry mirrors with a new set of registry mirrors. If some existing registry mirrors in daemon’s configuration are not in newly reloaded registry mirrors, these existing ones will be removed from daemon’s config.</li> <li>
<code class="language-plaintext highlighter-rouge">shutdown-timeout</code>: it replaces the daemon’s existing configuration timeout with a new timeout for shutting down all containers.</li> <li>
<code class="language-plaintext highlighter-rouge">features</code>: it explicitly enables or disables specific features.</li> </ul> <p>Updating and reloading the cluster configurations such as <code class="language-plaintext highlighter-rouge">--cluster-store</code>, <code class="language-plaintext highlighter-rouge">--cluster-advertise</code> and <code class="language-plaintext highlighter-rouge">--cluster-store-opts</code> will take effect only if these configurations were not previously configured. If <code class="language-plaintext highlighter-rouge">--cluster-store</code> has been provided in flags and <code class="language-plaintext highlighter-rouge">cluster-advertise</code> not, <code class="language-plaintext highlighter-rouge">cluster-advertise</code> can be added in the configuration file without accompanied by <code class="language-plaintext highlighter-rouge">--cluster-store</code>. Configuration reload will log a warning message if it detects a change in previously configured cluster configurations.</p> <h3 id="run-multiple-daemons">Run multiple daemons</h3> <blockquote> <p><strong>Note:</strong></p> <p>Running multiple daemons on a single host is considered as “experimental”. The user should be aware of unsolved problems. This solution may not work properly in some cases. Solutions are currently under development and will be delivered in the near future.</p> </blockquote> <p>This section describes how to run multiple Docker daemons on a single host. To run multiple daemons, you must configure each daemon so that it does not conflict with other daemons on the same host. You can set these options either by providing them as flags, or by using a <a href="#daemon-configuration-file">daemon configuration file</a>.</p> <p>The following daemon options must be configured for each daemon:</p> <div class="highlight"><pre class="highlight" data-language="">-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
</pre></div> <p>When your daemons use different values for these flags, you can run them on the same host without any problems. It is very important to properly understand the meaning of those options and to use them correctly.</p> <ul> <li>The <code class="language-plaintext highlighter-rouge">-b, --bridge=</code> flag is set to <code class="language-plaintext highlighter-rouge">docker0</code> as default bridge network. It is created automatically when you install Docker. If you are not using the default, you must create and configure the bridge manually or just set it to ‘none’: <code class="language-plaintext highlighter-rouge">--bridge=none</code>
</li> <li>
<code class="language-plaintext highlighter-rouge">--exec-root</code> is the path where the container state is stored. The default value is <code class="language-plaintext highlighter-rouge">/var/run/docker</code>. Specify the path for your running daemon here.</li> <li>
<code class="language-plaintext highlighter-rouge">--data-root</code> is the path where persisted data such as images, volumes, and cluster state are stored. The default value is <code class="language-plaintext highlighter-rouge">/var/lib/docker</code>. To avoid any conflict with other daemons, set this parameter separately for each daemon.</li> <li>
<code class="language-plaintext highlighter-rouge">-p, --pidfile=/var/run/docker.pid</code> is the path where the process ID of the daemon is stored. Specify the path for your pid file here.</li> <li>
<code class="language-plaintext highlighter-rouge">--host=[]</code> specifies where the Docker daemon will listen for client connections. If unspecified, it defaults to <code class="language-plaintext highlighter-rouge">/var/run/docker.sock</code>.</li> <li>
<code class="language-plaintext highlighter-rouge">--iptables=false</code> prevents the Docker daemon from adding iptables rules. If multiple daemons manage iptables rules, they may overwrite rules set by another daemon. Be aware that disabling this option requires you to manually add iptables rules to expose container ports. If you prevent Docker from adding iptables rules, Docker will also not add IP masquerading rules, even if you set <code class="language-plaintext highlighter-rouge">--ip-masq</code> to <code class="language-plaintext highlighter-rouge">true</code>. Without IP masquerading rules, Docker containers will not be able to connect to external hosts or the internet when using network other than default bridge.</li> <li>
<code class="language-plaintext highlighter-rouge">--config-file=/etc/docker/daemon.json</code> is the path where configuration file is stored. You can use it instead of daemon flags. Specify the path for each daemon.</li> <li>
<code class="language-plaintext highlighter-rouge">--tls*</code> Docker daemon supports <code class="language-plaintext highlighter-rouge">--tlsverify</code> mode that enforces encrypted and authenticated remote connections. The <code class="language-plaintext highlighter-rouge">--tls*</code> options enable use of specific certificates for individual daemons.</li> </ul> <p>Example script for a separate “bootstrap” instance of the Docker daemon without network:</p> <div class="highlight"><pre class="highlight" data-language="">$ 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
</pre></div> 
<p><a href="https://docs.docker.com/search/?q=container">container</a>, <a href="https://docs.docker.com/search/?q=daemon">daemon</a>, <a href="https://docs.docker.com/search/?q=runtime">runtime</a></p>
<div class="_attribution">
  <p class="_attribution-p">
    &copy; 2019 Docker, Inc.<br>Licensed under the Apache License, Version 2.0.<br>Docker and the Docker logo are trademarks or registered trademarks of Docker, Inc. in the United States and/or other countries.<br>Docker, Inc. and other parties may also have trademark rights in other terms used herein.<br>
    <a href="https://docs.docker.com/engine/reference/commandline/dockerd/" class="_attribution-link">https://docs.docker.com/engine/reference/commandline/dockerd/</a>
  </p>
</div>