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 ```