github.com/brahmaroutu/docker@v1.2.1-0.20160809185609-eb28dde01f16/docs/reference/commandline/dockerd.md (about)

     1  <!--[metadata]>
     2  +++
     3  title = "dockerd"
     4  aliases = ["/engine/reference/commandline/daemon/"]
     5  description = "The daemon command description and usage"
     6  keywords = ["container, daemon, runtime"]
     7  [menu.main]
     8  parent = "smn_cli"
     9  weight = -1
    10  +++
    11  <![end-metadata]-->
    12  
    13  # daemon
    14  
    15  ```markdown
    16  Usage: dockerd [OPTIONS]
    17  
    18  A self-sufficient runtime for containers.
    19  
    20  Options:
    21  
    22        --add-runtime=[]                       Register an additional OCI compatible runtime
    23        --api-cors-header                      Set CORS headers in the remote API
    24        --authorization-plugin=[]              Authorization plugins to load
    25        -b, --bridge                           Attach containers to a network bridge
    26        --bip                                  Specify network bridge IP
    27        --cgroup-parent                        Set parent cgroup for all containers
    28        --cluster-advertise                    Address or interface name to advertise
    29        --cluster-store                        URL of the distributed storage backend
    30        --cluster-store-opt=map[]              Set cluster store options
    31        --config-file=/etc/docker/daemon.json  Daemon configuration file
    32        --containerd                           Path to containerd socket
    33        -D, --debug                            Enable debug mode
    34        --default-gateway                      Container default gateway IPv4 address
    35        --default-gateway-v6                   Container default gateway IPv6 address
    36        --default-runtime=runc                 Default OCI runtime for containers
    37        --default-ulimit=[]                    Default ulimits for containers
    38        --disable-legacy-registry              Disable contacting legacy registries
    39        --dns=[]                               DNS server to use
    40        --dns-opt=[]                           DNS options to use
    41        --dns-search=[]                        DNS search domains to use
    42        --exec-opt=[]                          Runtime execution options
    43        --exec-root=/var/run/docker            Root directory for execution state files
    44        --fixed-cidr                           IPv4 subnet for fixed IPs
    45        --fixed-cidr-v6                        IPv6 subnet for fixed IPs
    46        -G, --group=docker                     Group for the unix socket
    47        -g, --graph=/var/lib/docker            Root of the Docker runtime
    48        -H, --host=[]                          Daemon socket(s) to connect to
    49        --help                                 Print usage
    50        --icc=true                             Enable inter-container communication
    51        --insecure-registry=[]                 Enable insecure registry communication
    52        --ip=0.0.0.0                           Default IP when binding container ports
    53        --ip-forward=true                      Enable net.ipv4.ip_forward
    54        --ip-masq=true                         Enable IP masquerading
    55        --iptables=true                        Enable addition of iptables rules
    56        --ipv6                                 Enable IPv6 networking
    57        -l, --log-level=info                   Set the logging level
    58        --label=[]                             Set key=value labels to the daemon
    59        --live-restore                         Enables keeping containers alive during daemon downtime
    60        --log-driver=json-file                 Default driver for container logs
    61        --log-opt=map[]                        Default log driver options for containers
    62        --max-concurrent-downloads=3           Set the max concurrent downloads for each pull
    63        --max-concurrent-uploads=5             Set the max concurrent uploads for each push
    64        --mtu                                  Set the containers network MTU
    65        --oom-score-adjust=-500                Set the oom_score_adj for the daemon
    66        -p, --pidfile=/var/run/docker.pid      Path to use for daemon PID file
    67        --raw-logs                             Full timestamps without ANSI coloring
    68        --registry-mirror=[]                   Preferred Docker registry mirror
    69        -s, --storage-driver                   Storage driver to use
    70        --selinux-enabled                      Enable selinux support
    71        --storage-opt=[]                       Storage driver options
    72        --swarm-default-advertise-addr         Set default address or interface for swarm advertised address
    73        --tls                                  Use TLS; implied by --tlsverify
    74        --tlscacert=~/.docker/ca.pem           Trust certs signed only by this CA
    75        --tlscert=~/.docker/cert.pem           Path to TLS certificate file
    76        --tlskey=~/.docker/key.pem             Path to TLS key file
    77        --tlsverify                            Use TLS and verify the remote
    78        --userland-proxy=true                  Use userland proxy for loopback traffic
    79        --userns-remap                         User/Group setting for user namespaces
    80        -v, --version                          Print version information and quit
    81  ```
    82  
    83  Options with [] may be specified multiple times.
    84  
    85  dockerd is the persistent process that manages containers. Docker
    86  uses different binaries for the daemon and client. To run the daemon you
    87  type `dockerd`.
    88  
    89  To run the daemon with debug output, use `dockerd -D`.
    90  
    91  ## Daemon socket option
    92  
    93  The Docker daemon can listen for [Docker Remote API](../api/docker_remote_api.md)
    94  requests via three different types of Socket: `unix`, `tcp`, and `fd`.
    95  
    96  By default, a `unix` domain socket (or IPC socket) is created at
    97  `/var/run/docker.sock`, requiring either `root` permission, or `docker` group
    98  membership.
    99  
   100  If you need to access the Docker daemon remotely, you need to enable the `tcp`
   101  Socket. Beware that the default setup provides un-encrypted and
   102  un-authenticated direct access to the Docker daemon - and should be secured
   103  either using the [built in HTTPS encrypted socket](../../security/https.md), or by
   104  putting a secure web proxy in front of it. You can listen on port `2375` on all
   105  network interfaces with `-H tcp://0.0.0.0:2375`, or on a particular network
   106  interface using its IP address: `-H tcp://192.168.59.103:2375`. It is
   107  conventional to use port `2375` for un-encrypted, and port `2376` for encrypted
   108  communication with the daemon.
   109  
   110  > **Note:**
   111  > If you're using an HTTPS encrypted socket, keep in mind that only
   112  > TLS1.0 and greater are supported. Protocols SSLv3 and under are not
   113  > supported anymore for security reasons.
   114  
   115  On Systemd based systems, you can communicate with the daemon via
   116  [Systemd socket activation](http://0pointer.de/blog/projects/socket-activation.html),
   117  use `dockerd -H fd://`. Using `fd://` will work perfectly for most setups but
   118  you can also specify individual sockets: `dockerd -H fd://3`. If the
   119  specified socket activated files aren't found, then Docker will exit. You can
   120  find examples of using Systemd socket activation with Docker and Systemd in the
   121  [Docker source tree](https://github.com/docker/docker/tree/master/contrib/init/systemd/).
   122  
   123  You can configure the Docker daemon to listen to multiple sockets at the same
   124  time using multiple `-H` options:
   125  
   126      # listen using the default unix socket, and on 2 specific IP addresses on this host.
   127      dockerd -H unix:///var/run/docker.sock -H tcp://192.168.59.106 -H tcp://10.10.10.2
   128  
   129  The Docker client will honor the `DOCKER_HOST` environment variable to set the
   130  `-H` flag for the client.
   131  
   132      $ docker -H tcp://0.0.0.0:2375 ps
   133      # or
   134      $ export DOCKER_HOST="tcp://0.0.0.0:2375"
   135      $ docker ps
   136      # both are equal
   137  
   138  Setting the `DOCKER_TLS_VERIFY` environment variable to any value other than
   139  the empty string is equivalent to setting the `--tlsverify` flag. The following
   140  are equivalent:
   141  
   142      $ docker --tlsverify ps
   143      # or
   144      $ export DOCKER_TLS_VERIFY=1
   145      $ docker ps
   146  
   147  The Docker client will honor the `HTTP_PROXY`, `HTTPS_PROXY`, and `NO_PROXY`
   148  environment variables (or the lowercase versions thereof). `HTTPS_PROXY` takes
   149  precedence over `HTTP_PROXY`.
   150  
   151  ### Bind Docker to another host/port or a Unix socket
   152  
   153  > **Warning**:
   154  > Changing the default `docker` daemon binding to a
   155  > TCP port or Unix *docker* user group will increase your security risks
   156  > by allowing non-root users to gain *root* access on the host. Make sure
   157  > you control access to `docker`. If you are binding
   158  > to a TCP port, anyone with access to that port has full Docker access;
   159  > so it is not advisable on an open network.
   160  
   161  With `-H` it is possible to make the Docker daemon to listen on a
   162  specific IP and port. By default, it will listen on
   163  `unix:///var/run/docker.sock` to allow only local connections by the
   164  *root* user. You *could* set it to `0.0.0.0:2375` or a specific host IP
   165  to give access to everybody, but that is **not recommended** because
   166  then it is trivial for someone to gain root access to the host where the
   167  daemon is running.
   168  
   169  Similarly, the Docker client can use `-H` to connect to a custom port.
   170  The Docker client will default to connecting to `unix:///var/run/docker.sock`
   171  on Linux, and `tcp://127.0.0.1:2376` on Windows.
   172  
   173  `-H` accepts host and port assignment in the following format:
   174  
   175      tcp://[host]:[port][path] or unix://path
   176  
   177  For example:
   178  
   179  -   `tcp://` -> TCP connection to `127.0.0.1` on either port `2376` when TLS encryption
   180      is on, or port `2375` when communication is in plain text.
   181  -   `tcp://host:2375` -> TCP connection on
   182      host:2375
   183  -   `tcp://host:2375/path` -> TCP connection on
   184      host:2375 and prepend path to all requests
   185  -   `unix://path/to/socket` -> Unix socket located
   186      at `path/to/socket`
   187  
   188  `-H`, when empty, will default to the same value as
   189  when no `-H` was passed in.
   190  
   191  `-H` also accepts short form for TCP bindings:
   192  
   193      `host:` or `host:port` or `:port`
   194  
   195  Run Docker in daemon mode:
   196  
   197      $ sudo <path to>/dockerd -H 0.0.0.0:5555 &
   198  
   199  Download an `ubuntu` image:
   200  
   201      $ docker -H :5555 pull ubuntu
   202  
   203  You can use multiple `-H`, for example, if you want to listen on both
   204  TCP and a Unix socket
   205  
   206      # Run docker in daemon mode
   207      $ sudo <path to>/dockerd -H tcp://127.0.0.1:2375 -H unix:///var/run/docker.sock &
   208      # Download an ubuntu image, use default Unix socket
   209      $ docker pull ubuntu
   210      # OR use the TCP port
   211      $ docker -H tcp://127.0.0.1:2375 pull ubuntu
   212  
   213  ### Daemon storage-driver option
   214  
   215  The Docker daemon has support for several different image layer storage
   216  drivers: `aufs`, `devicemapper`, `btrfs`, `zfs`, `overlay` and `overlay2`.
   217  
   218  The `aufs` driver is the oldest, but is based on a Linux kernel patch-set that
   219  is unlikely to be merged into the main kernel. These are also known to cause
   220  some serious kernel crashes. However, `aufs` allows containers to share
   221  executable and shared library memory, so is a useful choice when running
   222  thousands of containers with the same program or libraries.
   223  
   224  The `devicemapper` driver uses thin provisioning and Copy on Write (CoW)
   225  snapshots. For each devicemapper graph location – typically
   226  `/var/lib/docker/devicemapper` – a thin pool is created based on two block
   227  devices, one for data and one for metadata. By default, these block devices
   228  are created automatically by using loopback mounts of automatically created
   229  sparse files. Refer to [Storage driver options](#storage-driver-options) below
   230  for a way how to customize this setup.
   231  [~jpetazzo/Resizing Docker containers with the Device Mapper plugin](http://jpetazzo.github.io/2014/01/29/docker-device-mapper-resize/)
   232  article explains how to tune your existing setup without the use of options.
   233  
   234  The `btrfs` driver is very fast for `docker build` - but like `devicemapper`
   235  does not share executable memory between devices. Use
   236  `dockerd -s btrfs -g /mnt/btrfs_partition`.
   237  
   238  The `zfs` driver is probably not as fast as `btrfs` but has a longer track record
   239  on stability. Thanks to `Single Copy ARC` shared blocks between clones will be
   240  cached only once. Use `dockerd -s zfs`. To select a different zfs filesystem
   241  set `zfs.fsname` option as described in [Storage driver options](#storage-driver-options).
   242  
   243  The `overlay` is a very fast union filesystem. It is now merged in the main
   244  Linux kernel as of [3.18.0](https://lkml.org/lkml/2014/10/26/137). `overlay`
   245  also supports page cache sharing, this means multiple containers accessing
   246  the same file can share a single page cache entry (or entries), it makes
   247  `overlay` as efficient with memory as `aufs` driver. Call
   248  `dockerd -s overlay` to use it.
   249  
   250  > **Note:**
   251  > As promising as `overlay` is, the feature is still quite young and should not
   252  > be used in production. Most notably, using `overlay` can cause excessive
   253  > inode consumption (especially as the number of images grows), as well as
   254  > being incompatible with the use of RPMs.
   255  
   256  The `overlay2` uses the same fast union filesystem but takes advantage of
   257  [additional features](https://lkml.org/lkml/2015/2/11/106) added in Linux
   258  kernel 4.0 to avoid excessive inode consumption. Call `dockerd -s overlay2`
   259  to use it.
   260  
   261  > **Note:**
   262  > Both `overlay` and `overlay2` are currently unsupported on `btrfs` or any
   263  > Copy on Write filesystem and should only be used over `ext4` partitions.
   264  
   265  ### Storage driver options
   266  
   267  Particular storage-driver can be configured with options specified with
   268  `--storage-opt` flags. Options for `devicemapper` are prefixed with `dm`,
   269  options for `zfs` start with `zfs` and options for `btrfs` start with `btrfs`.
   270  
   271  #### Devicemapper options
   272  
   273  *  `dm.thinpooldev`
   274  
   275       Specifies a custom block storage device to use for the thin pool.
   276  
   277       If using a block device for device mapper storage, it is best to use `lvm`
   278       to create and manage the thin-pool volume. This volume is then handed to Docker
   279       to exclusively create snapshot volumes needed for images and containers.
   280  
   281       Managing the thin-pool outside of Engine makes for the most feature-rich
   282       method of having Docker utilize device mapper thin provisioning as the
   283       backing storage for Docker containers. The highlights of the lvm-based
   284       thin-pool management feature include: automatic or interactive thin-pool
   285       resize support, dynamically changing thin-pool features, automatic thinp
   286       metadata checking when lvm activates the thin-pool, etc.
   287  
   288       As a fallback if no thin pool is provided, loopback files are
   289       created. Loopback is very slow, but can be used without any
   290       pre-configuration of storage. It is strongly recommended that you do
   291       not use loopback in production. Ensure your Engine daemon has a
   292       `--storage-opt dm.thinpooldev` argument provided.
   293  
   294       Example use:
   295  
   296          $ dockerd \
   297                --storage-opt dm.thinpooldev=/dev/mapper/thin-pool
   298  
   299  *  `dm.basesize`
   300  
   301      Specifies the size to use when creating the base device, which limits the
   302      size of images and containers. The default value is 10G. Note, thin devices
   303      are inherently "sparse", so a 10G device which is mostly empty doesn't use
   304      10 GB of space on the pool. However, the filesystem will use more space for
   305      the empty case the larger the device is.
   306  
   307      The base device size can be increased at daemon restart which will allow
   308      all future images and containers (based on those new images) to be of the
   309      new base device size.
   310  
   311      Example use:
   312  
   313          $ dockerd --storage-opt dm.basesize=50G
   314  
   315      This will increase the base device size to 50G. The Docker daemon will throw an
   316      error if existing base device size is larger than 50G. A user can use
   317      this option to expand the base device size however shrinking is not permitted.
   318  
   319      This value affects the system-wide "base" empty filesystem
   320      that may already be initialized and inherited by pulled images. Typically,
   321      a change to this value requires additional steps to take effect:
   322  
   323          $ sudo service docker stop
   324          $ sudo rm -rf /var/lib/docker
   325          $ sudo service docker start
   326  
   327      Example use:
   328  
   329          $ dockerd --storage-opt dm.basesize=20G
   330  
   331  *  `dm.loopdatasize`
   332  
   333      > **Note**:
   334  	> This option configures devicemapper loopback, which should not
   335  	> be used in production.
   336  
   337      Specifies the size to use when creating the loopback file for the
   338      "data" device which is used for the thin pool. The default size is
   339      100G. The file is sparse, so it will not initially take up this
   340      much space.
   341  
   342      Example use:
   343  
   344          $ dockerd --storage-opt dm.loopdatasize=200G
   345  
   346  *  `dm.loopmetadatasize`
   347  
   348      > **Note**:
   349      > This option configures devicemapper loopback, which should not
   350      > be used in production.
   351  
   352      Specifies the size to use when creating the loopback file for the
   353      "metadata" device which is used for the thin pool. The default size
   354      is 2G. The file is sparse, so it will not initially take up
   355      this much space.
   356  
   357      Example use:
   358  
   359          $ dockerd --storage-opt dm.loopmetadatasize=4G
   360  
   361  *  `dm.fs`
   362  
   363      Specifies the filesystem type to use for the base device. The supported
   364      options are "ext4" and "xfs". The default is "xfs"
   365  
   366      Example use:
   367  
   368          $ dockerd --storage-opt dm.fs=ext4
   369  
   370  *  `dm.mkfsarg`
   371  
   372      Specifies extra mkfs arguments to be used when creating the base device.
   373  
   374      Example use:
   375  
   376          $ dockerd --storage-opt "dm.mkfsarg=-O ^has_journal"
   377  
   378  *  `dm.mountopt`
   379  
   380      Specifies extra mount options used when mounting the thin devices.
   381  
   382      Example use:
   383  
   384          $ dockerd --storage-opt dm.mountopt=nodiscard
   385  
   386  *  `dm.datadev`
   387  
   388      (Deprecated, use `dm.thinpooldev`)
   389  
   390      Specifies a custom blockdevice to use for data for the thin pool.
   391  
   392      If using a block device for device mapper storage, ideally both datadev and
   393      metadatadev should be specified to completely avoid using the loopback
   394      device.
   395  
   396      Example use:
   397  
   398          $ dockerd \
   399                --storage-opt dm.datadev=/dev/sdb1 \
   400                --storage-opt dm.metadatadev=/dev/sdc1
   401  
   402  *  `dm.metadatadev`
   403  
   404      (Deprecated, use `dm.thinpooldev`)
   405  
   406      Specifies a custom blockdevice to use for metadata for the thin pool.
   407  
   408      For best performance the metadata should be on a different spindle than the
   409      data, or even better on an SSD.
   410  
   411      If setting up a new metadata pool it is required to be valid. This can be
   412      achieved by zeroing the first 4k to indicate empty metadata, like this:
   413  
   414          $ dd if=/dev/zero of=$metadata_dev bs=4096 count=1
   415  
   416      Example use:
   417  
   418          $ dockerd \
   419                --storage-opt dm.datadev=/dev/sdb1 \
   420                --storage-opt dm.metadatadev=/dev/sdc1
   421  
   422  *  `dm.blocksize`
   423  
   424      Specifies a custom blocksize to use for the thin pool. The default
   425      blocksize is 64K.
   426  
   427      Example use:
   428  
   429          $ dockerd --storage-opt dm.blocksize=512K
   430  
   431  *  `dm.blkdiscard`
   432  
   433      Enables or disables the use of blkdiscard when removing devicemapper
   434      devices. This is enabled by default (only) if using loopback devices and is
   435      required to resparsify the loopback file on image/container removal.
   436  
   437      Disabling this on loopback can lead to *much* faster container removal
   438      times, but will make the space used in `/var/lib/docker` directory not be
   439      returned to the system for other use when containers are removed.
   440  
   441      Example use:
   442  
   443          $ dockerd --storage-opt dm.blkdiscard=false
   444  
   445  *  `dm.override_udev_sync_check`
   446  
   447      Overrides the `udev` synchronization checks between `devicemapper` and `udev`.
   448      `udev` is the device manager for the Linux kernel.
   449  
   450      To view the `udev` sync support of a Docker daemon that is using the
   451      `devicemapper` driver, run:
   452  
   453          $ docker info
   454          [...]
   455          Udev Sync Supported: true
   456          [...]
   457  
   458      When `udev` sync support is `true`, then `devicemapper` and udev can
   459      coordinate the activation and deactivation of devices for containers.
   460  
   461      When `udev` sync support is `false`, a race condition occurs between
   462      the`devicemapper` and `udev` during create and cleanup. The race condition
   463      results in errors and failures. (For information on these failures, see
   464      [docker#4036](https://github.com/docker/docker/issues/4036))
   465  
   466      To allow the `docker` daemon to start, regardless of `udev` sync not being
   467      supported, set `dm.override_udev_sync_check` to true:
   468  
   469          $ dockerd --storage-opt dm.override_udev_sync_check=true
   470  
   471      When this value is `true`, the  `devicemapper` continues and simply warns
   472      you the errors are happening.
   473  
   474      > **Note:**
   475      > The ideal is to pursue a `docker` daemon and environment that does
   476      > support synchronizing with `udev`. For further discussion on this
   477      > topic, see [docker#4036](https://github.com/docker/docker/issues/4036).
   478      > Otherwise, set this flag for migrating existing Docker daemons to
   479      > a daemon with a supported environment.
   480  
   481  *  `dm.use_deferred_removal`
   482  
   483      Enables use of deferred device removal if `libdm` and the kernel driver
   484      support the mechanism.
   485  
   486      Deferred device removal means that if device is busy when devices are
   487      being removed/deactivated, then a deferred removal is scheduled on
   488      device. And devices automatically go away when last user of the device
   489      exits.
   490  
   491      For example, when a container exits, its associated thin device is removed.
   492      If that device has leaked into some other mount namespace and can't be
   493      removed, the container exit still succeeds and this option causes the
   494      system to schedule the device for deferred removal. It does not wait in a
   495      loop trying to remove a busy device.
   496  
   497      Example use:
   498  
   499          $ dockerd --storage-opt dm.use_deferred_removal=true
   500  
   501  *  `dm.use_deferred_deletion`
   502  
   503      Enables use of deferred device deletion for thin pool devices. By default,
   504      thin pool device deletion is synchronous. Before a container is deleted,
   505      the Docker daemon removes any associated devices. If the storage driver
   506      can not remove a device, the container deletion fails and daemon returns.
   507  
   508          Error deleting container: Error response from daemon: Cannot destroy container
   509  
   510      To avoid this failure, enable both deferred device deletion and deferred
   511      device removal on the daemon.
   512  
   513          $ dockerd \
   514                --storage-opt dm.use_deferred_deletion=true \
   515                --storage-opt dm.use_deferred_removal=true
   516  
   517      With these two options enabled, if a device is busy when the driver is
   518      deleting a container, the driver marks the device as deleted. Later, when
   519      the device isn't in use, the driver deletes it.
   520  
   521      In general it should be safe to enable this option by default. It will help
   522      when unintentional leaking of mount point happens across multiple mount
   523      namespaces.
   524  
   525  *  `dm.min_free_space`
   526  
   527      Specifies the min free space percent in a thin pool require for new device
   528      creation to succeed. This check applies to both free data space as well
   529      as free metadata space. Valid values are from 0% - 99%. Value 0% disables
   530      free space checking logic. If user does not specify a value for this option,
   531      the Engine uses a default value of 10%.
   532  
   533      Whenever a new a thin pool device is created (during `docker pull` or during
   534      container creation), the Engine checks if the minimum free space is
   535      available. If sufficient space is unavailable, then device creation fails
   536      and any relevant `docker` operation fails.
   537  
   538      To recover from this error, you must create more free space in the thin pool
   539      to recover from the error. You can create free space by deleting some images
   540      and containers from the thin pool. You can also add more storage to the thin
   541      pool.
   542  
   543      To add more space to a LVM (logical volume management) thin pool, just add
   544      more storage to the volume group container thin pool; this should automatically
   545      resolve any errors. If your configuration uses loop devices, then stop the
   546      Engine daemon, grow the size of loop files and restart the daemon to resolve
   547      the issue.
   548  
   549      Example use:
   550  
   551      ```bash
   552      $ dockerd --storage-opt dm.min_free_space=10%
   553      ```
   554  
   555  #### ZFS options
   556  
   557  * `zfs.fsname`
   558  
   559      Set zfs filesystem under which docker will create its own datasets.
   560      By default docker will pick up the zfs filesystem where docker graph
   561      (`/var/lib/docker`) is located.
   562  
   563      Example use:
   564  
   565          $ dockerd -s zfs --storage-opt zfs.fsname=zroot/docker
   566  
   567  #### Btrfs options
   568  
   569  * `btrfs.min_space`
   570  
   571      Specifies the mininum size to use when creating the subvolume which is used
   572      for containers. If user uses disk quota for btrfs when creating or running
   573      a container with **--storage-opt size** option, docker should ensure the
   574      **size** cannot be smaller than **btrfs.min_space**.
   575  
   576      Example use:
   577          $ docker daemon -s btrfs --storage-opt btrfs.min_space=10G
   578  
   579  #### Overlay2 options
   580  
   581  * `overlay2.override_kernel_check`
   582  
   583      Overrides the Linux kernel version check allowing overlay2. Support for
   584      specifying multiple lower directories needed by overlay2 was added to the
   585      Linux kernel in 4.0.0. However some older kernel versions may be patched
   586      to add multiple lower directory support for OverlayFS. This option should
   587      only be used after verifying this support exists in the kernel. Applying
   588      this option on a kernel without this support will cause failures on mount.
   589  
   590  ## Docker runtime execution options
   591  
   592  The Docker daemon relies on a
   593  [OCI](https://github.com/opencontainers/specs) compliant runtime
   594  (invoked via the `containerd` daemon) as its interface to the Linux
   595  kernel `namespaces`, `cgroups`, and `SELinux`.
   596  
   597  Runtimes can be registered with the daemon either via the
   598  configuration file or using the `--add-runtime` command line argument.
   599  
   600  The following is an example adding 2 runtimes via the configuration:
   601  ```json
   602  	"default-runtime": "runc",
   603  	"runtimes": {
   604  		"runc": {
   605  			"path": "runc"
   606  		},
   607  		"custom": {
   608  			"path": "/usr/local/bin/my-runc-replacement",
   609  			"runtimeArgs": [
   610  				"--debug"
   611  			]
   612  		}
   613  	}
   614  ```
   615  
   616  This is the same example via the command line:
   617  
   618      $ sudo dockerd --add-runtime runc=runc --add-runtime custom=/usr/local/bin/my-runc-replacement
   619  
   620  **Note**: defining runtime arguments via the command line is not supported.
   621  
   622  ## Options for the runtime
   623  
   624  You can configure the runtime using options specified
   625  with the `--exec-opt` flag. All the flag's options have the `native` prefix. A
   626  single `native.cgroupdriver` option is available.
   627  
   628  The `native.cgroupdriver` option specifies the management of the container's
   629  cgroups. You can specify only specify `cgroupfs` or `systemd`. If you specify
   630  `systemd` and it is not available, the system errors out. If you omit the
   631  `native.cgroupdriver` option,` cgroupfs` is used.
   632  
   633  This example sets the `cgroupdriver` to `systemd`:
   634  
   635      $ sudo dockerd --exec-opt native.cgroupdriver=systemd
   636  
   637  Setting this option applies to all containers the daemon launches.
   638  
   639  Also Windows Container makes use of `--exec-opt` for special purpose. Docker user
   640  can specify default container isolation technology with this, for example:
   641  
   642      $ dockerd --exec-opt isolation=hyperv
   643  
   644  Will make `hyperv` the default isolation technology on Windows. If no isolation
   645  value is specified on daemon start, on Windows client, the default is
   646  `hyperv`, and on Windows server, the default is `process`.
   647  
   648  ## Daemon DNS options
   649  
   650  To set the DNS server for all Docker containers, use
   651  `dockerd --dns 8.8.8.8`.
   652  
   653  To set the DNS search domain for all Docker containers, use
   654  `dockerd --dns-search example.com`.
   655  
   656  ## Insecure registries
   657  
   658  Docker considers a private registry either secure or insecure. In the rest of
   659  this section, *registry* is used for *private registry*, and `myregistry:5000`
   660  is a placeholder example for a private registry.
   661  
   662  A secure registry uses TLS and a copy of its CA certificate is placed on the
   663  Docker host at `/etc/docker/certs.d/myregistry:5000/ca.crt`. An insecure
   664  registry is either not using TLS (i.e., listening on plain text HTTP), or is
   665  using TLS with a CA certificate not known by the Docker daemon. The latter can
   666  happen when the certificate was not found under
   667  `/etc/docker/certs.d/myregistry:5000/`, or if the certificate verification
   668  failed (i.e., wrong CA).
   669  
   670  By default, Docker assumes all, but local (see local registries below),
   671  registries are secure. Communicating with an insecure registry is not possible
   672  if Docker assumes that registry is secure. In order to communicate with an
   673  insecure registry, the Docker daemon requires `--insecure-registry` in one of
   674  the following two forms:
   675  
   676  * `--insecure-registry myregistry:5000` tells the Docker daemon that
   677    myregistry:5000 should be considered insecure.
   678  * `--insecure-registry 10.1.0.0/16` tells the Docker daemon that all registries
   679    whose domain resolve to an IP address is part of the subnet described by the
   680    CIDR syntax, should be considered insecure.
   681  
   682  The flag can be used multiple times to allow multiple registries to be marked
   683  as insecure.
   684  
   685  If an insecure registry is not marked as insecure, `docker pull`,
   686  `docker push`, and `docker search` will result in an error message prompting
   687  the user to either secure or pass the `--insecure-registry` flag to the Docker
   688  daemon as described above.
   689  
   690  Local registries, whose IP address falls in the 127.0.0.0/8 range, are
   691  automatically marked as insecure as of Docker 1.3.2. It is not recommended to
   692  rely on this, as it may change in the future.
   693  
   694  Enabling `--insecure-registry`, i.e., allowing un-encrypted and/or untrusted
   695  communication, can be useful when running a local registry.  However,
   696  because its use creates security vulnerabilities it should ONLY be enabled for
   697  testing purposes.  For increased security, users should add their CA to their
   698  system's list of trusted CAs instead of enabling `--insecure-registry`.
   699  
   700  ## Legacy Registries
   701  
   702  Enabling `--disable-legacy-registry` forces a docker daemon to only interact with registries which support the V2 protocol.  Specifically, the daemon will not attempt `push`, `pull` and `login` to v1 registries.  The exception to this is `search` which can still be performed on v1 registries.
   703  
   704  ## Running a Docker daemon behind an HTTPS_PROXY
   705  
   706  When running inside a LAN that uses an `HTTPS` proxy, the Docker Hub
   707  certificates will be replaced by the proxy's certificates. These certificates
   708  need to be added to your Docker host's configuration:
   709  
   710  1. Install the `ca-certificates` package for your distribution
   711  2. Ask your network admin for the proxy's CA certificate and append them to
   712     `/etc/pki/tls/certs/ca-bundle.crt`
   713  3. Then start your Docker daemon with `HTTPS_PROXY=http://username:password@proxy:port/ dockerd`.
   714     The `username:` and `password@` are optional - and are only needed if your
   715     proxy is set up to require authentication.
   716  
   717  This will only add the proxy and authentication to the Docker daemon's requests -
   718  your `docker build`s and running containers will need extra configuration to
   719  use the proxy
   720  
   721  ## Default Ulimits
   722  
   723  `--default-ulimit` allows you to set the default `ulimit` options to use for
   724  all containers. It takes the same options as `--ulimit` for `docker run`. If
   725  these defaults are not set, `ulimit` settings will be inherited, if not set on
   726  `docker run`, from the Docker daemon. Any `--ulimit` options passed to
   727  `docker run` will overwrite these defaults.
   728  
   729  Be careful setting `nproc` with the `ulimit` flag as `nproc` is designed by Linux to
   730  set the maximum number of processes available to a user, not to a container. For details
   731  please check the [run](run.md) reference.
   732  
   733  ## Nodes discovery
   734  
   735  The `--cluster-advertise` option specifies the `host:port` or `interface:port`
   736  combination that this particular daemon instance should use when advertising
   737  itself to the cluster. The daemon is reached by remote hosts through this value.
   738  If you  specify an interface, make sure it includes the IP address of the actual
   739  Docker host. For Engine installation created through `docker-machine`, the
   740  interface is typically `eth1`.
   741  
   742  The daemon uses [libkv](https://github.com/docker/libkv/) to advertise
   743  the node within the cluster. Some key-value backends support mutual
   744  TLS. To configure the client TLS settings used by the daemon can be configured
   745  using the `--cluster-store-opt` flag, specifying the paths to PEM encoded
   746  files. For example:
   747  
   748  ```bash
   749  dockerd \
   750      --cluster-advertise 192.168.1.2:2376 \
   751      --cluster-store etcd://192.168.1.2:2379 \
   752      --cluster-store-opt kv.cacertfile=/path/to/ca.pem \
   753      --cluster-store-opt kv.certfile=/path/to/cert.pem \
   754      --cluster-store-opt kv.keyfile=/path/to/key.pem
   755  ```
   756  
   757  The currently supported cluster store options are:
   758  
   759  *  `discovery.heartbeat`
   760  
   761      Specifies the heartbeat timer in seconds which is used by the daemon as a
   762      keepalive mechanism to make sure discovery module treats the node as alive
   763      in the cluster. If not configured, the default value is 20 seconds.
   764  
   765  *  `discovery.ttl`
   766  
   767      Specifies the ttl (time-to-live) in seconds which is used by the discovery
   768      module to timeout a node if a valid heartbeat is not received within the
   769      configured ttl value. If not configured, the default value is 60 seconds.
   770  
   771  *  `kv.cacertfile`
   772  
   773      Specifies the path to a local file with PEM encoded CA certificates to trust
   774  
   775  *  `kv.certfile`
   776  
   777      Specifies the path to a local file with a PEM encoded certificate.  This
   778      certificate is used as the client cert for communication with the
   779      Key/Value store.
   780  
   781  *  `kv.keyfile`
   782  
   783      Specifies the path to a local file with a PEM encoded private key.  This
   784      private key is used as the client key for communication with the
   785      Key/Value store.
   786  
   787  *  `kv.path`
   788  
   789      Specifies the path in the Key/Value store. If not configured, the default value is 'docker/nodes'.
   790  
   791  ## Access authorization
   792  
   793  Docker's access authorization can be extended by authorization plugins that your
   794  organization can purchase or build themselves. You can install one or more
   795  authorization plugins when you start the Docker `daemon` using the
   796  `--authorization-plugin=PLUGIN_ID` option.
   797  
   798  ```bash
   799  dockerd --authorization-plugin=plugin1 --authorization-plugin=plugin2,...
   800  ```
   801  
   802  The `PLUGIN_ID` value is either the plugin's name or a path to its specification
   803  file. The plugin's implementation determines whether you can specify a name or
   804  path. Consult with your Docker administrator to get information about the
   805  plugins available to you.
   806  
   807  Once a plugin is installed, requests made to the `daemon` through the command
   808  line or Docker's remote API are allowed or denied by the plugin.  If you have
   809  multiple plugins installed, at least one must allow the request for it to
   810  complete.
   811  
   812  For information about how to create an authorization plugin, see [authorization
   813  plugin](../../extend/plugins_authorization.md) section in the Docker extend section of this documentation.
   814  
   815  
   816  ## Daemon user namespace options
   817  
   818  The Linux kernel [user namespace support](http://man7.org/linux/man-pages/man7/user_namespaces.7.html) provides additional security by enabling
   819  a process, and therefore a container, to have a unique range of user and
   820  group IDs which are outside the traditional user and group range utilized by
   821  the host system. Potentially the most important security improvement is that,
   822  by default, container processes running as the `root` user will have expected
   823  administrative privilege (with some restrictions) inside the container but will
   824  effectively be mapped to an unprivileged `uid` on the host.
   825  
   826  When user namespace support is enabled, Docker creates a single daemon-wide mapping
   827  for all containers running on the same engine instance. The mappings will
   828  utilize the existing subordinate user and group ID feature available on all modern
   829  Linux distributions.
   830  The [`/etc/subuid`](http://man7.org/linux/man-pages/man5/subuid.5.html) and
   831  [`/etc/subgid`](http://man7.org/linux/man-pages/man5/subgid.5.html) files will be
   832  read for the user, and optional group, specified to the `--userns-remap`
   833  parameter.  If you do not wish to specify your own user and/or group, you can
   834  provide `default` as the value to this flag, and a user will be created on your behalf
   835  and provided subordinate uid and gid ranges. This default user will be named
   836  `dockremap`, and entries will be created for it in `/etc/passwd` and
   837  `/etc/group` using your distro's standard user and group creation tools.
   838  
   839  > **Note**: The single mapping per-daemon restriction is in place for now
   840  > because Docker shares image layers from its local cache across all
   841  > containers running on the engine instance.  Since file ownership must be
   842  > the same for all containers sharing the same layer content, the decision
   843  > was made to map the file ownership on `docker pull` to the daemon's user and
   844  > group mappings so that there is no delay for running containers once the
   845  > content is downloaded. This design preserves the same performance for `docker
   846  > pull`, `docker push`, and container startup as users expect with
   847  > user namespaces disabled.
   848  
   849  ### Starting the daemon with user namespaces enabled
   850  
   851  To enable user namespace support, start the daemon with the
   852  `--userns-remap` flag, which accepts values in the following formats:
   853  
   854   - uid
   855   - uid:gid
   856   - username
   857   - username:groupname
   858  
   859  If numeric IDs are provided, translation back to valid user or group names
   860  will occur so that the subordinate uid and gid information can be read, given
   861  these resources are name-based, not id-based.  If the numeric ID information
   862  provided does not exist as entries in `/etc/passwd` or `/etc/group`, daemon
   863  startup will fail with an error message.
   864  
   865  > **Note:** On Fedora 22, you have to `touch` the `/etc/subuid` and `/etc/subgid`
   866  > files to have ranges assigned when users are created.  This must be done
   867  > *before* the `--userns-remap` option is enabled. Once these files exist, the
   868  > daemon can be (re)started and range assignment on user creation works properly.
   869  
   870  *Example: starting with default Docker user management:*
   871  
   872  ```bash
   873  $ dockerd --userns-remap=default
   874  ```
   875  
   876  When `default` is provided, Docker will create - or find the existing - user and group
   877  named `dockremap`. If the user is created, and the Linux distribution has
   878  appropriate support, the `/etc/subuid` and `/etc/subgid` files will be populated
   879  with a contiguous 65536 length range of subordinate user and group IDs, starting
   880  at an offset based on prior entries in those files.  For example, Ubuntu will
   881  create the following range, based on an existing user named `user1` already owning
   882  the first 65536 range:
   883  
   884  ```bash
   885  $ cat /etc/subuid
   886  user1:100000:65536
   887  dockremap:165536:65536
   888  ```
   889  
   890  If you have a preferred/self-managed user with subordinate ID mappings already
   891  configured, you can provide that username or uid to the `--userns-remap` flag.
   892  If you have a group that doesn't match the username, you may provide the `gid`
   893  or group name as well; otherwise the username will be used as the group name
   894  when querying the system for the subordinate group ID range.
   895  
   896  ### Detailed information on `subuid`/`subgid` ranges
   897  
   898  Given potential advanced use of the subordinate ID ranges by power users, the
   899  following paragraphs define how the Docker daemon currently uses the range entries
   900  found within the subordinate range files.
   901  
   902  The simplest case is that only one contiguous range is defined for the
   903  provided user or group. In this case, Docker will use that entire contiguous
   904  range for the mapping of host uids and gids to the container process.  This
   905  means that the first ID in the range will be the remapped root user, and the
   906  IDs above that initial ID will map host ID 1 through the end of the range.
   907  
   908  From the example `/etc/subuid` content shown above, the remapped root
   909  user would be uid 165536.
   910  
   911  If the system administrator has set up multiple ranges for a single user or
   912  group, the Docker daemon will read all the available ranges and use the
   913  following algorithm to create the mapping ranges:
   914  
   915  1. The range segments found for the particular user will be sorted by *start ID* ascending.
   916  2. Map segments will be created from each range in increasing value with a length matching the length of each segment. Therefore the range segment with the lowest numeric starting value will be equal to the remapped root, and continue up through host uid/gid equal to the range segment length. As an example, if the lowest segment starts at ID 1000 and has a length of 100, then a map of 1000 -> 0 (the remapped root) up through 1100 -> 100 will be created from this segment. If the next segment starts at ID 10000, then the next map will start with mapping 10000 -> 101 up to the length of this second segment. This will continue until no more segments are found in the subordinate files for this user.
   917  3. If more than five range segments exist for a single user, only the first five will be utilized, matching the kernel's limitation of only five entries in `/proc/self/uid_map` and `proc/self/gid_map`.
   918  
   919  ### Disable user namespace for a container
   920  
   921  If you enable user namespaces on the daemon, all containers are started
   922  with user namespaces enabled. In some situations you might want to disable
   923  this feature for a container, for example, to start a privileged container (see
   924  [user namespace known restrictions](#user-namespace-known-restrictions)).
   925  To enable those advanced features for a specific container use `--userns=host`
   926  in the `run/exec/create` command.
   927  This option will completely disable user namespace mapping for the container's user.
   928  
   929  ### User namespace known restrictions
   930  
   931  The following standard Docker features are currently incompatible when
   932  running a Docker daemon with user namespaces enabled:
   933  
   934   - sharing PID or NET namespaces with the host (`--pid=host` or `--network=host`)
   935   - A `--read-only` container filesystem (this is a Linux kernel restriction against remounting with modified flags of a currently mounted filesystem when inside a user namespace)
   936   - external (volume or graph) drivers which are unaware/incapable of using daemon user mappings
   937   - Using `--privileged` mode flag on `docker run` (unless also specifying `--userns=host`)
   938  
   939  In general, user namespaces are an advanced feature and will require
   940  coordination with other capabilities. For example, if volumes are mounted from
   941  the host, file ownership will have to be pre-arranged if the user or
   942  administrator wishes the containers to have expected access to the volume
   943  contents.
   944  
   945  Finally, while the `root` user inside a user namespaced container process has
   946  many of the expected admin privileges that go along with being the superuser, the
   947  Linux kernel has restrictions based on internal knowledge that this is a user namespaced
   948  process. The most notable restriction that we are aware of at this time is the
   949  inability to use `mknod`. Permission will be denied for device creation even as
   950  container `root` inside a user namespace.
   951  
   952  ## Miscellaneous options
   953  
   954  IP masquerading uses address translation to allow containers without a public
   955  IP to talk to other machines on the Internet. This may interfere with some
   956  network topologies and can be disabled with `--ip-masq=false`.
   957  
   958  Docker supports softlinks for the Docker data directory (`/var/lib/docker`) and
   959  for `/var/lib/docker/tmp`. The `DOCKER_TMPDIR` and the data directory can be
   960  set like this:
   961  
   962      DOCKER_TMPDIR=/mnt/disk2/tmp /usr/local/bin/dockerd -D -g /var/lib/docker -H unix:// > /var/lib/docker-machine/docker.log 2>&1
   963      # or
   964      export DOCKER_TMPDIR=/mnt/disk2/tmp
   965      /usr/local/bin/dockerd -D -g /var/lib/docker -H unix:// > /var/lib/docker-machine/docker.log 2>&1
   966  
   967  ## Default cgroup parent
   968  
   969  The `--cgroup-parent` option allows you to set the default cgroup parent
   970  to use for containers. If this option is not set, it defaults to `/docker` for
   971  fs cgroup driver and `system.slice` for systemd cgroup driver.
   972  
   973  If the cgroup has a leading forward slash (`/`), the cgroup is created
   974  under the root cgroup, otherwise the cgroup is created under the daemon
   975  cgroup.
   976  
   977  Assuming the daemon is running in cgroup `daemoncgroup`,
   978  `--cgroup-parent=/foobar` creates a cgroup in
   979  `/sys/fs/cgroup/memory/foobar`, whereas using `--cgroup-parent=foobar`
   980  creates the cgroup in `/sys/fs/cgroup/memory/daemoncgroup/foobar`
   981  
   982  The systemd cgroup driver has different rules for `--cgroup-parent`. Systemd
   983  represents hierarchy by slice and the name of the slice encodes the location in
   984  the tree. So `--cgroup-parent` for systemd cgroups should be a slice name. A
   985  name can consist of a dash-separated series of names, which describes the path
   986  to the slice from the root slice. For example, `--cgroup-parent=user-a-b.slice`
   987  means the memory cgroup for the container is created in
   988  `/sys/fs/cgroup/memory/user.slice/user-a.slice/user-a-b.slice/docker-<id>.scope`.
   989  
   990  This setting can also be set per container, using the `--cgroup-parent`
   991  option on `docker create` and `docker run`, and takes precedence over
   992  the `--cgroup-parent` option on the daemon.
   993  
   994  ## Daemon configuration file
   995  
   996  The `--config-file` option allows you to set any configuration option
   997  for the daemon in a JSON format. This file uses the same flag names as keys,
   998  except for flags that allow several entries, where it uses the plural
   999  of the flag name, e.g., `labels` for the `label` flag.
  1000  
  1001  The options set in the configuration file must not conflict with options set
  1002  via flags. The docker daemon fails to start if an option is duplicated between
  1003  the file and the flags, regardless their value. We do this to avoid
  1004  silently ignore changes introduced in configuration reloads.
  1005  For example, the daemon fails to start if you set daemon labels
  1006  in the configuration file and also set daemon labels via the `--label` flag.
  1007  Options that are not present in the file are ignored when the daemon starts.
  1008  
  1009  ### Linux configuration file
  1010  
  1011  The default location of the configuration file on Linux is
  1012  `/etc/docker/daemon.json`. The `--config-file` flag can be used to specify a
  1013   non-default location.
  1014  
  1015  This is a full example of the allowed configuration options on Linux:
  1016  
  1017  ```json
  1018  {
  1019  	"authorization-plugins": [],
  1020  	"dns": [],
  1021  	"dns-opts": [],
  1022  	"dns-search": [],
  1023  	"exec-opts": [],
  1024  	"exec-root": "",
  1025  	"storage-driver": "",
  1026  	"storage-opts": [],
  1027  	"labels": [],
  1028  	"live-restore": true,
  1029  	"log-driver": "",
  1030  	"log-opts": [],
  1031  	"mtu": 0,
  1032  	"pidfile": "",
  1033  	"graph": "",
  1034  	"cluster-store": "",
  1035  	"cluster-store-opts": {},
  1036  	"cluster-advertise": "",
  1037  	"max-concurrent-downloads": 3,
  1038  	"max-concurrent-uploads": 5,
  1039  	"debug": true,
  1040  	"hosts": [],
  1041  	"log-level": "",
  1042  	"tls": true,
  1043  	"tlsverify": true,
  1044  	"tlscacert": "",
  1045  	"tlscert": "",
  1046  	"tlskey": "",
  1047  	"swarm-default-advertise-addr": "",
  1048  	"api-cors-header": "",
  1049  	"selinux-enabled": false,
  1050  	"userns-remap": "",
  1051  	"group": "",
  1052  	"cgroup-parent": "",
  1053  	"default-ulimits": {},
  1054  	"ipv6": false,
  1055  	"iptables": false,
  1056  	"ip-forward": false,
  1057  	"ip-masq": false,
  1058  	"userland-proxy": false,
  1059  	"ip": "0.0.0.0",
  1060  	"bridge": "",
  1061  	"bip": "",
  1062  	"fixed-cidr": "",
  1063  	"fixed-cidr-v6": "",
  1064  	"default-gateway": "",
  1065  	"default-gateway-v6": "",
  1066  	"icc": false,
  1067  	"raw-logs": false,
  1068  	"registry-mirrors": [],
  1069  	"insecure-registries": [],
  1070  	"disable-legacy-registry": false,
  1071  	"default-runtime": "runc",
  1072  	"oom-score-adjust": -500,
  1073  	"runtimes": {
  1074  		"runc": {
  1075  			"path": "runc"
  1076  		},
  1077  		"custom": {
  1078  			"path": "/usr/local/bin/my-runc-replacement",
  1079  			"runtimeArgs": [
  1080  				"--debug"
  1081  			]
  1082  		}
  1083  	}
  1084  }
  1085  ```
  1086  
  1087  ### Windows configuration file
  1088  
  1089  The default location of the configuration file on Windows is
  1090   `%programdata%\docker\config\daemon.json`. The `--config-file` flag can be
  1091   used to specify a non-default location.
  1092  
  1093  This is a full example of the allowed configuration options on Windows:
  1094  
  1095  ```json
  1096  {
  1097      "authorization-plugins": [],
  1098      "dns": [],
  1099      "dns-opts": [],
  1100      "dns-search": [],
  1101      "exec-opts": [],
  1102      "storage-driver": "",
  1103      "storage-opts": [],
  1104      "labels": [],
  1105      "live-restore": true,
  1106      "log-driver": "",
  1107      "mtu": 0,
  1108      "pidfile": "",
  1109      "graph": "",
  1110      "cluster-store": "",
  1111      "cluster-advertise": "",
  1112      "debug": true,
  1113      "hosts": [],
  1114      "log-level": "",
  1115      "tlsverify": true,
  1116      "tlscacert": "",
  1117      "tlscert": "",
  1118      "tlskey": "",
  1119      "swarm-default-advertise-addr": "",
  1120      "group": "",
  1121      "default-ulimits": {},
  1122      "bridge": "",
  1123      "fixed-cidr": "",
  1124      "raw-logs": false,
  1125      "registry-mirrors": [],
  1126      "insecure-registries": [],
  1127      "disable-legacy-registry": false
  1128  }
  1129  ```
  1130  
  1131  ### Configuration reloading
  1132  
  1133  Some options can be reconfigured when the daemon is running without requiring
  1134  to restart the process. We use the `SIGHUP` signal in Linux to reload, and a global event
  1135  in Windows with the key `Global\docker-daemon-config-$PID`. The options can
  1136  be modified in the configuration file but still will check for conflicts with
  1137  the provided flags. The daemon fails to reconfigure itself
  1138  if there are conflicts, but it won't stop execution.
  1139  
  1140  The list of currently supported options that can be reconfigured is this:
  1141  
  1142  - `debug`: it changes the daemon to debug mode when set to true.
  1143  - `cluster-store`: it reloads the discovery store with the new address.
  1144  - `cluster-store-opts`: it uses the new options to reload the discovery store.
  1145  - `cluster-advertise`: it modifies the address advertised after reloading.
  1146  - `labels`: it replaces the daemon labels with a new set of labels.
  1147  - `live-restore`: Enables [keeping containers alive during daemon downtime](../../admin/live-restore.md).
  1148  - `max-concurrent-downloads`: it updates the max concurrent downloads for each pull.
  1149  - `max-concurrent-uploads`: it updates the max concurrent uploads for each push.
  1150  - `default-runtime`: it updates the runtime to be used if not is
  1151    specified at container creation. It defaults to "default" which is
  1152    the runtime shipped with the official docker packages.
  1153  - `runtimes`: it updates the list of available OCI runtimes that can
  1154    be used to run containers
  1155  - `authorization-plugin`: specifies the authorization plugins to use.
  1156  
  1157  Updating and reloading the cluster configurations such as `--cluster-store`,
  1158  `--cluster-advertise` and `--cluster-store-opts` will take effect only if
  1159  these configurations were not previously configured. If `--cluster-store`
  1160  has been provided in flags and `cluster-advertise` not, `cluster-advertise`
  1161  can be added in the configuration file without accompanied by `--cluster-store`
  1162  Configuration reload will log a warning message if it detects a change in
  1163  previously configured cluster configurations.
  1164  
  1165  
  1166  ## Running multiple daemons
  1167  
  1168  > **Note:** Running multiple daemons on a single host is considered as "experimental". The user should be aware of
  1169  > unsolved problems. This solution may not work properly in some cases. Solutions are currently under development
  1170  > and will be delivered in the near future.
  1171  
  1172  This section describes how to run multiple Docker daemons on a single host. To
  1173  run multiple daemons, you must configure each daemon so that it does not
  1174  conflict with other daemons on the same host. You can set these options either
  1175  by providing them as flags, or by using a [daemon configuration file](#daemon-configuration-file).
  1176  
  1177  The following daemon options must be configured for each daemon:
  1178  
  1179  ```bash
  1180  -b, --bridge=                          Attach containers to a network bridge
  1181  --exec-root=/var/run/docker            Root of the Docker execdriver
  1182  -g, --graph=/var/lib/docker            Root of the Docker runtime
  1183  -p, --pidfile=/var/run/docker.pid      Path to use for daemon PID file
  1184  -H, --host=[]                          Daemon socket(s) to connect to
  1185  --iptables=true                        Enable addition of iptables rules
  1186  --config-file=/etc/docker/daemon.json  Daemon configuration file
  1187  --tlscacert="~/.docker/ca.pem"         Trust certs signed only by this CA
  1188  --tlscert="~/.docker/cert.pem"         Path to TLS certificate file
  1189  --tlskey="~/.docker/key.pem"           Path to TLS key file
  1190  ```
  1191  
  1192  When your daemons use different values for these flags, you can run them on the same host without any problems.
  1193  It is very important to properly understand the meaning of those options and to use them correctly.
  1194  
  1195  - The `-b, --bridge=` flag is set to `docker0` as default bridge network. It is created automatically when you install Docker.
  1196  If you are not using the default, you must create and configure the bridge manually or just set it to 'none': `--bridge=none`
  1197  - `--exec-root` is the path where the container state is stored. The default value is `/var/run/docker`. Specify the path for
  1198  your running daemon here.
  1199  - `--graph` is the path where images are stored. The default value is `/var/lib/docker`. To avoid any conflict with other daemons
  1200  set this parameter separately for each daemon.
  1201  - `-p, --pidfile=/var/run/docker.pid` is the path where the process ID of the daemon is stored. Specify the path for your
  1202  pid file here.
  1203  - `--host=[]` specifies where the Docker daemon will listen for client connections. If unspecified, it defaults to `/var/run/docker.sock`.
  1204  - `--iptables=false` prevents the Docker daemon from adding iptables rules. If
  1205    multiple daemons manage iptables rules, they may overwrite rules set by
  1206    another daemon. Be aware that disabling this option requires you to manually
  1207    add iptables rules to expose container ports.
  1208  - `--config-file=/etc/docker/daemon.json` is the path where configuration file is stored. You can use it instead of
  1209  daemon flags. Specify the path for each daemon.
  1210  - `--tls*` Docker daemon supports `--tlsverify` mode that enforces encrypted and authenticated remote connections.
  1211  The `--tls*` options enable use of specific certificates for individual daemons.
  1212  
  1213  Example script for a separate “bootstrap” instance of the Docker daemon without network:
  1214  
  1215  ```bash
  1216  $ docker daemon \
  1217          -H unix:///var/run/docker-bootstrap.sock \
  1218          -p /var/run/docker-bootstrap.pid \
  1219          --iptables=false \
  1220          --ip-masq=false \
  1221          --bridge=none \
  1222          --graph=/var/lib/docker-bootstrap \
  1223          --exec-root=/var/run/docker-bootstrap
  1224  ```