dockerd

Run Docker daemon

$ dockerd

$ dockerd [[-H|--host]] unix://[path/to/tmp.sock] [[-H|--host]] tcp://[ip]

$ dockerd [[-p|--pidfile]] [path/to/pid_file]

$ dockerd [[-D|--debug]]

$ dockerd [[-l|--log-level]] [debug|info|warn|error|fatal]

dockerd [OPTIONS]

--host, -H socket
    Daemon socket(s) to connect to. Can be specified multiple times. Default is unix:///var/run/docker.sock.

--config-file path
    Path to the daemon configuration file. Default is /etc/docker/daemon.json.

--log-level level
    Set the logging level (e.g., debug, info, warn, error, fatal, panic). Default is info.

--debug, -D
    Enable debug mode. Alias for --log-level=debug.

--data-root path
    Root directory for Docker persistent data (images, volumes, etc.). Default is /var/lib/docker.

--storage-driver driver
    Specify the storage driver to use (e.g., overlay2, btrfs, zfs).

--insecure-registries registry
    Enable insecure registry communication. Can be specified multiple times.

--tls, --tlscacert, --tlscert, --tlskey
    Enable and configure TLS for daemon communication.

--icc
    Enable inter-container communication (default is true).

--pidfile path
    Path to use for the daemon's PID file. Default is /var/run/docker.pid.

--mtu value
    Set the containers network MTU.

--ipv6
    Enable IPv6 networking.

dockerd is the persistent background process that powers the Docker Engine. It acts as the central component of the Docker architecture, listening for Docker API requests from the docker client (CLI or other applications).

The daemon is responsible for building, running, and distributing Docker containers. It manages all Docker objects, including images, containers, networks, and data volumes. When you execute a docker command, such as docker run or docker build, the docker client communicates with the dockerd daemon via its REST API, typically over a Unix socket (/var/run/docker.sock) or a TCP port. The daemon then performs the requested operations, leveraging underlying components like containerd for container lifecycle management and runc for low-level container execution.

dockerd also handles complex tasks such as persistent storage management (using various storage drivers like OverlayFS, Btrfs), network configuration (e.g., bridge, overlay networks), and image layer caching. It typically runs as a root-privileged service and can be configured through command-line flags or a configuration file (daemon.json).

dockerd requires root privileges to operate, which can pose security considerations if not properly managed. It is crucial to secure the daemon's API endpoint, especially if exposed over TCP, using TLS. Misconfigurations or running untrusted containers can lead to system vulnerabilities. The daemon can be resource-intensive, consuming significant CPU, memory, and disk I/O, particularly under heavy workloads or with many running containers. Stopping or restarting dockerd will stop all running containers.

dockerd can be configured using a JSON file, typically located at /etc/docker/daemon.json. This file allows for persistent configuration of daemon settings such as data root, logging driver, storage driver options, insecure registries, and more. It's often preferred over command-line flags for production environments.

On most Linux distributions, dockerd is managed as a systemd service (docker.service). You can control its lifecycle using systemctl commands, for example: systemctl start docker, systemctl stop docker, systemctl enable docker, and systemctl status docker. This ensures the daemon starts automatically on boot and handles proper shutdown.

dockerd exposes a RESTful API that the docker client and other tools use to interact with Docker. By default, this API is exposed over a Unix socket (/var/run/docker.sock), which is accessible only by users with appropriate permissions (e.g., members of the 'docker' group). It can also be configured to listen on a TCP port for remote access, which should always be secured with TLS.

The concept of the Docker daemon evolved from the initial Docker project, which was launched in 2013 by Solomon Hykes at PyCon. Initially, the single docker binary encompassed both client and daemon functionalities. As Docker matured and adopted a client-server architecture, the daemon component was explicitly named dockerd, while the client remained docker. This separation allowed for remote management and a more robust design.

Over time, parts of dockerd's responsibilities, particularly the low-level container runtime and image distribution, were componentized and open-sourced into projects like containerd (a high-level container runtime) and runc (an OCI-compliant low-level runtime). This modularization, driven by the Open Container Initiative (OCI), improved stability, security, and allowed for greater flexibility and interoperability within the container ecosystem. dockerd now orchestrates these underlying components to provide the complete Docker Engine experience.

docker(1), docker-compose(1), containerd(8), runc(8), systemctl(1)