github.com/slene/docker@v1.8.0-rc1/docs/reference/commandline/daemon.md (about)

     1  <!--[metadata]>
     2  +++
     3  title = "daemon"
     4  description = "The daemon command description and usage"
     5  keywords = ["container, daemon, runtime"]
     6  [menu.main]
     7  parent = "smn_cli"
     8  +++
     9  <![end-metadata]-->
    10  
    11  # daemon
    12  
    13      Usage: docker daemon [OPTIONS]
    14  
    15      A self-sufficient runtime for linux containers.
    16  
    17      Options:
    18        --api-cors-header=""                   Set CORS headers in the remote API
    19        -b, --bridge=""                        Attach containers to a network bridge
    20        --bip=""                               Specify network bridge IP
    21        -D, --debug=false                      Enable debug mode
    22        --default-gateway=""                   Container default gateway IPv4 address
    23        --default-gateway-v6=""                Container default gateway IPv6 address
    24        --dns=[]                               DNS server to use
    25        --dns-search=[]                        DNS search domains to use
    26        --default-ulimit=[]                    Set default ulimit settings for containers
    27        -e, --exec-driver="native"             Exec driver to use
    28        --exec-opt=[]                          Set exec driver options
    29        --exec-root="/var/run/docker"          Root of the Docker execdriver
    30        --fixed-cidr=""                        IPv4 subnet for fixed IPs
    31        --fixed-cidr-v6=""                     IPv6 subnet for fixed IPs
    32        -G, --group="docker"                   Group for the unix socket
    33        -g, --graph="/var/lib/docker"          Root of the Docker runtime
    34        -H, --host=[]                          Daemon socket(s) to connect to
    35        -h, --help=false                       Print usage
    36        --icc=true                             Enable inter-container communication
    37        --insecure-registry=[]                 Enable insecure registry communication
    38        --ip=0.0.0.0                           Default IP when binding container ports
    39        --ip-forward=true                      Enable net.ipv4.ip_forward
    40        --ip-masq=true                         Enable IP masquerading
    41        --iptables=true                        Enable addition of iptables rules
    42        --ipv6=false                           Enable IPv6 networking
    43        -l, --log-level="info"                 Set the logging level
    44        --label=[]                             Set key=value labels to the daemon
    45        --log-driver="json-file"               Default driver for container logs
    46        --log-opt=[]                           Log driver specific options
    47        --mtu=0                                Set the containers network MTU
    48        -p, --pidfile="/var/run/docker.pid"    Path to use for daemon PID file
    49        --registry-mirror=[]                   Preferred Docker registry mirror
    50        -s, --storage-driver=""                Storage driver to use
    51        --selinux-enabled=false                Enable selinux support
    52        --storage-opt=[]                       Set storage driver options
    53        --tls=false                            Use TLS; implied by --tlsverify
    54        --tlscacert="~/.docker/ca.pem"         Trust certs signed only by this CA
    55        --tlscert="~/.docker/cert.pem"         Path to TLS certificate file
    56        --tlskey="~/.docker/key.pem"           Path to TLS key file
    57        --tlsverify=false                      Use TLS and verify the remote
    58        --userland-proxy=true                  Use userland proxy for loopback traffic
    59  
    60  Options with [] may be specified multiple times.
    61  
    62  The Docker daemon is the persistent process that manages containers. Docker
    63  uses the same binary for both the daemon and client. To run the daemon you
    64  type `docker daemon`.
    65  
    66  To run the daemon with debug output, use `docker daemon -D`.
    67  
    68  ## Daemon socket option
    69  
    70  The Docker daemon can listen for [Docker Remote API](/reference/api/docker_remote_api/)
    71  requests via three different types of Socket: `unix`, `tcp`, and `fd`.
    72  
    73  By default, a `unix` domain socket (or IPC socket) is created at
    74  `/var/run/docker.sock`, requiring either `root` permission, or `docker` group
    75  membership.
    76  
    77  If you need to access the Docker daemon remotely, you need to enable the `tcp`
    78  Socket. Beware that the default setup provides un-encrypted and
    79  un-authenticated direct access to the Docker daemon - and should be secured
    80  either using the [built in HTTPS encrypted socket](/articles/https/), or by
    81  putting a secure web proxy in front of it. You can listen on port `2375` on all
    82  network interfaces with `-H tcp://0.0.0.0:2375`, or on a particular network
    83  interface using its IP address: `-H tcp://192.168.59.103:2375`. It is
    84  conventional to use port `2375` for un-encrypted, and port `2376` for encrypted
    85  communication with the daemon.
    86  
    87  > **Note:**
    88  > If you're using an HTTPS encrypted socket, keep in mind that only
    89  > TLS1.0 and greater are supported. Protocols SSLv3 and under are not
    90  > supported anymore for security reasons.
    91  
    92  On Systemd based systems, you can communicate with the daemon via
    93  [Systemd socket activation](http://0pointer.de/blog/projects/socket-activation.html),
    94  use `docker daemon -H fd://`. Using `fd://` will work perfectly for most setups but
    95  you can also specify individual sockets: `docker daemon -H fd://3`. If the
    96  specified socket activated files aren't found, then Docker will exit. You can
    97  find examples of using Systemd socket activation with Docker and Systemd in the
    98  [Docker source tree](https://github.com/docker/docker/tree/master/contrib/init/systemd/).
    99  
   100  You can configure the Docker daemon to listen to multiple sockets at the same
   101  time using multiple `-H` options:
   102  
   103      # listen using the default unix socket, and on 2 specific IP addresses on this host.
   104      docker daemon -H unix:///var/run/docker.sock -H tcp://192.168.59.106 -H tcp://10.10.10.2
   105  
   106  The Docker client will honor the `DOCKER_HOST` environment variable to set the
   107  `-H` flag for the client.
   108  
   109      $ docker -H tcp://0.0.0.0:2375 ps
   110      # or
   111      $ export DOCKER_HOST="tcp://0.0.0.0:2375"
   112      $ docker ps
   113      # both are equal
   114  
   115  Setting the `DOCKER_TLS_VERIFY` environment variable to any value other than
   116  the empty string is equivalent to setting the `--tlsverify` flag. The following
   117  are equivalent:
   118  
   119      $ docker --tlsverify ps
   120      # or
   121      $ export DOCKER_TLS_VERIFY=1
   122      $ docker ps
   123  
   124  The Docker client will honor the `HTTP_PROXY`, `HTTPS_PROXY`, and `NO_PROXY`
   125  environment variables (or the lowercase versions thereof). `HTTPS_PROXY` takes
   126  precedence over `HTTP_PROXY`.
   127  
   128  ### Daemon storage-driver option
   129  
   130  The Docker daemon has support for several different image layer storage
   131  drivers: `aufs`, `devicemapper`, `btrfs`, `zfs` and `overlay`.
   132  
   133  The `aufs` driver is the oldest, but is based on a Linux kernel patch-set that
   134  is unlikely to be merged into the main kernel. These are also known to cause
   135  some serious kernel crashes. However, `aufs` is also the only storage driver
   136  that allows containers to share executable and shared library memory, so is a
   137  useful choice when running thousands of containers with the same program or
   138  libraries.
   139  
   140  The `devicemapper` driver uses thin provisioning and Copy on Write (CoW)
   141  snapshots. For each devicemapper graph location – typically
   142  `/var/lib/docker/devicemapper` – a thin pool is created based on two block
   143  devices, one for data and one for metadata. By default, these block devices
   144  are created automatically by using loopback mounts of automatically created
   145  sparse files. Refer to [Storage driver options](#storage-driver-options) below
   146  for a way how to customize this setup.
   147  [~jpetazzo/Resizing Docker containers with the Device Mapper plugin](http://jpetazzo.github.io/2014/01/29/docker-device-mapper-resize/)
   148  article explains how to tune your existing setup without the use of options.
   149  
   150  The `btrfs` driver is very fast for `docker build` - but like `devicemapper`
   151  does not share executable memory between devices. Use
   152  `docker daemon -s btrfs -g /mnt/btrfs_partition`.
   153  
   154  The `zfs` driver is probably not fast as `btrfs` but has a longer track record
   155  on stability. Thanks to `Single Copy ARC` shared blocks between clones will be
   156  cached only once. Use `docker daemon -s zfs`. To select a different zfs filesystem
   157  set `zfs.fsname` option as described in [Storage driver options](#storage-driver-options).
   158  
   159  The `overlay` is a very fast union filesystem. It is now merged in the main
   160  Linux kernel as of [3.18.0](https://lkml.org/lkml/2014/10/26/137). Call
   161  `docker daemon -s overlay` to use it.
   162  
   163  > **Note:**
   164  > As promising as `overlay` is, the feature is still quite young and should not
   165  > be used in production. Most notably, using `overlay` can cause excessive
   166  > inode consumption (especially as the number of images grows), as well as
   167  > being incompatible with the use of RPMs.
   168  
   169  > **Note:**
   170  > It is currently unsupported on `btrfs` or any Copy on Write filesystem
   171  > and should only be used over `ext4` partitions.
   172  
   173  ### Storage driver options
   174  
   175  Particular storage-driver can be configured with options specified with
   176  `--storage-opt` flags. Options for `devicemapper` are prefixed with `dm` and
   177  options for `zfs` start with `zfs`.
   178  
   179  *  `dm.thinpooldev`
   180  
   181       Specifies a custom block storage device to use for the thin pool.
   182  
   183       If using a block device for device mapper storage, it is best to use `lvm`
   184       to create and manage the thin-pool volume. This volume is then handed to Docker
   185       to exclusively create snapshot volumes needed for images and containers.  
   186  
   187       Managing the thin-pool outside of Docker makes for the most feature-rich
   188       method of having Docker utilize device mapper thin provisioning as the
   189       backing storage for Docker's containers. The highlights of the lvm-based
   190       thin-pool management feature include: automatic or interactive thin-pool
   191       resize support, dynamically changing thin-pool features, automatic thinp
   192       metadata checking when lvm activates the thin-pool, etc.
   193  
   194       Example use:
   195  
   196          docker daemon --storage-opt dm.thinpooldev=/dev/mapper/thin-pool
   197  
   198   *  `dm.basesize`
   199  
   200      Specifies the size to use when creating the base device, which limits the
   201      size of images and containers. The default value is 100G. Note, thin devices
   202      are inherently "sparse", so a 100G device which is mostly empty doesn't use
   203      100 GB of space on the pool. However, the filesystem will use more space for
   204      the empty case the larger the device is.
   205  
   206      This value affects the system-wide "base" empty filesystem
   207      that may already be initialized and inherited by pulled images. Typically,
   208      a change to this value requires additional steps to take effect:
   209  
   210          $ sudo service docker stop
   211          $ sudo rm -rf /var/lib/docker
   212          $ sudo service docker start
   213  
   214      Example use:
   215  
   216          $ docker daemon --storage-opt dm.basesize=20G
   217  
   218   *  `dm.loopdatasize`
   219  
   220      >**Note**: This option configures devicemapper loopback, which should not be used in production.
   221  		
   222      Specifies the size to use when creating the loopback file for the
   223      "data" device which is used for the thin pool. The default size is
   224      100G. The file is sparse, so it will not initially take up this
   225      much space.
   226  
   227      Example use:
   228  
   229          $ docker daemon --storage-opt dm.loopdatasize=200G
   230  
   231   *  `dm.loopmetadatasize`
   232  
   233      >**Note**: This option configures devicemapper loopback, which should not be used in production.
   234  
   235      Specifies the size to use when creating the loopback file for the
   236      "metadadata" device which is used for the thin pool. The default size
   237      is 2G. The file is sparse, so it will not initially take up
   238      this much space.
   239  
   240      Example use:
   241  
   242          $ docker daemon --storage-opt dm.loopmetadatasize=4G
   243  
   244   *  `dm.fs`
   245  
   246      Specifies the filesystem type to use for the base device. The supported
   247      options are "ext4" and "xfs". The default is "ext4"
   248  
   249      Example use:
   250  
   251          $ docker daemon --storage-opt dm.fs=xfs
   252  
   253   *  `dm.mkfsarg`
   254  
   255      Specifies extra mkfs arguments to be used when creating the base device.
   256  
   257      Example use:
   258  
   259          $ docker daemon --storage-opt "dm.mkfsarg=-O ^has_journal"
   260  
   261   *  `dm.mountopt`
   262  
   263      Specifies extra mount options used when mounting the thin devices.
   264  
   265      Example use:
   266  
   267          $ docker daemon --storage-opt dm.mountopt=nodiscard
   268  
   269   *  `dm.datadev`
   270  
   271      (Deprecated, use `dm.thinpooldev`)
   272  
   273      Specifies a custom blockdevice to use for data for the thin pool.
   274  
   275      If using a block device for device mapper storage, ideally both datadev and
   276      metadatadev should be specified to completely avoid using the loopback
   277      device.
   278  
   279      Example use:
   280  
   281          $ docker daemon --storage-opt dm.datadev=/dev/sdb1 --storage-opt dm.metadatadev=/dev/sdc1
   282  
   283   *  `dm.metadatadev`
   284  
   285      (Deprecated, use `dm.thinpooldev`)
   286  
   287      Specifies a custom blockdevice to use for metadata for the thin pool.
   288  
   289      For best performance the metadata should be on a different spindle than the
   290      data, or even better on an SSD.
   291  
   292      If setting up a new metadata pool it is required to be valid. This can be
   293      achieved by zeroing the first 4k to indicate empty metadata, like this:
   294  
   295  	$ dd if=/dev/zero of=$metadata_dev bs=4096 count=1
   296  
   297      Example use:
   298  
   299          $ docker daemon --storage-opt dm.datadev=/dev/sdb1 --storage-opt dm.metadatadev=/dev/sdc1
   300  
   301   *  `dm.blocksize`
   302  
   303      Specifies a custom blocksize to use for the thin pool. The default
   304      blocksize is 64K.
   305  
   306      Example use:
   307  
   308          $ docker daemon --storage-opt dm.blocksize=512K
   309  
   310   *  `dm.blkdiscard`
   311  
   312      Enables or disables the use of blkdiscard when removing devicemapper
   313      devices. This is enabled by default (only) if using loopback devices and is
   314      required to resparsify the loopback file on image/container removal.
   315  
   316      Disabling this on loopback can lead to *much* faster container removal
   317      times, but will make the space used in `/var/lib/docker` directory not be
   318      returned to the system for other use when containers are removed.
   319  
   320      Example use:
   321  
   322          $ docker daemon --storage-opt dm.blkdiscard=false
   323  
   324   *  `dm.override_udev_sync_check`
   325  
   326      Overrides the `udev` synchronization checks between `devicemapper` and `udev`.
   327      `udev` is the device manager for the Linux kernel.
   328  
   329      To view the `udev` sync support of a Docker daemon that is using the
   330      `devicemapper` driver, run:
   331  
   332          $ docker info
   333          [...]
   334          Udev Sync Supported: true
   335          [...]
   336  
   337      When `udev` sync support is `true`, then `devicemapper` and udev can
   338      coordinate the activation and deactivation of devices for containers.
   339  
   340      When `udev` sync support is `false`, a race condition occurs between
   341      the`devicemapper` and `udev` during create and cleanup. The race condition
   342      results in errors and failures. (For information on these failures, see
   343      [docker#4036](https://github.com/docker/docker/issues/4036))
   344  
   345      To allow the `docker` daemon to start, regardless of `udev` sync not being
   346      supported, set `dm.override_udev_sync_check` to true:
   347  
   348          $ docker daemon --storage-opt dm.override_udev_sync_check=true
   349  
   350      When this value is `true`, the  `devicemapper` continues and simply warns
   351      you the errors are happening.
   352  
   353      > **Note:**
   354      > The ideal is to pursue a `docker` daemon and environment that does
   355      > support synchronizing with `udev`. For further discussion on this
   356      > topic, see [docker#4036](https://github.com/docker/docker/issues/4036).
   357      > Otherwise, set this flag for migrating existing Docker daemons to
   358      > a daemon with a supported environment.
   359  
   360  
   361  ## Docker execdriver option
   362  
   363  Currently supported options of `zfs`:
   364  
   365   * `zfs.fsname`
   366  
   367      Set zfs filesystem under which docker will create its own datasets.
   368      By default docker will pick up the zfs filesystem where docker graph
   369      (`/var/lib/docker`) is located.
   370  
   371      Example use:
   372  
   373          $ docker daemon -s zfs --storage-opt zfs.fsname=zroot/docker
   374  
   375  ## Docker execdriver option
   376  
   377  The Docker daemon uses a specifically built `libcontainer` execution driver as
   378  its interface to the Linux kernel `namespaces`, `cgroups`, and `SELinux`.
   379  
   380  There is still legacy support for the original [LXC userspace tools](
   381  https://linuxcontainers.org/) via the `lxc` execution driver, however, this is
   382  not where the primary development of new functionality is taking place.
   383  Add `-e lxc` to the daemon flags to use the `lxc` execution driver.
   384  
   385  ## Options for the native execdriver
   386  
   387  You can configure the `native` (libcontainer) execdriver using options specified
   388  with the `--exec-opt` flag. All the flag's options have the `native` prefix. A
   389  single `native.cgroupdriver` option is available.
   390  
   391  The `native.cgroupdriver` option specifies the management of the container's
   392  cgroups. You can specify `cgroupfs` or `systemd`. If you specify `systemd` and
   393  it is not available, the system uses `cgroupfs`. By default, if no option is
   394  specified, the execdriver first tries `systemd` and falls back to `cgroupfs`.
   395  This example sets the execdriver to `cgroupfs`:
   396  
   397      $ sudo docker daemon --exec-opt native.cgroupdriver=cgroupfs
   398  
   399  Setting this option applies to all containers the daemon launches.
   400  
   401  ## Daemon DNS options
   402  
   403  To set the DNS server for all Docker containers, use
   404  `docker daemon --dns 8.8.8.8`.
   405  
   406  To set the DNS search domain for all Docker containers, use
   407  `docker daemon --dns-search example.com`.
   408  
   409  ## Insecure registries
   410  
   411  Docker considers a private registry either secure or insecure. In the rest of
   412  this section, *registry* is used for *private registry*, and `myregistry:5000`
   413  is a placeholder example for a private registry.
   414  
   415  A secure registry uses TLS and a copy of its CA certificate is placed on the
   416  Docker host at `/etc/docker/certs.d/myregistry:5000/ca.crt`. An insecure
   417  registry is either not using TLS (i.e., listening on plain text HTTP), or is
   418  using TLS with a CA certificate not known by the Docker daemon. The latter can
   419  happen when the certificate was not found under
   420  `/etc/docker/certs.d/myregistry:5000/`, or if the certificate verification
   421  failed (i.e., wrong CA).
   422  
   423  By default, Docker assumes all, but local (see local registries below),
   424  registries are secure. Communicating with an insecure registry is not possible
   425  if Docker assumes that registry is secure. In order to communicate with an
   426  insecure registry, the Docker daemon requires `--insecure-registry` in one of
   427  the following two forms:
   428  
   429  * `--insecure-registry myregistry:5000` tells the Docker daemon that
   430    myregistry:5000 should be considered insecure.
   431  * `--insecure-registry 10.1.0.0/16` tells the Docker daemon that all registries
   432    whose domain resolve to an IP address is part of the subnet described by the
   433    CIDR syntax, should be considered insecure.
   434  
   435  The flag can be used multiple times to allow multiple registries to be marked
   436  as insecure.
   437  
   438  If an insecure registry is not marked as insecure, `docker pull`,
   439  `docker push`, and `docker search` will result in an error message prompting
   440  the user to either secure or pass the `--insecure-registry` flag to the Docker
   441  daemon as described above.
   442  
   443  Local registries, whose IP address falls in the 127.0.0.0/8 range, are
   444  automatically marked as insecure as of Docker 1.3.2. It is not recommended to
   445  rely on this, as it may change in the future.
   446  
   447  ## Running a Docker daemon behind a HTTPS_PROXY
   448  
   449  When running inside a LAN that uses a `HTTPS` proxy, the Docker Hub
   450  certificates will be replaced by the proxy's certificates. These certificates
   451  need to be added to your Docker host's configuration:
   452  
   453  1. Install the `ca-certificates` package for your distribution
   454  2. Ask your network admin for the proxy's CA certificate and append them to
   455     `/etc/pki/tls/certs/ca-bundle.crt`
   456  3. Then start your Docker daemon with `HTTPS_PROXY=http://username:password@proxy:port/ docker daemon`.
   457     The `username:` and `password@` are optional - and are only needed if your
   458     proxy is set up to require authentication.
   459  
   460  This will only add the proxy and authentication to the Docker daemon's requests -
   461  your `docker build`s and running containers will need extra configuration to
   462  use the proxy
   463  
   464  ## Default Ulimits
   465  
   466  `--default-ulimit` allows you to set the default `ulimit` options to use for
   467  all containers. It takes the same options as `--ulimit` for `docker run`. If
   468  these defaults are not set, `ulimit` settings will be inherited, if not set on
   469  `docker run`, from the Docker daemon. Any `--ulimit` options passed to 
   470  `docker run` will overwrite these defaults.
   471  
   472  Be careful setting `nproc` with the `ulimit` flag as `nproc` is designed by Linux to
   473  set the maximum number of processes available to a user, not to a container. For details
   474  please check the [run](run.md) reference.
   475  
   476  ## Miscellaneous options
   477  
   478  IP masquerading uses address translation to allow containers without a public
   479  IP to talk to other machines on the Internet. This may interfere with some
   480  network topologies and can be disabled with --ip-masq=false.
   481  
   482  Docker supports softlinks for the Docker data directory (`/var/lib/docker`) and
   483  for `/var/lib/docker/tmp`. The `DOCKER_TMPDIR` and the data directory can be
   484  set like this:
   485  
   486      DOCKER_TMPDIR=/mnt/disk2/tmp /usr/local/bin/docker daemon -D -g /var/lib/docker -H unix:// > /var/lib/boot2docker/docker.log 2>&1
   487      # or
   488      export DOCKER_TMPDIR=/mnt/disk2/tmp
   489      /usr/local/bin/docker daemon -D -g /var/lib/docker -H unix:// > /var/lib/boot2docker/docker.log 2>&1
   490  
   491