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