mirror of
https://github.com/genuinetools/reg.git
synced 2024-08-21 06:10:23 -04:00
1511 lines
58 KiB
Markdown
1511 lines
58 KiB
Markdown
![]() |
---
|
|||
|
title: "dockerd"
|
|||
|
aliases: ["/engine/reference/commandline/daemon/"]
|
|||
|
description: "The daemon command description and usage"
|
|||
|
keywords: "container, daemon, runtime"
|
|||
|
---
|
|||
|
|
|||
|
<!-- This file is maintained within the docker/cli GitHub
|
|||
|
repository at https://github.com/docker/cli/. Make all
|
|||
|
pull requests against that repo. If you see this file in
|
|||
|
another repository, consider it read-only there, as it will
|
|||
|
periodically be overwritten by the definitive file. Pull
|
|||
|
requests which include edits to this file in other repositories
|
|||
|
will be rejected.
|
|||
|
-->
|
|||
|
|
|||
|
# daemon
|
|||
|
|
|||
|
```markdown
|
|||
|
Usage: dockerd COMMAND
|
|||
|
|
|||
|
A self-sufficient runtime for containers.
|
|||
|
|
|||
|
Options:
|
|||
|
--add-runtime runtime Register an additional OCI compatible runtime (default [])
|
|||
|
--allow-nondistributable-artifacts list Push nondistributable artifacts to specified registries (default [])
|
|||
|
--api-cors-header string Set CORS headers in the Engine API
|
|||
|
--authorization-plugin list Authorization plugins to load (default [])
|
|||
|
--bip string Specify network bridge IP
|
|||
|
-b, --bridge string Attach containers to a network bridge
|
|||
|
--cgroup-parent string Set parent cgroup for all containers
|
|||
|
--cluster-advertise string Address or interface name to advertise
|
|||
|
--cluster-store string URL of the distributed storage backend
|
|||
|
--cluster-store-opt map Set cluster store options (default map[])
|
|||
|
--config-file string Daemon configuration file (default "/etc/docker/daemon.json")
|
|||
|
--containerd string Path to containerd socket
|
|||
|
--cpu-rt-period int Limit the CPU real-time period in microseconds
|
|||
|
--cpu-rt-runtime int Limit the CPU real-time runtime in microseconds
|
|||
|
--data-root string Root directory of persistent Docker state (default "/var/lib/docker")
|
|||
|
-D, --debug Enable debug mode
|
|||
|
--default-gateway ip Container default gateway IPv4 address
|
|||
|
--default-gateway-v6 ip Container default gateway IPv6 address
|
|||
|
--default-runtime string Default OCI runtime for containers (default "runc")
|
|||
|
--default-ulimit ulimit Default ulimits for containers (default [])
|
|||
|
--dns list DNS server to use (default [])
|
|||
|
--dns-opt list DNS options to use (default [])
|
|||
|
--dns-search list DNS search domains to use (default [])
|
|||
|
--exec-opt list Runtime execution options (default [])
|
|||
|
--exec-root string Root directory for execution state files (default "/var/run/docker")
|
|||
|
--experimental Enable experimental features
|
|||
|
--fixed-cidr string IPv4 subnet for fixed IPs
|
|||
|
--fixed-cidr-v6 string IPv6 subnet for fixed IPs
|
|||
|
-G, --group string Group for the unix socket (default "docker")
|
|||
|
--help Print usage
|
|||
|
-H, --host list Daemon socket(s) to connect to (default [])
|
|||
|
--icc Enable inter-container communication (default true)
|
|||
|
--init Run an init in the container to forward signals and reap processes
|
|||
|
--init-path string Path to the docker-init binary
|
|||
|
--insecure-registry list Enable insecure registry communication (default [])
|
|||
|
--ip ip Default IP when binding container ports (default 0.0.0.0)
|
|||
|
--ip-forward Enable net.ipv4.ip_forward (default true)
|
|||
|
--ip-masq Enable IP masquerading (default true)
|
|||
|
--iptables Enable addition of iptables rules (default true)
|
|||
|
--ipv6 Enable IPv6 networking
|
|||
|
--label list Set key=value labels to the daemon (default [])
|
|||
|
--live-restore Enable live restore of docker when containers are still running
|
|||
|
--log-driver string Default driver for container logs (default "json-file")
|
|||
|
-l, --log-level string Set the logging level ("debug", "info", "warn", "error", "fatal") (default "info")
|
|||
|
--log-opt map Default log driver options for containers (default map[])
|
|||
|
--max-concurrent-downloads int Set the max concurrent downloads for each pull (default 3)
|
|||
|
--max-concurrent-uploads int Set the max concurrent uploads for each push (default 5)
|
|||
|
--metrics-addr string Set default address and port to serve the metrics api on
|
|||
|
--mtu int Set the containers network MTU
|
|||
|
--node-generic-resources list Advertise user-defined resource
|
|||
|
--no-new-privileges Set no-new-privileges by default for new containers
|
|||
|
--oom-score-adjust int Set the oom_score_adj for the daemon (default -500)
|
|||
|
-p, --pidfile string Path to use for daemon PID file (default "/var/run/docker.pid")
|
|||
|
--raw-logs Full timestamps without ANSI coloring
|
|||
|
--registry-mirror list Preferred Docker registry mirror (default [])
|
|||
|
--seccomp-profile string Path to seccomp profile
|
|||
|
--selinux-enabled Enable selinux support
|
|||
|
--shutdown-timeout int Set the default shutdown timeout (default 15)
|
|||
|
-s, --storage-driver string Storage driver to use
|
|||
|
--storage-opt list Storage driver options (default [])
|
|||
|
--swarm-default-advertise-addr string Set default address or interface for swarm advertised address
|
|||
|
--tls Use TLS; implied by --tlsverify
|
|||
|
--tlscacert string Trust certs signed only by this CA (default "~/.docker/ca.pem")
|
|||
|
--tlscert string Path to TLS certificate file (default "~/.docker/cert.pem")
|
|||
|
--tlskey string Path to TLS key file (default ~/.docker/key.pem")
|
|||
|
--tlsverify Use TLS and verify the remote
|
|||
|
--userland-proxy Use userland proxy for loopback traffic (default true)
|
|||
|
--userland-proxy-path string Path to the userland proxy binary
|
|||
|
--userns-remap string User/Group setting for user namespaces
|
|||
|
-v, --version Print version information and quit
|
|||
|
```
|
|||
|
|
|||
|
Options with [] may be specified multiple times.
|
|||
|
|
|||
|
## Description
|
|||
|
|
|||
|
`dockerd` is the persistent process that manages containers. Docker
|
|||
|
uses different binaries for the daemon and client. To run the daemon you
|
|||
|
type `dockerd`.
|
|||
|
|
|||
|
To run the daemon with debug output, use `dockerd -D` or add `"debug": true` to
|
|||
|
the `daemon.json` file.
|
|||
|
|
|||
|
> **Note**: In Docker 1.13 and higher, enable experimental features by starting
|
|||
|
> `dockerd` with the `--experimental` flag or adding `"experimental": true` to the
|
|||
|
> `daemon.json` file. In earlier Docker versions, a different build was required
|
|||
|
> to enable experimental features.
|
|||
|
|
|||
|
## Examples
|
|||
|
|
|||
|
### Daemon socket option
|
|||
|
|
|||
|
The Docker daemon can listen for [Docker Engine API](../api/)
|
|||
|
requests via three different types of Socket: `unix`, `tcp`, and `fd`.
|
|||
|
|
|||
|
By default, a `unix` domain socket (or IPC socket) is created at
|
|||
|
`/var/run/docker.sock`, requiring either `root` permission, or `docker` group
|
|||
|
membership.
|
|||
|
|
|||
|
If you need to access the Docker daemon remotely, you need to enable the `tcp`
|
|||
|
Socket. Beware that the default setup provides un-encrypted and
|
|||
|
un-authenticated direct access to the Docker daemon - and should be secured
|
|||
|
either using the [built in HTTPS encrypted socket](https://docs.docker.com/engine/security/https/), or by
|
|||
|
putting a secure web proxy in front of it. You can listen on port `2375` on all
|
|||
|
network interfaces with `-H tcp://0.0.0.0:2375`, or on a particular network
|
|||
|
interface using its IP address: `-H tcp://192.168.59.103:2375`. It is
|
|||
|
conventional to use port `2375` for un-encrypted, and port `2376` for encrypted
|
|||
|
communication with the daemon.
|
|||
|
|
|||
|
> **Note**: If you're using an HTTPS encrypted socket, keep in mind that only
|
|||
|
> TLS1.0 and greater are supported. Protocols SSLv3 and under are not
|
|||
|
> supported anymore for security reasons.
|
|||
|
|
|||
|
On Systemd based systems, you can communicate with the daemon via
|
|||
|
[Systemd socket activation](http://0pointer.de/blog/projects/socket-activation.html),
|
|||
|
use `dockerd -H fd://`. Using `fd://` will work perfectly for most setups but
|
|||
|
you can also specify individual sockets: `dockerd -H fd://3`. If the
|
|||
|
specified socket activated files aren't found, then Docker will exit. You can
|
|||
|
find examples of using Systemd socket activation with Docker and Systemd in the
|
|||
|
[Docker source tree](https://github.com/docker/docker/tree/master/contrib/init/systemd/).
|
|||
|
|
|||
|
You can configure the Docker daemon to listen to multiple sockets at the same
|
|||
|
time using multiple `-H` options:
|
|||
|
|
|||
|
```bash
|
|||
|
# listen using the default unix socket, and on 2 specific IP addresses on this host.
|
|||
|
|
|||
|
$ sudo dockerd -H unix:///var/run/docker.sock -H tcp://192.168.59.106 -H tcp://10.10.10.2
|
|||
|
```
|
|||
|
|
|||
|
The Docker client will honor the `DOCKER_HOST` environment variable to set the
|
|||
|
`-H` flag for the client. Use **one** of the following commands:
|
|||
|
|
|||
|
```bash
|
|||
|
$ docker -H tcp://0.0.0.0:2375 ps
|
|||
|
```
|
|||
|
|
|||
|
```bash
|
|||
|
$ export DOCKER_HOST="tcp://0.0.0.0:2375"
|
|||
|
|
|||
|
$ docker ps
|
|||
|
```
|
|||
|
|
|||
|
Setting the `DOCKER_TLS_VERIFY` environment variable to any value other than
|
|||
|
the empty string is equivalent to setting the `--tlsverify` flag. The following
|
|||
|
are equivalent:
|
|||
|
|
|||
|
```bash
|
|||
|
$ docker --tlsverify ps
|
|||
|
# or
|
|||
|
$ export DOCKER_TLS_VERIFY=1
|
|||
|
$ docker ps
|
|||
|
```
|
|||
|
|
|||
|
The Docker client will honor the `HTTP_PROXY`, `HTTPS_PROXY`, and `NO_PROXY`
|
|||
|
environment variables (or the lowercase versions thereof). `HTTPS_PROXY` takes
|
|||
|
precedence over `HTTP_PROXY`.
|
|||
|
|
|||
|
#### Bind Docker to another host/port or a Unix socket
|
|||
|
|
|||
|
> **Warning**:
|
|||
|
> Changing the default `docker` daemon binding to a
|
|||
|
> TCP port or Unix *docker* user group will increase your security risks
|
|||
|
> by allowing non-root users to gain *root* access on the host. Make sure
|
|||
|
> you control access to `docker`. If you are binding
|
|||
|
> to a TCP port, anyone with access to that port has full Docker access;
|
|||
|
> so it is not advisable on an open network.
|
|||
|
|
|||
|
With `-H` it is possible to make the Docker daemon to listen on a
|
|||
|
specific IP and port. By default, it will listen on
|
|||
|
`unix:///var/run/docker.sock` to allow only local connections by the
|
|||
|
*root* user. You *could* set it to `0.0.0.0:2375` or a specific host IP
|
|||
|
to give access to everybody, but that is **not recommended** because
|
|||
|
then it is trivial for someone to gain root access to the host where the
|
|||
|
daemon is running.
|
|||
|
|
|||
|
Similarly, the Docker client can use `-H` to connect to a custom port.
|
|||
|
The Docker client will default to connecting to `unix:///var/run/docker.sock`
|
|||
|
on Linux, and `tcp://127.0.0.1:2376` on Windows.
|
|||
|
|
|||
|
`-H` accepts host and port assignment in the following format:
|
|||
|
|
|||
|
tcp://[host]:[port][path] or unix://path
|
|||
|
|
|||
|
For example:
|
|||
|
|
|||
|
- `tcp://` -> TCP connection to `127.0.0.1` on either port `2376` when TLS encryption
|
|||
|
is on, or port `2375` when communication is in plain text.
|
|||
|
- `tcp://host:2375` -> TCP connection on
|
|||
|
host:2375
|
|||
|
- `tcp://host:2375/path` -> TCP connection on
|
|||
|
host:2375 and prepend path to all requests
|
|||
|
- `unix://path/to/socket` -> Unix socket located
|
|||
|
at `path/to/socket`
|
|||
|
|
|||
|
`-H`, when empty, will default to the same value as
|
|||
|
when no `-H` was passed in.
|
|||
|
|
|||
|
`-H` also accepts short form for TCP bindings: `host:` or `host:port` or `:port`
|
|||
|
|
|||
|
Run Docker in daemon mode:
|
|||
|
|
|||
|
```bash
|
|||
|
$ sudo <path to>/dockerd -H 0.0.0.0:5555 &
|
|||
|
```
|
|||
|
|
|||
|
Download an `ubuntu` image:
|
|||
|
|
|||
|
```bash
|
|||
|
$ docker -H :5555 pull ubuntu
|
|||
|
```
|
|||
|
|
|||
|
You can use multiple `-H`, for example, if you want to listen on both
|
|||
|
TCP and a Unix socket
|
|||
|
|
|||
|
```bash
|
|||
|
# Run docker in daemon mode
|
|||
|
$ sudo <path to>/dockerd -H tcp://127.0.0.1:2375 -H unix:///var/run/docker.sock &
|
|||
|
# Download an ubuntu image, use default Unix socket
|
|||
|
$ docker pull ubuntu
|
|||
|
# OR use the TCP port
|
|||
|
$ docker -H tcp://127.0.0.1:2375 pull ubuntu
|
|||
|
```
|
|||
|
|
|||
|
### Daemon storage-driver
|
|||
|
|
|||
|
On Linux, the Docker daemon has support for several different image layer storage
|
|||
|
drivers: `aufs`, `devicemapper`, `btrfs`, `zfs`, `overlay` and `overlay2`.
|
|||
|
|
|||
|
The `aufs` driver is the oldest, but is based on a Linux kernel patch-set that
|
|||
|
is unlikely to be merged into the main kernel. These are also known to cause
|
|||
|
some serious kernel crashes. However `aufs` allows containers to share
|
|||
|
executable and shared library memory, so is a useful choice when running
|
|||
|
thousands of containers with the same program or libraries.
|
|||
|
|
|||
|
The `devicemapper` driver uses thin provisioning and Copy on Write (CoW)
|
|||
|
snapshots. For each devicemapper graph location – typically
|
|||
|
`/var/lib/docker/devicemapper` – a thin pool is created based on two block
|
|||
|
devices, one for data and one for metadata. By default, these block devices
|
|||
|
are created automatically by using loopback mounts of automatically created
|
|||
|
sparse files. Refer to [Devicemapper options](#devicemapper-options) below
|
|||
|
for a way how to customize this setup.
|
|||
|
[~jpetazzo/Resizing Docker containers with the Device Mapper plugin](http://jpetazzo.github.io/2014/01/29/docker-device-mapper-resize/)
|
|||
|
article explains how to tune your existing setup without the use of options.
|
|||
|
|
|||
|
The `btrfs` driver is very fast for `docker build` - but like `devicemapper`
|
|||
|
does not share executable memory between devices. Use
|
|||
|
`dockerd -s btrfs -g /mnt/btrfs_partition`.
|
|||
|
|
|||
|
The `zfs` driver is probably not as fast as `btrfs` but has a longer track record
|
|||
|
on stability. Thanks to `Single Copy ARC` shared blocks between clones will be
|
|||
|
cached only once. Use `dockerd -s zfs`. To select a different zfs filesystem
|
|||
|
set `zfs.fsname` option as described in [ZFS options](#zfs-options).
|
|||
|
|
|||
|
The `overlay` is a very fast union filesystem. It is now merged in the main
|
|||
|
Linux kernel as of [3.18.0](https://lkml.org/lkml/2014/10/26/137). `overlay`
|
|||
|
also supports page cache sharing, this means multiple containers accessing
|
|||
|
the same file can share a single page cache entry (or entries), it makes
|
|||
|
`overlay` as efficient with memory as `aufs` driver. Call
|
|||
|
`dockerd -s overlay` to use it.
|
|||
|
|
|||
|
> **Note**: As promising as `overlay` is, the feature is still quite young and
|
|||
|
> should not be used in production. Most notably, using `overlay` can cause
|
|||
|
> excessive inode consumption (especially as the number of images grows), as
|
|||
|
> well as > being incompatible with the use of RPMs.
|
|||
|
|
|||
|
The `overlay2` uses the same fast union filesystem but takes advantage of
|
|||
|
[additional features](https://lkml.org/lkml/2015/2/11/106) added in Linux
|
|||
|
kernel 4.0 to avoid excessive inode consumption. Call `dockerd -s overlay2`
|
|||
|
to use it.
|
|||
|
|
|||
|
> **Note**: Both `overlay` and `overlay2` are currently unsupported on `btrfs`
|
|||
|
> or any Copy on Write filesystem and should only be used over `ext4` partitions.
|
|||
|
|
|||
|
On Windows, the Docker daemon supports a single image layer storage driver
|
|||
|
depending on the image platform: `windowsfilter` for Windows images, and
|
|||
|
`lcow` for Linux containers on Windows.
|
|||
|
|
|||
|
### Options per storage driver
|
|||
|
|
|||
|
Particular storage-driver can be configured with options specified with
|
|||
|
`--storage-opt` flags. Options for `devicemapper` are prefixed with `dm`,
|
|||
|
options for `zfs` start with `zfs`, options for `btrfs` start with `btrfs`
|
|||
|
and options for `lcow` start with `lcow`.
|
|||
|
|
|||
|
#### Devicemapper options
|
|||
|
|
|||
|
This is an example of the configuration file for devicemapper on Linux:
|
|||
|
|
|||
|
```json
|
|||
|
{
|
|||
|
"storage-driver": "devicemapper",
|
|||
|
"storage-opts": [
|
|||
|
"dm.thinpooldev=/dev/mapper/thin-pool",
|
|||
|
"dm.use_deferred_deletion=true",
|
|||
|
"dm.use_deferred_removal=true"
|
|||
|
]
|
|||
|
}
|
|||
|
```
|
|||
|
|
|||
|
##### `dm.thinpooldev`
|
|||
|
|
|||
|
Specifies a custom block storage device to use for the thin pool.
|
|||
|
|
|||
|
If using a block device for device mapper storage, it is best to use `lvm`
|
|||
|
to create and manage the thin-pool volume. This volume is then handed to Docker
|
|||
|
to exclusively create snapshot volumes needed for images and containers.
|
|||
|
|
|||
|
Managing the thin-pool outside of Engine makes for the most feature-rich
|
|||
|
method of having Docker utilize device mapper thin provisioning as the
|
|||
|
backing storage for Docker containers. The highlights of the lvm-based
|
|||
|
thin-pool management feature include: automatic or interactive thin-pool
|
|||
|
resize support, dynamically changing thin-pool features, automatic thinp
|
|||
|
metadata checking when lvm activates the thin-pool, etc.
|
|||
|
|
|||
|
As a fallback if no thin pool is provided, loopback files are
|
|||
|
created. Loopback is very slow, but can be used without any
|
|||
|
pre-configuration of storage. It is strongly recommended that you do
|
|||
|
not use loopback in production. Ensure your Engine daemon has a
|
|||
|
`--storage-opt dm.thinpooldev` argument provided.
|
|||
|
|
|||
|
###### Example:
|
|||
|
|
|||
|
```bash
|
|||
|
$ sudo dockerd --storage-opt dm.thinpooldev=/dev/mapper/thin-pool
|
|||
|
```
|
|||
|
|
|||
|
##### `dm.directlvm_device`
|
|||
|
|
|||
|
As an alternative to providing a thin pool as above, Docker can setup a block
|
|||
|
device for you.
|
|||
|
|
|||
|
###### Example:
|
|||
|
|
|||
|
```bash
|
|||
|
$ sudo dockerd --storage-opt dm.directlvm_device=/dev/xvdf
|
|||
|
```
|
|||
|
|
|||
|
##### `dm.thinp_percent`
|
|||
|
|
|||
|
Sets the percentage of passed in block device to use for storage.
|
|||
|
|
|||
|
###### Example:
|
|||
|
|
|||
|
```bash
|
|||
|
$ sudo dockerd --storage-opt dm.thinp_percent=95
|
|||
|
```
|
|||
|
|
|||
|
##### `dm.thinp_metapercent`
|
|||
|
|
|||
|
Sets the percentage of the passed in block device to use for metadata storage.
|
|||
|
|
|||
|
###### Example:
|
|||
|
|
|||
|
```bash
|
|||
|
$ sudo dockerd --storage-opt dm.thinp_metapercent=1
|
|||
|
```
|
|||
|
|
|||
|
##### `dm.thinp_autoextend_threshold`
|
|||
|
|
|||
|
Sets the value of the percentage of space used before `lvm` attempts to
|
|||
|
autoextend the available space [100 = disabled]
|
|||
|
|
|||
|
###### Example:
|
|||
|
|
|||
|
```bash
|
|||
|
$ sudo dockerd --storage-opt dm.thinp_autoextend_threshold=80
|
|||
|
```
|
|||
|
|
|||
|
##### `dm.thinp_autoextend_percent`
|
|||
|
|
|||
|
Sets the value percentage value to increase the thin pool by when `lvm`
|
|||
|
attempts to autoextend the available space [100 = disabled]
|
|||
|
|
|||
|
###### Example:
|
|||
|
|
|||
|
```bash
|
|||
|
$ sudo dockerd --storage-opt dm.thinp_autoextend_percent=20
|
|||
|
```
|
|||
|
|
|||
|
|
|||
|
##### `dm.basesize`
|
|||
|
|
|||
|
Specifies the size to use when creating the base device, which limits the
|
|||
|
size of images and containers. The default value is 10G. Note, thin devices
|
|||
|
are inherently "sparse", so a 10G device which is mostly empty doesn't use
|
|||
|
10 GB of space on the pool. However, the filesystem will use more space for
|
|||
|
the empty case the larger the device is.
|
|||
|
|
|||
|
The base device size can be increased at daemon restart which will allow
|
|||
|
all future images and containers (based on those new images) to be of the
|
|||
|
new base device size.
|
|||
|
|
|||
|
###### Examples
|
|||
|
|
|||
|
```bash
|
|||
|
$ sudo dockerd --storage-opt dm.basesize=50G
|
|||
|
```
|
|||
|
|
|||
|
This will increase the base device size to 50G. The Docker daemon will throw an
|
|||
|
error if existing base device size is larger than 50G. A user can use
|
|||
|
this option to expand the base device size however shrinking is not permitted.
|
|||
|
|
|||
|
This value affects the system-wide "base" empty filesystem
|
|||
|
that may already be initialized and inherited by pulled images. Typically,
|
|||
|
a change to this value requires additional steps to take effect:
|
|||
|
|
|||
|
```bash
|
|||
|
$ sudo service docker stop
|
|||
|
|
|||
|
$ sudo rm -rf /var/lib/docker
|
|||
|
|
|||
|
$ sudo service docker start
|
|||
|
```
|
|||
|
|
|||
|
|
|||
|
##### `dm.loopdatasize`
|
|||
|
|
|||
|
> **Note**: This option configures devicemapper loopback, which should not
|
|||
|
> be used in production.
|
|||
|
|
|||
|
Specifies the size to use when creating the loopback file for the
|
|||
|
"data" device which is used for the thin pool. The default size is
|
|||
|
100G. The file is sparse, so it will not initially take up this
|
|||
|
much space.
|
|||
|
|
|||
|
###### Example
|
|||
|
|
|||
|
```bash
|
|||
|
$ sudo dockerd --storage-opt dm.loopdatasize=200G
|
|||
|
```
|
|||
|
|
|||
|
##### `dm.loopmetadatasize`
|
|||
|
|
|||
|
> **Note**: This option configures devicemapper loopback, which should not
|
|||
|
> be used in production.
|
|||
|
|
|||
|
Specifies the size to use when creating the loopback file for the
|
|||
|
"metadata" device which is used for the thin pool. The default size
|
|||
|
is 2G. The file is sparse, so it will not initially take up
|
|||
|
this much space.
|
|||
|
|
|||
|
###### Example
|
|||
|
|
|||
|
```bash
|
|||
|
$ sudo dockerd --storage-opt dm.loopmetadatasize=4G
|
|||
|
```
|
|||
|
|
|||
|
##### `dm.fs`
|
|||
|
|
|||
|
Specifies the filesystem type to use for the base device. The supported
|
|||
|
options are "ext4" and "xfs". The default is "xfs"
|
|||
|
|
|||
|
###### Example
|
|||
|
|
|||
|
```bash
|
|||
|
$ sudo dockerd --storage-opt dm.fs=ext4
|
|||
|
```
|
|||
|
|
|||
|
##### `dm.mkfsarg`
|
|||
|
|
|||
|
Specifies extra mkfs arguments to be used when creating the base device.
|
|||
|
|
|||
|
###### Example
|
|||
|
|
|||
|
```bash
|
|||
|
$ sudo dockerd --storage-opt "dm.mkfsarg=-O ^has_journal"
|
|||
|
```
|
|||
|
|
|||
|
##### `dm.mountopt`
|
|||
|
|
|||
|
Specifies extra mount options used when mounting the thin devices.
|
|||
|
|
|||
|
###### Example
|
|||
|
|
|||
|
```bash
|
|||
|
$ sudo dockerd --storage-opt dm.mountopt=nodiscard
|
|||
|
```
|
|||
|
|
|||
|
##### `dm.datadev`
|
|||
|
|
|||
|
(Deprecated, use `dm.thinpooldev`)
|
|||
|
|
|||
|
Specifies a custom blockdevice to use for data for the thin pool.
|
|||
|
|
|||
|
If using a block device for device mapper storage, ideally both `datadev` and
|
|||
|
`metadatadev` should be specified to completely avoid using the loopback
|
|||
|
device.
|
|||
|
|
|||
|
###### Example
|
|||
|
|
|||
|
```bash
|
|||
|
$ sudo dockerd \
|
|||
|
--storage-opt dm.datadev=/dev/sdb1 \
|
|||
|
--storage-opt dm.metadatadev=/dev/sdc1
|
|||
|
```
|
|||
|
|
|||
|
##### `dm.metadatadev`
|
|||
|
|
|||
|
(Deprecated, use `dm.thinpooldev`)
|
|||
|
|
|||
|
Specifies a custom blockdevice to use for metadata for the thin pool.
|
|||
|
|
|||
|
For best performance the metadata should be on a different spindle than the
|
|||
|
data, or even better on an SSD.
|
|||
|
|
|||
|
If setting up a new metadata pool it is required to be valid. This can be
|
|||
|
achieved by zeroing the first 4k to indicate empty metadata, like this:
|
|||
|
|
|||
|
```bash
|
|||
|
$ dd if=/dev/zero of=$metadata_dev bs=4096 count=1
|
|||
|
```
|
|||
|
|
|||
|
###### Example
|
|||
|
|
|||
|
```bash
|
|||
|
$ sudo dockerd \
|
|||
|
--storage-opt dm.datadev=/dev/sdb1 \
|
|||
|
--storage-opt dm.metadatadev=/dev/sdc1
|
|||
|
```
|
|||
|
|
|||
|
##### `dm.blocksize`
|
|||
|
|
|||
|
Specifies a custom blocksize to use for the thin pool. The default
|
|||
|
blocksize is 64K.
|
|||
|
|
|||
|
###### Example
|
|||
|
|
|||
|
```bash
|
|||
|
$ sudo dockerd --storage-opt dm.blocksize=512K
|
|||
|
```
|
|||
|
|
|||
|
##### `dm.blkdiscard`
|
|||
|
|
|||
|
Enables or disables the use of `blkdiscard` when removing devicemapper
|
|||
|
devices. This is enabled by default (only) if using loopback devices and is
|
|||
|
required to resparsify the loopback file on image/container removal.
|
|||
|
|
|||
|
Disabling this on loopback can lead to *much* faster container removal
|
|||
|
times, but will make the space used in `/var/lib/docker` directory not be
|
|||
|
returned to the system for other use when containers are removed.
|
|||
|
|
|||
|
###### Examples
|
|||
|
|
|||
|
```bash
|
|||
|
$ sudo dockerd --storage-opt dm.blkdiscard=false
|
|||
|
```
|
|||
|
|
|||
|
##### `dm.override_udev_sync_check`
|
|||
|
|
|||
|
Overrides the `udev` synchronization checks between `devicemapper` and `udev`.
|
|||
|
`udev` is the device manager for the Linux kernel.
|
|||
|
|
|||
|
To view the `udev` sync support of a Docker daemon that is using the
|
|||
|
`devicemapper` driver, run:
|
|||
|
|
|||
|
```bash
|
|||
|
$ docker info
|
|||
|
[...]
|
|||
|
Udev Sync Supported: true
|
|||
|
[...]
|
|||
|
```
|
|||
|
|
|||
|
When `udev` sync support is `true`, then `devicemapper` and udev can
|
|||
|
coordinate the activation and deactivation of devices for containers.
|
|||
|
|
|||
|
When `udev` sync support is `false`, a race condition occurs between
|
|||
|
the`devicemapper` and `udev` during create and cleanup. The race condition
|
|||
|
results in errors and failures. (For information on these failures, see
|
|||
|
[docker#4036](https://github.com/docker/docker/issues/4036))
|
|||
|
|
|||
|
To allow the `docker` daemon to start, regardless of `udev` sync not being
|
|||
|
supported, set `dm.override_udev_sync_check` to true:
|
|||
|
|
|||
|
```bash
|
|||
|
$ sudo dockerd --storage-opt dm.override_udev_sync_check=true
|
|||
|
```
|
|||
|
|
|||
|
When this value is `true`, the `devicemapper` continues and simply warns
|
|||
|
you the errors are happening.
|
|||
|
|
|||
|
> **Note**: The ideal is to pursue a `docker` daemon and environment that does
|
|||
|
> support synchronizing with `udev`. For further discussion on this
|
|||
|
> topic, see [docker#4036](https://github.com/docker/docker/issues/4036).
|
|||
|
> Otherwise, set this flag for migrating existing Docker daemons to
|
|||
|
> a daemon with a supported environment.
|
|||
|
|
|||
|
##### `dm.use_deferred_removal`
|
|||
|
|
|||
|
Enables use of deferred device removal if `libdm` and the kernel driver
|
|||
|
support the mechanism.
|
|||
|
|
|||
|
Deferred device removal means that if device is busy when devices are
|
|||
|
being removed/deactivated, then a deferred removal is scheduled on
|
|||
|
device. And devices automatically go away when last user of the device
|
|||
|
exits.
|
|||
|
|
|||
|
For example, when a container exits, its associated thin device is removed.
|
|||
|
If that device has leaked into some other mount namespace and can't be
|
|||
|
removed, the container exit still succeeds and this option causes the
|
|||
|
system to schedule the device for deferred removal. It does not wait in a
|
|||
|
loop trying to remove a busy device.
|
|||
|
|
|||
|
###### Example
|
|||
|
|
|||
|
```bash
|
|||
|
$ sudo dockerd --storage-opt dm.use_deferred_removal=true
|
|||
|
```
|
|||
|
|
|||
|
##### `dm.use_deferred_deletion`
|
|||
|
|
|||
|
Enables use of deferred device deletion for thin pool devices. By default,
|
|||
|
thin pool device deletion is synchronous. Before a container is deleted,
|
|||
|
the Docker daemon removes any associated devices. If the storage driver
|
|||
|
can not remove a device, the container deletion fails and daemon returns.
|
|||
|
|
|||
|
```none
|
|||
|
Error deleting container: Error response from daemon: Cannot destroy container
|
|||
|
```
|
|||
|
|
|||
|
To avoid this failure, enable both deferred device deletion and deferred
|
|||
|
device removal on the daemon.
|
|||
|
|
|||
|
```bash
|
|||
|
$ sudo dockerd \
|
|||
|
--storage-opt dm.use_deferred_deletion=true \
|
|||
|
--storage-opt dm.use_deferred_removal=true
|
|||
|
```
|
|||
|
|
|||
|
With these two options enabled, if a device is busy when the driver is
|
|||
|
deleting a container, the driver marks the device as deleted. Later, when
|
|||
|
the device isn't in use, the driver deletes it.
|
|||
|
|
|||
|
In general it should be safe to enable this option by default. It will help
|
|||
|
when unintentional leaking of mount point happens across multiple mount
|
|||
|
namespaces.
|
|||
|
|
|||
|
##### `dm.min_free_space`
|
|||
|
|
|||
|
Specifies the min free space percent in a thin pool require for new device
|
|||
|
creation to succeed. This check applies to both free data space as well
|
|||
|
as free metadata space. Valid values are from 0% - 99%. Value 0% disables
|
|||
|
free space checking logic. If user does not specify a value for this option,
|
|||
|
the Engine uses a default value of 10%.
|
|||
|
|
|||
|
Whenever a new a thin pool device is created (during `docker pull` or during
|
|||
|
container creation), the Engine checks if the minimum free space is
|
|||
|
available. If sufficient space is unavailable, then device creation fails
|
|||
|
and any relevant `docker` operation fails.
|
|||
|
|
|||
|
To recover from this error, you must create more free space in the thin pool
|
|||
|
to recover from the error. You can create free space by deleting some images
|
|||
|
and containers from the thin pool. You can also add more storage to the thin
|
|||
|
pool.
|
|||
|
|
|||
|
To add more space to a LVM (logical volume management) thin pool, just add
|
|||
|
more storage to the volume group container thin pool; this should automatically
|
|||
|
resolve any errors. If your configuration uses loop devices, then stop the
|
|||
|
Engine daemon, grow the size of loop files and restart the daemon to resolve
|
|||
|
the issue.
|
|||
|
|
|||
|
###### Example
|
|||
|
|
|||
|
```bash
|
|||
|
$ sudo dockerd --storage-opt dm.min_free_space=10%
|
|||
|
```
|
|||
|
|
|||
|
##### `dm.xfs_nospace_max_retries`
|
|||
|
|
|||
|
Specifies the maximum number of retries XFS should attempt to complete
|
|||
|
IO when ENOSPC (no space) error is returned by underlying storage device.
|
|||
|
|
|||
|
By default XFS retries infinitely for IO to finish and this can result
|
|||
|
in unkillable process. To change this behavior one can set
|
|||
|
xfs_nospace_max_retries to say 0 and XFS will not retry IO after getting
|
|||
|
ENOSPC and will shutdown filesystem.
|
|||
|
|
|||
|
###### Example
|
|||
|
|
|||
|
```bash
|
|||
|
$ sudo dockerd --storage-opt dm.xfs_nospace_max_retries=0
|
|||
|
```
|
|||
|
|
|||
|
##### `dm.libdm_log_level`
|
|||
|
|
|||
|
Specifies the maxmimum `libdm` log level that will be forwarded to the
|
|||
|
`dockerd` log (as specified by `--log-level`). This option is primarily
|
|||
|
intended for debugging problems involving `libdm`. Using values other than the
|
|||
|
defaults may cause false-positive warnings to be logged.
|
|||
|
|
|||
|
Values specified must fall within the range of valid `libdm` log levels. At the
|
|||
|
time of writing, the following is the list of `libdm` log levels as well as
|
|||
|
their corresponding levels when output by `dockerd`.
|
|||
|
|
|||
|
| `libdm` Level | Value | `--log-level` |
|
|||
|
| ------------- | -----:| ------------- |
|
|||
|
| `_LOG_FATAL` | 2 | error |
|
|||
|
| `_LOG_ERR` | 3 | error |
|
|||
|
| `_LOG_WARN` | 4 | warn |
|
|||
|
| `_LOG_NOTICE` | 5 | info |
|
|||
|
| `_LOG_INFO` | 6 | info |
|
|||
|
| `_LOG_DEBUG` | 7 | debug |
|
|||
|
|
|||
|
###### Example
|
|||
|
|
|||
|
```bash
|
|||
|
$ sudo dockerd \
|
|||
|
--log-level debug \
|
|||
|
--storage-opt dm.libdm_log_level=7
|
|||
|
```
|
|||
|
|
|||
|
#### ZFS options
|
|||
|
|
|||
|
##### `zfs.fsname`
|
|||
|
|
|||
|
Set zfs filesystem under which docker will create its own datasets.
|
|||
|
By default docker will pick up the zfs filesystem where docker graph
|
|||
|
(`/var/lib/docker`) is located.
|
|||
|
|
|||
|
###### Example
|
|||
|
|
|||
|
```bash
|
|||
|
$ sudo dockerd -s zfs --storage-opt zfs.fsname=zroot/docker
|
|||
|
```
|
|||
|
|
|||
|
#### Btrfs options
|
|||
|
|
|||
|
##### `btrfs.min_space`
|
|||
|
|
|||
|
Specifies the minimum size to use when creating the subvolume which is used
|
|||
|
for containers. If user uses disk quota for btrfs when creating or running
|
|||
|
a container with **--storage-opt size** option, docker should ensure the
|
|||
|
**size** cannot be smaller than **btrfs.min_space**.
|
|||
|
|
|||
|
###### Example
|
|||
|
|
|||
|
```bash
|
|||
|
$ sudo dockerd -s btrfs --storage-opt btrfs.min_space=10G
|
|||
|
```
|
|||
|
|
|||
|
#### Overlay2 options
|
|||
|
|
|||
|
##### `overlay2.override_kernel_check`
|
|||
|
|
|||
|
Overrides the Linux kernel version check allowing overlay2. Support for
|
|||
|
specifying multiple lower directories needed by overlay2 was added to the
|
|||
|
Linux kernel in 4.0.0. However, some older kernel versions may be patched
|
|||
|
to add multiple lower directory support for OverlayFS. This option should
|
|||
|
only be used after verifying this support exists in the kernel. Applying
|
|||
|
this option on a kernel without this support will cause failures on mount.
|
|||
|
|
|||
|
##### `overlay2.size`
|
|||
|
|
|||
|
Sets the default max size of the container. It is supported only when the
|
|||
|
backing fs is `xfs` and mounted with `pquota` mount option. Under these
|
|||
|
conditions the user can pass any size less then the backing fs size.
|
|||
|
|
|||
|
###### Example
|
|||
|
|
|||
|
```bash
|
|||
|
$ sudo dockerd -s overlay2 --storage-opt overlay2.size=1G
|
|||
|
```
|
|||
|
|
|||
|
|
|||
|
#### Windowsfilter options
|
|||
|
|
|||
|
##### `size`
|
|||
|
|
|||
|
Specifies the size to use when creating the sandbox which is used for containers.
|
|||
|
Defaults to 20G.
|
|||
|
|
|||
|
###### Example
|
|||
|
|
|||
|
```PowerShell
|
|||
|
C:\> dockerd --storage-opt size=40G
|
|||
|
```
|
|||
|
|
|||
|
#### LCOW (Linux Containers on Windows) options
|
|||
|
|
|||
|
##### `lcow.globalmode`
|
|||
|
|
|||
|
Specifies whether the daemon instantiates utility VM instances as required
|
|||
|
(recommended and default if omitted), or uses single global utility VM (better
|
|||
|
performance, but has security implications and not recommended for production
|
|||
|
deployments).
|
|||
|
|
|||
|
###### Example
|
|||
|
|
|||
|
```PowerShell
|
|||
|
C:\> dockerd --storage-opt lcow.globalmode=false
|
|||
|
```
|
|||
|
|
|||
|
##### `lcow.kirdpath`
|
|||
|
|
|||
|
Specifies the folder path to the location of a pair of kernel and initrd files
|
|||
|
used for booting a utility VM. Defaults to `%ProgramFiles%\Linux Containers`.
|
|||
|
|
|||
|
###### Example
|
|||
|
|
|||
|
```PowerShell
|
|||
|
C:\> dockerd --storage-opt lcow.kirdpath=c:\path\to\files
|
|||
|
```
|
|||
|
|
|||
|
##### `lcow.kernel`
|
|||
|
|
|||
|
Specifies the filename of a kernel file located in the `lcow.kirdpath` path.
|
|||
|
Defaults to `bootx64.efi`.
|
|||
|
|
|||
|
###### Example
|
|||
|
|
|||
|
```PowerShell
|
|||
|
C:\> dockerd --storage-opt lcow.kernel=kernel.efi
|
|||
|
```
|
|||
|
|
|||
|
##### `lcow.initrd`
|
|||
|
|
|||
|
Specifies the filename of an initrd file located in the `lcow.kirdpath` path.
|
|||
|
Defaults to `initrd.img`.
|
|||
|
|
|||
|
###### Example
|
|||
|
|
|||
|
```PowerShell
|
|||
|
C:\> dockerd --storage-opt lcow.initrd=myinitrd.img
|
|||
|
```
|
|||
|
|
|||
|
##### `lcow.bootparameters`
|
|||
|
|
|||
|
Specifies additional boot parameters for booting utility VMs when in kernel/
|
|||
|
initrd mode. Ignored if the utility VM is booting from VHD. These settings
|
|||
|
are kernel specific.
|
|||
|
|
|||
|
###### Example
|
|||
|
|
|||
|
```PowerShell
|
|||
|
C:\> dockerd --storage-opt "lcow.bootparameters='option=value'"
|
|||
|
```
|
|||
|
|
|||
|
##### `lcow.vhdx`
|
|||
|
|
|||
|
Specifies a custom VHDX to boot a utility VM, as an alternate to kernel
|
|||
|
and initrd booting. Defaults to `uvm.vhdx` under `lcow.kirdpath`.
|
|||
|
|
|||
|
###### Example
|
|||
|
|
|||
|
```PowerShell
|
|||
|
C:\> dockerd --storage-opt lcow.vhdx=custom.vhdx
|
|||
|
```
|
|||
|
|
|||
|
##### `lcow.timeout`
|
|||
|
|
|||
|
Specifies the timeout for utility VM operations in seconds. Defaults
|
|||
|
to 300.
|
|||
|
|
|||
|
###### Example
|
|||
|
|
|||
|
```PowerShell
|
|||
|
C:\> dockerd --storage-opt lcow.timeout=240
|
|||
|
```
|
|||
|
|
|||
|
##### `lcow.sandboxsize`
|
|||
|
|
|||
|
Specifies the size in GB to use when creating the sandbox which is used for
|
|||
|
containers. Defaults to 20. Cannot be less than 20.
|
|||
|
|
|||
|
###### Example
|
|||
|
|
|||
|
```PowerShell
|
|||
|
C:\> dockerd --storage-opt lcow.sandboxsize=40
|
|||
|
```
|
|||
|
|
|||
|
### Docker runtime execution options
|
|||
|
|
|||
|
The Docker daemon relies on a
|
|||
|
[OCI](https://github.com/opencontainers/runtime-spec) compliant runtime
|
|||
|
(invoked via the `containerd` daemon) as its interface to the Linux
|
|||
|
kernel `namespaces`, `cgroups`, and `SELinux`.
|
|||
|
|
|||
|
By default, the Docker daemon automatically starts `containerd`. If you want to
|
|||
|
control `containerd` startup, manually start `containerd` and pass the path to
|
|||
|
the `containerd` socket using the `--containerd` flag. For example:
|
|||
|
|
|||
|
```bash
|
|||
|
$ sudo dockerd --containerd /var/run/dev/docker-containerd.sock
|
|||
|
```
|
|||
|
|
|||
|
Runtimes can be registered with the daemon either via the
|
|||
|
configuration file or using the `--add-runtime` command line argument.
|
|||
|
|
|||
|
The following is an example adding 2 runtimes via the configuration:
|
|||
|
|
|||
|
```json
|
|||
|
{
|
|||
|
"default-runtime": "runc",
|
|||
|
"runtimes": {
|
|||
|
"runc": {
|
|||
|
"path": "runc"
|
|||
|
},
|
|||
|
"custom": {
|
|||
|
"path": "/usr/local/bin/my-runc-replacement",
|
|||
|
"runtimeArgs": [
|
|||
|
"--debug"
|
|||
|
]
|
|||
|
}
|
|||
|
}
|
|||
|
}
|
|||
|
```
|
|||
|
|
|||
|
This is the same example via the command line:
|
|||
|
|
|||
|
```bash
|
|||
|
$ sudo dockerd --add-runtime runc=runc --add-runtime custom=/usr/local/bin/my-runc-replacement
|
|||
|
```
|
|||
|
|
|||
|
> **Note**: Defining runtime arguments via the command line is not supported.
|
|||
|
|
|||
|
#### Options for the runtime
|
|||
|
|
|||
|
You can configure the runtime using options specified
|
|||
|
with the `--exec-opt` flag. All the flag's options have the `native` prefix. A
|
|||
|
single `native.cgroupdriver` option is available.
|
|||
|
|
|||
|
The `native.cgroupdriver` option specifies the management of the container's
|
|||
|
cgroups. You can only specify `cgroupfs` or `systemd`. If you specify
|
|||
|
`systemd` and it is not available, the system errors out. If you omit the
|
|||
|
`native.cgroupdriver` option,` cgroupfs` is used.
|
|||
|
|
|||
|
This example sets the `cgroupdriver` to `systemd`:
|
|||
|
|
|||
|
```bash
|
|||
|
$ sudo dockerd --exec-opt native.cgroupdriver=systemd
|
|||
|
```
|
|||
|
|
|||
|
Setting this option applies to all containers the daemon launches.
|
|||
|
|
|||
|
Also Windows Container makes use of `--exec-opt` for special purpose. Docker user
|
|||
|
can specify default container isolation technology with this, for example:
|
|||
|
|
|||
|
```console
|
|||
|
> dockerd --exec-opt isolation=hyperv
|
|||
|
```
|
|||
|
|
|||
|
Will make `hyperv` the default isolation technology on Windows. If no isolation
|
|||
|
value is specified on daemon start, on Windows client, the default is
|
|||
|
`hyperv`, and on Windows server, the default is `process`.
|
|||
|
|
|||
|
### Daemon DNS options
|
|||
|
|
|||
|
To set the DNS server for all Docker containers, use:
|
|||
|
|
|||
|
```bash
|
|||
|
$ sudo dockerd --dns 8.8.8.8
|
|||
|
```
|
|||
|
|
|||
|
To set the DNS search domain for all Docker containers, use:
|
|||
|
|
|||
|
```bash
|
|||
|
$ sudo dockerd --dns-search example.com
|
|||
|
```
|
|||
|
|
|||
|
### Allow push of nondistributable artifacts
|
|||
|
|
|||
|
Some images (e.g., Windows base images) contain artifacts whose distribution is
|
|||
|
restricted by license. When these images are pushed to a registry, restricted
|
|||
|
artifacts are not included.
|
|||
|
|
|||
|
To override this behavior for specific registries, use the
|
|||
|
`--allow-nondistributable-artifacts` option in one of the following forms:
|
|||
|
|
|||
|
* `--allow-nondistributable-artifacts myregistry:5000` tells the Docker daemon
|
|||
|
to push nondistributable artifacts to myregistry:5000.
|
|||
|
* `--allow-nondistributable-artifacts 10.1.0.0/16` tells the Docker daemon to
|
|||
|
push nondistributable artifacts to all registries whose resolved IP address
|
|||
|
is within the subnet described by the CIDR syntax.
|
|||
|
|
|||
|
This option can be used multiple times.
|
|||
|
|
|||
|
This option is useful when pushing images containing nondistributable artifacts
|
|||
|
to a registry on an air-gapped network so hosts on that network can pull the
|
|||
|
images without connecting to another server.
|
|||
|
|
|||
|
> **Warning**: Nondistributable artifacts typically have restrictions on how
|
|||
|
> and where they can be distributed and shared. Only use this feature to push
|
|||
|
> artifacts to private registries and ensure that you are in compliance with
|
|||
|
> any terms that cover redistributing nondistributable artifacts.
|
|||
|
|
|||
|
### Insecure registries
|
|||
|
|
|||
|
Docker considers a private registry either secure or insecure. In the rest of
|
|||
|
this section, *registry* is used for *private registry*, and `myregistry:5000`
|
|||
|
is a placeholder example for a private registry.
|
|||
|
|
|||
|
A secure registry uses TLS and a copy of its CA certificate is placed on the
|
|||
|
Docker host at `/etc/docker/certs.d/myregistry:5000/ca.crt`. An insecure
|
|||
|
registry is either not using TLS (i.e., listening on plain text HTTP), or is
|
|||
|
using TLS with a CA certificate not known by the Docker daemon. The latter can
|
|||
|
happen when the certificate was not found under
|
|||
|
`/etc/docker/certs.d/myregistry:5000/`, or if the certificate verification
|
|||
|
failed (i.e., wrong CA).
|
|||
|
|
|||
|
By default, Docker assumes all, but local (see local registries below),
|
|||
|
registries are secure. Communicating with an insecure registry is not possible
|
|||
|
if Docker assumes that registry is secure. In order to communicate with an
|
|||
|
insecure registry, the Docker daemon requires `--insecure-registry` in one of
|
|||
|
the following two forms:
|
|||
|
|
|||
|
* `--insecure-registry myregistry:5000` tells the Docker daemon that
|
|||
|
myregistry:5000 should be considered insecure.
|
|||
|
* `--insecure-registry 10.1.0.0/16` tells the Docker daemon that all registries
|
|||
|
whose domain resolve to an IP address is part of the subnet described by the
|
|||
|
CIDR syntax, should be considered insecure.
|
|||
|
|
|||
|
The flag can be used multiple times to allow multiple registries to be marked
|
|||
|
as insecure.
|
|||
|
|
|||
|
If an insecure registry is not marked as insecure, `docker pull`,
|
|||
|
`docker push`, and `docker search` will result in an error message prompting
|
|||
|
the user to either secure or pass the `--insecure-registry` flag to the Docker
|
|||
|
daemon as described above.
|
|||
|
|
|||
|
Local registries, whose IP address falls in the 127.0.0.0/8 range, are
|
|||
|
automatically marked as insecure as of Docker 1.3.2. It is not recommended to
|
|||
|
rely on this, as it may change in the future.
|
|||
|
|
|||
|
Enabling `--insecure-registry`, i.e., allowing un-encrypted and/or untrusted
|
|||
|
communication, can be useful when running a local registry. However,
|
|||
|
because its use creates security vulnerabilities it should ONLY be enabled for
|
|||
|
testing purposes. For increased security, users should add their CA to their
|
|||
|
system's list of trusted CAs instead of enabling `--insecure-registry`.
|
|||
|
|
|||
|
#### Legacy Registries
|
|||
|
|
|||
|
Starting with Docker 17.12, operations against registries supporting only the
|
|||
|
legacy v1 protocol are no longer supported. 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.
|
|||
|
|
|||
|
The `disable-legacy-registry` configuration option has been removed and, when
|
|||
|
used, will produce an error on daemon startup.
|
|||
|
|
|||
|
|
|||
|
### Running a Docker daemon behind an HTTPS_PROXY
|
|||
|
|
|||
|
When running inside a LAN that uses an `HTTPS` proxy, the Docker Hub
|
|||
|
certificates will be replaced by the proxy's certificates. These certificates
|
|||
|
need to be added to your Docker host's configuration:
|
|||
|
|
|||
|
1. Install the `ca-certificates` package for your distribution
|
|||
|
2. Ask your network admin for the proxy's CA certificate and append them to
|
|||
|
`/etc/pki/tls/certs/ca-bundle.crt`
|
|||
|
3. Then start your Docker daemon with `HTTPS_PROXY=http://username:password@proxy:port/ dockerd`.
|
|||
|
The `username:` and `password@` are optional - and are only needed if your
|
|||
|
proxy is set up to require authentication.
|
|||
|
|
|||
|
This will only add the proxy and authentication to the Docker daemon's requests -
|
|||
|
your `docker build`s and running containers will need extra configuration to
|
|||
|
use the proxy
|
|||
|
|
|||
|
### Default `ulimit` settings
|
|||
|
|
|||
|
`--default-ulimit` allows you to set the default `ulimit` options to use for
|
|||
|
all containers. It takes the same options as `--ulimit` for `docker run`. If
|
|||
|
these defaults are not set, `ulimit` settings will be inherited, if not set on
|
|||
|
`docker run`, from the Docker daemon. Any `--ulimit` options passed to
|
|||
|
`docker run` will overwrite these defaults.
|
|||
|
|
|||
|
Be careful setting `nproc` with the `ulimit` flag as `nproc` is designed by Linux to
|
|||
|
set the maximum number of processes available to a user, not to a container. For details
|
|||
|
please check the [run](run.md) reference.
|
|||
|
|
|||
|
### Node discovery
|
|||
|
|
|||
|
The `--cluster-advertise` option specifies the `host:port` or `interface:port`
|
|||
|
combination that this particular daemon instance should use when advertising
|
|||
|
itself to the cluster. The daemon is reached by remote hosts through this value.
|
|||
|
If you specify an interface, make sure it includes the IP address of the actual
|
|||
|
Docker host. For Engine installation created through `docker-machine`, the
|
|||
|
interface is typically `eth1`.
|
|||
|
|
|||
|
The daemon uses [libkv](https://github.com/docker/libkv/) to advertise
|
|||
|
the node within the cluster. Some key-value backends support mutual
|
|||
|
TLS. To configure the client TLS settings used by the daemon can be configured
|
|||
|
using the `--cluster-store-opt` flag, specifying the paths to PEM encoded
|
|||
|
files. For example:
|
|||
|
|
|||
|
```bash
|
|||
|
$ sudo dockerd \
|
|||
|
--cluster-advertise 192.168.1.2:2376 \
|
|||
|
--cluster-store etcd://192.168.1.2:2379 \
|
|||
|
--cluster-store-opt kv.cacertfile=/path/to/ca.pem \
|
|||
|
--cluster-store-opt kv.certfile=/path/to/cert.pem \
|
|||
|
--cluster-store-opt kv.keyfile=/path/to/key.pem
|
|||
|
```
|
|||
|
|
|||
|
The currently supported cluster store options are:
|
|||
|
|
|||
|
| Option | Description |
|
|||
|
|:----------------------|:------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
|
|||
|
| `discovery.heartbeat` | Specifies the heartbeat timer in seconds which is used by the daemon as a `keepalive` mechanism to make sure discovery module treats the node as alive in the cluster. If not configured, the default value is 20 seconds. |
|
|||
|
| `discovery.ttl` | Specifies the TTL (time-to-live) in seconds which is used by the discovery module to timeout a node if a valid heartbeat is not received within the configured ttl value. If not configured, the default value is 60 seconds. |
|
|||
|
| `kv.cacertfile` | Specifies the path to a local file with PEM encoded CA certificates to trust. |
|
|||
|
| `kv.certfile` | Specifies the path to a local file with a PEM encoded certificate. This certificate is used as the client cert for communication with the Key/Value store. |
|
|||
|
| `kv.keyfile` | Specifies the path to a local file with a PEM encoded private key. This private key is used as the client key for communication with the Key/Value store. |
|
|||
|
| `kv.path` | Specifies the path in the Key/Value store. If not configured, the default value is 'docker/nodes'. |
|
|||
|
|
|||
|
### Access authorization
|
|||
|
|
|||
|
Docker's access authorization can be extended by authorization plugins that your
|
|||
|
organization can purchase or build themselves. You can install one or more
|
|||
|
authorization plugins when you start the Docker `daemon` using the
|
|||
|
`--authorization-plugin=PLUGIN_ID` option.
|
|||
|
|
|||
|
```bash
|
|||
|
$ sudo dockerd --authorization-plugin=plugin1 --authorization-plugin=plugin2,...
|
|||
|
```
|
|||
|
|
|||
|
The `PLUGIN_ID` value is either the plugin's name or a path to its specification
|
|||
|
file. The plugin's implementation determines whether you can specify a name or
|
|||
|
path. Consult with your Docker administrator to get information about the
|
|||
|
plugins available to you.
|
|||
|
|
|||
|
Once a plugin is installed, requests made to the `daemon` through the
|
|||
|
command line or Docker's Engine API are allowed or denied by the plugin.
|
|||
|
If you have multiple plugins installed, each plugin, in order, must
|
|||
|
allow the request for it to complete.
|
|||
|
|
|||
|
For information about how to create an authorization plugin, see [authorization
|
|||
|
plugin](../../extend/plugins_authorization.md) section in the Docker extend section of this documentation.
|
|||
|
|
|||
|
|
|||
|
### Daemon user namespace options
|
|||
|
|
|||
|
The Linux kernel
|
|||
|
[user namespace support](http://man7.org/linux/man-pages/man7/user_namespaces.7.html)
|
|||
|
provides additional security by enabling a process, and therefore a container,
|
|||
|
to have a unique range of user and group IDs which are outside the traditional
|
|||
|
user and group range utilized by the host system. Potentially the most important
|
|||
|
security improvement is that, by default, container processes running as the
|
|||
|
`root` user will have expected administrative privilege (with some restrictions)
|
|||
|
inside the container but will effectively be mapped to an unprivileged `uid` on
|
|||
|
the host.
|
|||
|
|
|||
|
For details about how to use this feature, as well as limitations, see
|
|||
|
[Isolate containers with a user namespace](https://docs.docker.com/engine/security/userns-remap/).
|
|||
|
|
|||
|
### Miscellaneous options
|
|||
|
|
|||
|
IP masquerading uses address translation to allow containers without a public
|
|||
|
IP to talk to other machines on the Internet. This may interfere with some
|
|||
|
network topologies and can be disabled with `--ip-masq=false`.
|
|||
|
|
|||
|
Docker supports softlinks for the Docker data directory (`/var/lib/docker`) and
|
|||
|
for `/var/lib/docker/tmp`. The `DOCKER_TMPDIR` and the data directory can be
|
|||
|
set like this:
|
|||
|
|
|||
|
DOCKER_TMPDIR=/mnt/disk2/tmp /usr/local/bin/dockerd -D -g /var/lib/docker -H unix:// > /var/lib/docker-machine/docker.log 2>&1
|
|||
|
# or
|
|||
|
export DOCKER_TMPDIR=/mnt/disk2/tmp
|
|||
|
/usr/local/bin/dockerd -D -g /var/lib/docker -H unix:// > /var/lib/docker-machine/docker.log 2>&1
|
|||
|
|
|||
|
#### Default cgroup parent
|
|||
|
|
|||
|
The `--cgroup-parent` option allows you to set the default cgroup parent
|
|||
|
to use for containers. If this option is not set, it defaults to `/docker` for
|
|||
|
fs cgroup driver and `system.slice` for systemd cgroup driver.
|
|||
|
|
|||
|
If the cgroup has a leading forward slash (`/`), the cgroup is created
|
|||
|
under the root cgroup, otherwise the cgroup is created under the daemon
|
|||
|
cgroup.
|
|||
|
|
|||
|
Assuming the daemon is running in cgroup `daemoncgroup`,
|
|||
|
`--cgroup-parent=/foobar` creates a cgroup in
|
|||
|
`/sys/fs/cgroup/memory/foobar`, whereas using `--cgroup-parent=foobar`
|
|||
|
creates the cgroup in `/sys/fs/cgroup/memory/daemoncgroup/foobar`
|
|||
|
|
|||
|
The systemd cgroup driver has different rules for `--cgroup-parent`. Systemd
|
|||
|
represents hierarchy by slice and the name of the slice encodes the location in
|
|||
|
the tree. So `--cgroup-parent` for systemd cgroups should be a slice name. A
|
|||
|
name can consist of a dash-separated series of names, which describes the path
|
|||
|
to the slice from the root slice. For example, `--cgroup-parent=user-a-b.slice`
|
|||
|
means the memory cgroup for the container is created in
|
|||
|
`/sys/fs/cgroup/memory/user.slice/user-a.slice/user-a-b.slice/docker-<id>.scope`.
|
|||
|
|
|||
|
This setting can also be set per container, using the `--cgroup-parent`
|
|||
|
option on `docker create` and `docker run`, and takes precedence over
|
|||
|
the `--cgroup-parent` option on the daemon.
|
|||
|
|
|||
|
#### Daemon metrics
|
|||
|
|
|||
|
The `--metrics-addr` option takes a tcp address to serve the metrics API.
|
|||
|
This feature is still experimental, therefore, the daemon must be running in experimental
|
|||
|
mode for this feature to work.
|
|||
|
|
|||
|
To serve the metrics API on localhost:1337 you would specify `--metrics-addr 127.0.0.1:1337`
|
|||
|
allowing you to make requests on the API at `127.0.0.1:1337/metrics` to receive metrics in the
|
|||
|
[prometheus](https://prometheus.io/docs/instrumenting/exposition_formats/) format.
|
|||
|
|
|||
|
If you are running a prometheus server you can add this address to your scrape configs
|
|||
|
to have prometheus collect metrics on Docker. For more information
|
|||
|
on prometheus you can view the website [here](https://prometheus.io/).
|
|||
|
|
|||
|
```none
|
|||
|
scrape_configs:
|
|||
|
- job_name: 'docker'
|
|||
|
static_configs:
|
|||
|
- targets: ['127.0.0.1:1337']
|
|||
|
```
|
|||
|
|
|||
|
Please note that this feature is still marked as experimental as metrics and metric
|
|||
|
names could change while this feature is still in experimental. Please provide
|
|||
|
feedback on what you would like to see collected in the API.
|
|||
|
|
|||
|
#### Node Generic Resources
|
|||
|
|
|||
|
The `--node-generic-resources` option takes a list of key-value
|
|||
|
pair (`key=value`) that allows you to advertise user defined resources
|
|||
|
in a swarm cluster.
|
|||
|
|
|||
|
The current expected use case is to advertise NVIDIA GPUs so that services
|
|||
|
requesting `NVIDIA-GPU=[0-16]` can land on a node that has enough GPUs for
|
|||
|
the task to run.
|
|||
|
|
|||
|
Example of usage:
|
|||
|
```json
|
|||
|
{
|
|||
|
"node-generic-resources": ["NVIDIA-GPU=UUID1", "NVIDIA-GPU=UUID2"]
|
|||
|
}
|
|||
|
```
|
|||
|
|
|||
|
### Daemon configuration file
|
|||
|
|
|||
|
The `--config-file` option allows you to set any configuration option
|
|||
|
for the daemon in a JSON format. This file uses the same flag names as keys,
|
|||
|
except for flags that allow several entries, where it uses the plural
|
|||
|
of the flag name, e.g., `labels` for the `label` flag.
|
|||
|
|
|||
|
The options set in the configuration file must not conflict with options set
|
|||
|
via flags. The docker daemon fails to start if an option is duplicated between
|
|||
|
the file and the flags, regardless their value. We do this to avoid
|
|||
|
silently ignore changes introduced in configuration reloads.
|
|||
|
For example, the daemon fails to start if you set daemon labels
|
|||
|
in the configuration file and also set daemon labels via the `--label` flag.
|
|||
|
Options that are not present in the file are ignored when the daemon starts.
|
|||
|
|
|||
|
##### On Linux
|
|||
|
|
|||
|
The default location of the configuration file on Linux is
|
|||
|
`/etc/docker/daemon.json`. The `--config-file` flag can be used to specify a
|
|||
|
non-default location.
|
|||
|
|
|||
|
This is a full example of the allowed configuration options on Linux:
|
|||
|
|
|||
|
```json
|
|||
|
{
|
|||
|
"authorization-plugins": [],
|
|||
|
"data-root": "",
|
|||
|
"dns": [],
|
|||
|
"dns-opts": [],
|
|||
|
"dns-search": [],
|
|||
|
"exec-opts": [],
|
|||
|
"exec-root": "",
|
|||
|
"experimental": false,
|
|||
|
"storage-driver": "",
|
|||
|
"storage-opts": [],
|
|||
|
"labels": [],
|
|||
|
"live-restore": true,
|
|||
|
"log-driver": "",
|
|||
|
"log-opts": {},
|
|||
|
"mtu": 0,
|
|||
|
"pidfile": "",
|
|||
|
"cluster-store": "",
|
|||
|
"cluster-store-opts": {},
|
|||
|
"cluster-advertise": "",
|
|||
|
"max-concurrent-downloads": 3,
|
|||
|
"max-concurrent-uploads": 5,
|
|||
|
"default-shm-size": "64M",
|
|||
|
"shutdown-timeout": 15,
|
|||
|
"debug": true,
|
|||
|
"hosts": [],
|
|||
|
"log-level": "",
|
|||
|
"tls": true,
|
|||
|
"tlsverify": true,
|
|||
|
"tlscacert": "",
|
|||
|
"tlscert": "",
|
|||
|
"tlskey": "",
|
|||
|
"swarm-default-advertise-addr": "",
|
|||
|
"api-cors-header": "",
|
|||
|
"selinux-enabled": false,
|
|||
|
"userns-remap": "",
|
|||
|
"group": "",
|
|||
|
"cgroup-parent": "",
|
|||
|
"default-ulimits": {},
|
|||
|
"init": false,
|
|||
|
"init-path": "/usr/libexec/docker-init",
|
|||
|
"ipv6": false,
|
|||
|
"iptables": false,
|
|||
|
"ip-forward": false,
|
|||
|
"ip-masq": false,
|
|||
|
"userland-proxy": false,
|
|||
|
"userland-proxy-path": "/usr/libexec/docker-proxy",
|
|||
|
"ip": "0.0.0.0",
|
|||
|
"bridge": "",
|
|||
|
"bip": "",
|
|||
|
"fixed-cidr": "",
|
|||
|
"fixed-cidr-v6": "",
|
|||
|
"default-gateway": "",
|
|||
|
"default-gateway-v6": "",
|
|||
|
"icc": false,
|
|||
|
"raw-logs": false,
|
|||
|
"allow-nondistributable-artifacts": [],
|
|||
|
"registry-mirrors": [],
|
|||
|
"seccomp-profile": "",
|
|||
|
"insecure-registries": [],
|
|||
|
"no-new-privileges": false,
|
|||
|
"default-runtime": "runc",
|
|||
|
"oom-score-adjust": -500,
|
|||
|
"node-generic-resources": ["NVIDIA-GPU=UUID1", "NVIDIA-GPU=UUID2"],
|
|||
|
"runtimes": {
|
|||
|
"cc-runtime": {
|
|||
|
"path": "/usr/bin/cc-runtime"
|
|||
|
},
|
|||
|
"custom": {
|
|||
|
"path": "/usr/local/bin/my-runc-replacement",
|
|||
|
"runtimeArgs": [
|
|||
|
"--debug"
|
|||
|
]
|
|||
|
}
|
|||
|
}
|
|||
|
}
|
|||
|
```
|
|||
|
|
|||
|
> **Note:** You cannot set options in `daemon.json` that have already been set on
|
|||
|
> daemon startup as a flag.
|
|||
|
> On systems that use `systemd` to start the Docker daemon, `-H` is already set, so
|
|||
|
> you cannot use the `hosts` key in `daemon.json` to add listening addresses.
|
|||
|
> See https://docs.docker.com/engine/admin/systemd/#custom-docker-daemon-options for how
|
|||
|
> to accomplish this task with a systemd drop-in file.
|
|||
|
|
|||
|
##### On Windows
|
|||
|
|
|||
|
The default location of the configuration file on Windows is
|
|||
|
`%programdata%\docker\config\daemon.json`. The `--config-file` flag can be
|
|||
|
used to specify a non-default location.
|
|||
|
|
|||
|
This is a full example of the allowed configuration options on Windows:
|
|||
|
|
|||
|
```json
|
|||
|
{
|
|||
|
"authorization-plugins": [],
|
|||
|
"data-root": "",
|
|||
|
"dns": [],
|
|||
|
"dns-opts": [],
|
|||
|
"dns-search": [],
|
|||
|
"exec-opts": [],
|
|||
|
"experimental": false,
|
|||
|
"storage-driver": "",
|
|||
|
"storage-opts": [],
|
|||
|
"labels": [],
|
|||
|
"log-driver": "",
|
|||
|
"mtu": 0,
|
|||
|
"pidfile": "",
|
|||
|
"cluster-store": "",
|
|||
|
"cluster-advertise": "",
|
|||
|
"max-concurrent-downloads": 3,
|
|||
|
"max-concurrent-uploads": 5,
|
|||
|
"shutdown-timeout": 15,
|
|||
|
"debug": true,
|
|||
|
"hosts": [],
|
|||
|
"log-level": "",
|
|||
|
"tlsverify": true,
|
|||
|
"tlscacert": "",
|
|||
|
"tlscert": "",
|
|||
|
"tlskey": "",
|
|||
|
"swarm-default-advertise-addr": "",
|
|||
|
"group": "",
|
|||
|
"default-ulimits": {},
|
|||
|
"bridge": "",
|
|||
|
"fixed-cidr": "",
|
|||
|
"raw-logs": false,
|
|||
|
"allow-nondistributable-artifacts": [],
|
|||
|
"registry-mirrors": [],
|
|||
|
"insecure-registries": []
|
|||
|
}
|
|||
|
```
|
|||
|
|
|||
|
#### Configuration reload behavior
|
|||
|
|
|||
|
Some options can be reconfigured when the daemon is running without requiring
|
|||
|
to restart the process. We use the `SIGHUP` signal in Linux to reload, and a global event
|
|||
|
in Windows with the key `Global\docker-daemon-config-$PID`. The options can
|
|||
|
be modified in the configuration file but still will check for conflicts with
|
|||
|
the provided flags. The daemon fails to reconfigure itself
|
|||
|
if there are conflicts, but it won't stop execution.
|
|||
|
|
|||
|
The list of currently supported options that can be reconfigured is this:
|
|||
|
|
|||
|
- `debug`: it changes the daemon to debug mode when set to true.
|
|||
|
- `cluster-store`: it reloads the discovery store with the new address.
|
|||
|
- `cluster-store-opts`: it uses the new options to reload the discovery store.
|
|||
|
- `cluster-advertise`: it modifies the address advertised after reloading.
|
|||
|
- `labels`: it replaces the daemon labels with a new set of labels.
|
|||
|
- `live-restore`: Enables [keeping containers alive during daemon downtime](https://docs.docker.com/engine/admin/live-restore/).
|
|||
|
- `max-concurrent-downloads`: it updates the max concurrent downloads for each pull.
|
|||
|
- `max-concurrent-uploads`: it updates the max concurrent uploads for each push.
|
|||
|
- `default-runtime`: it updates the runtime to be used if not is
|
|||
|
specified at container creation. It defaults to "default" which is
|
|||
|
the runtime shipped with the official docker packages.
|
|||
|
- `runtimes`: it updates the list of available OCI runtimes that can
|
|||
|
be used to run containers
|
|||
|
- `authorization-plugin`: specifies the authorization plugins to use.
|
|||
|
- `allow-nondistributable-artifacts`: Replaces the set of registries to which the daemon will push nondistributable artifacts with a new set of registries.
|
|||
|
- `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.
|
|||
|
- `registry-mirrors`: it replaces the daemon registry mirrors with a new set of registry mirrors. If some existing registry mirrors in daemon's configuration are not in newly reloaded registry mirrors, these existing ones will be removed from daemon's config.
|
|||
|
|
|||
|
Updating and reloading the cluster configurations such as `--cluster-store`,
|
|||
|
`--cluster-advertise` and `--cluster-store-opts` will take effect only if
|
|||
|
these configurations were not previously configured. If `--cluster-store`
|
|||
|
has been provided in flags and `cluster-advertise` not, `cluster-advertise`
|
|||
|
can be added in the configuration file without accompanied by `--cluster-store`.
|
|||
|
Configuration reload will log a warning message if it detects a change in
|
|||
|
previously configured cluster configurations.
|
|||
|
|
|||
|
|
|||
|
### Run multiple daemons
|
|||
|
|
|||
|
> **Note:** Running multiple daemons on a single host is considered as "experimental". The user should be aware of
|
|||
|
> unsolved problems. This solution may not work properly in some cases. Solutions are currently under development
|
|||
|
> and will be delivered in the near future.
|
|||
|
|
|||
|
This section describes how to run multiple Docker daemons on a single host. To
|
|||
|
run multiple daemons, you must configure each daemon so that it does not
|
|||
|
conflict with other daemons on the same host. You can set these options either
|
|||
|
by providing them as flags, or by using a [daemon configuration file](#daemon-configuration-file).
|
|||
|
|
|||
|
The following daemon options must be configured for each daemon:
|
|||
|
|
|||
|
```none
|
|||
|
-b, --bridge= Attach containers to a network bridge
|
|||
|
--exec-root=/var/run/docker Root of the Docker execdriver
|
|||
|
--data-root=/var/lib/docker Root of persisted Docker data
|
|||
|
-p, --pidfile=/var/run/docker.pid Path to use for daemon PID file
|
|||
|
-H, --host=[] Daemon socket(s) to connect to
|
|||
|
--iptables=true Enable addition of iptables rules
|
|||
|
--config-file=/etc/docker/daemon.json Daemon configuration file
|
|||
|
--tlscacert="~/.docker/ca.pem" Trust certs signed only by this CA
|
|||
|
--tlscert="~/.docker/cert.pem" Path to TLS certificate file
|
|||
|
--tlskey="~/.docker/key.pem" Path to TLS key file
|
|||
|
```
|
|||
|
|
|||
|
When your daemons use different values for these flags, you can run them on the same host without any problems.
|
|||
|
It is very important to properly understand the meaning of those options and to use them correctly.
|
|||
|
|
|||
|
- The `-b, --bridge=` flag is set to `docker0` as default bridge network. It is created automatically when you install Docker.
|
|||
|
If you are not using the default, you must create and configure the bridge manually or just set it to 'none': `--bridge=none`
|
|||
|
- `--exec-root` is the path where the container state is stored. The default value is `/var/run/docker`. Specify the path for
|
|||
|
your running daemon here.
|
|||
|
- `--data-root` is the path where persisted data such as images, volumes, and
|
|||
|
cluster state are stored. The default value is `/var/lib/docker`. To avoid any
|
|||
|
conflict with other daemons, set this parameter separately for each daemon.
|
|||
|
- `-p, --pidfile=/var/run/docker.pid` is the path where the process ID of the daemon is stored. Specify the path for your
|
|||
|
pid file here.
|
|||
|
- `--host=[]` specifies where the Docker daemon will listen for client connections. If unspecified, it defaults to `/var/run/docker.sock`.
|
|||
|
- `--iptables=false` prevents the Docker daemon from adding iptables rules. If
|
|||
|
multiple daemons manage iptables rules, they may overwrite rules set by another
|
|||
|
daemon. Be aware that disabling this option requires you to manually add
|
|||
|
iptables rules to expose container ports. If you prevent Docker from adding
|
|||
|
iptables rules, Docker will also not add IP masquerading rules, even if you set
|
|||
|
`--ip-masq` to `true`. Without IP masquerading rules, Docker containers will not be
|
|||
|
able to connect to external hosts or the internet when using network other than
|
|||
|
default bridge.
|
|||
|
- `--config-file=/etc/docker/daemon.json` is the path where configuration file is stored. You can use it instead of
|
|||
|
daemon flags. Specify the path for each daemon.
|
|||
|
- `--tls*` Docker daemon supports `--tlsverify` mode that enforces encrypted and authenticated remote connections.
|
|||
|
The `--tls*` options enable use of specific certificates for individual daemons.
|
|||
|
|
|||
|
Example script for a separate “bootstrap” instance of the Docker daemon without network:
|
|||
|
|
|||
|
```bash
|
|||
|
$ sudo dockerd \
|
|||
|
-H unix:///var/run/docker-bootstrap.sock \
|
|||
|
-p /var/run/docker-bootstrap.pid \
|
|||
|
--iptables=false \
|
|||
|
--ip-masq=false \
|
|||
|
--bridge=none \
|
|||
|
--data-root=/var/lib/docker-bootstrap \
|
|||
|
--exec-root=/var/run/docker-bootstrap
|
|||
|
```
|