Docker：常用可选参数

accttodo 12/31/2025 Docker

参考

# Docker：常用可选参数

以下是 Docker 守护进程（dockerd）启动时的常用可选参数及其说明。这些参数可通过以下方式配置：

命令行启动：直接附加到 dockerd 命令后（如 dockerd -H tcp://0.0.0.0:2375）。
配置文件：写入 /etc/docker/daemon.json（需注意避免与启动脚本冲突）。
Systemd 服务：修改 /etc/systemd/system/docker.service.d/override.conf 中的 ExecStart 字段。

# 常用启动参数

# 1. 网络配置

参数	说明	示例
`-H` / `--host`	指定守护进程监听地址（支持 `unix://`、`tcp://`、`fd://`）	`-H tcp://0.0.0.0:2375`（允许远程访问）
`--bip`	设置 `docker0` 网桥的 IP 地址和子网	`--bip=192.168.1.1/24`
`--iptables`	是否自动管理 iptables 规则（默认 `true`）	`--iptables=false`（需手动配置防火墙）
`--ipv6`	启用 IPv6 网络支持	`--ipv6=true`
`--icc`	允许容器间通过网桥直接通信（默认 `true`）	`--icc=false`（增强安全性）

# 2. 存储与运行时

参数	说明	示例
`--data-root`	指定镜像/容器数据的存储路径（默认 `/var/lib/docker`）	`--data-root=/mnt/docker-data`
`--storage-driver`	设置存储驱动（如 `overlay2`、`aufs`）	`--storage-driver=overlay2`
`--default-runtime`	指定默认容器运行时（如 `runc`、`containerd`）	`--default-runtime=runc`
`--live-restore`	守护进程重启时保持容器运行（避免服务中断）	`--live-restore=true`

# 3. 日志与调试

参数	说明	示例
`-D` / `--debug`	启用调试模式（输出详细日志）	`dockerd -D`
`-l` / `--log-level`	设置日志级别（`debug`/`info`/`warn`/`error`）	`--log-level=debug`
`--log-driver`	配置容器日志的默认驱动（如 `json-file`、`syslog`）	`--log-driver=syslog`

# 4. 安全与代理

参数	说明	示例
`--tlsverify`	强制使用 TLS 加密并验证客户端证书	`--tlsverify`（需配合证书路径参数）
`--insecure-registry`	允许连接非 HTTPS 私有仓库	`--insecure-registry=192.168.1.100:5000`
`--registry-mirror`	指定镜像加速源（如阿里云、中科大）	`--registry-mirror=https://mirror.aliyuncs.com`
`--no-new-privileges`	禁止容器获取新权限（增强安全性）	`--no-new-privileges=true`

# 5. 资源与性能

参数	说明	示例
`--mtu`	设置容器网络 MTU（最大传输单元）	`--mtu=1500`
`--max-concurrent-downloads`	限制镜像拉取的并发数（默认 3）	`--max-concurrent-downloads=5`
`--default-ulimit`	设置容器的默认资源限制（如文件句柄数）	`--default-ulimit nofile=1024:2048`

# 6. 重要注意事项

参数冲突处理：若 daemon.json 与 ExecStart 命令行参数冲突，Docker 可能无法启动，需统一配置来源。
生产环境建议：
- 启用 --live-restore 确保守护进程升级时容器不中断。
- 使用 --icc=false 和 --no-new-privileges=true 提升安全性。
- 通过 --data-root 将数据存储到独立磁盘分区，避免系统盘满载。
完整参数列表：可通过 dockerd --help 查看所有支持选项。

示例 Systemd 配置（/etc/systemd/system/docker.service.d/override.conf）：
[Service]
ExecStart=/usr/bin/dockerd \
  -H tcp://0.0.0.0:2375 \
  --storage-driver=overlay2 \
  --data-root=/mnt/docker-data \
  --live-restore
1
2
3
4
5
6

以上参数可根据实际需求组合使用，建议通过 daemon.json 统一管理以避免维护复杂性。

# 参数：自定义守护进程监听通信协议

Docker守护进程支持三种Socket连接模式：

unix:///var/run/docker.sock、tcp://host:port和fd://socketfd。
unix://用于本地管理，tcp://用于远程连接，fd://用于systemd激活支持。

# 多协议的配置

Docker 守护进程（dockerd）可以同时设置 -H 参数指定多种通信协议。这是 Docker 支持多端监听能力的体现，允许不同方式连接守护进程。以下是关键点说明：

配置可行性
- 同时绑定多协议：通过多次使用 -H 参数，可分别指定不同协议和地址。例如：
```
dockerd -H unix:///var/run/docker.sock -H tcp://0.0.0.0:2375 -H fd://
```
  1
  此配置会同时启用：
  - unix://：本地 Unix Socket（默认路径），用于本地命令行工具访问。
  - tcp://：TCP 端口（如 2375），允许远程客户端（如其他主机或 API 工具）连接。
  - fd://：通过 systemd 套接字激活（需 systemd 支持），按需启动守护进程。

具体配置方式
- 方式一：命令行启动
  
  直接在 dockerd 启动命令后添加多个 -H 参数：
```
dockerd -H fd:// -H tcp://0.0.0.0:2375 -H unix:///var/run/docker.sock
```
  1
- 方式二：Systemd 服务文件
  
  修改 systemd 配置文件（如 /etc/systemd/system/docker.service.d/override.conf）：
```
[Service]
ExecStart=/usr/bin/dockerd \
  -H fd:// \
  -H tcp://0.0.0.0:2375 \
  -H unix:///var/run/docker.sock
```
  1
  2
  3
  4
  5
  完成后需执行：
```
sudo systemctl daemon-reload
sudo systemctl restart docker
```
  1
  2
- 方式三：配置文件 daemon.json
  
  在 /etc/docker/daemon.json 中通过 hosts 数组指定：
```
{
  "hosts": ["fd://", "tcp://0.0.0.0:2375", "unix:///var/run/docker.sock"]
}
```
  1
  2
  3

⚠️ 注意：若同时存在命令行参数和 daemon.json，需确保 systemd 的 ExecStart 中未使用 -H，否则会冲突。

配置示例及验证
- 查看当前监听端口：
```
sudo netstat -tulnp | grep dockerd
```
  1
  输出应包含：
```
tcp6  0.0 0.0.0.0:2375  :::*  LISTEN  <dockerd-PID>
unix  3  [ ]   STREAM  LISTENING  <PID>  /var/run/docker.sock
```
  1
  2
- 测试连接：
  - 本地访问：docker info（通过 Unix Socket）。
  - 远程访问：docker -H tcp://<IP>:2375 info。

🔒安全建议

避免无加密 TCP 暴露：生产环境中开放 tcp:// 端口需启用 TLS 加密（--tlsverify），否则会暴露未授权访问风险。
最小化监听范围：若无需远程管理，可仅保留 fd:// 和 unix://。

# fd协议的详解

fd:// 代表 File Descriptor（文件描述符），是 Docker 守护进程（dockerd）与 systemd 协同工作时的一种特殊的 Docker 监听方式，其核心作用是将网络监听的管理权交给 systemd，实现按需启动和资源优化。关键点在于，当使用 fd:// 时，Docker 并不直接监听具体地址或端口，而是将监听任务交给 systemd 来管理。这就像是把"门卫"的工作委托给了专业的保安公司。

在基于 Systemd 的系统上，可以通过 Systemd socket activation 与守护程序进行通信。 systemd 会负责创建和管理 socket，Docker 只是使用 systemd 提供的文件描述符进行通信。关于系统交互流程，可以整理为几个关键步骤：systemd 创建监听 socket → Docker 启动时继承这些文件描述符 → Docker 直接使用这些预先建立的通信通道 → systemd 负责管理 socket 的生命周期。

# `fd://` 的作用

委托监听管理
- 当 Docker 配置为 -H fd:// 时，不再直接绑定端口或套接字，而是通过 systemd 提供的文件描述符（File Descriptor）通信。
- 比喻理解：
  - 未使用 fd://：Docker 自己“盯门”（如监听 tcp://2375 或 unix://docker.sock）。
  - 使用 fd://：Docker 对 systemd 说：“你安排门（监听方式），我负责响应敲门（请求）！”。
依赖 systemd 的 Socket Activation
- systemd 预先创建好套接字（如 Unix Socket 或 TCP 端口），并在首次请求到达时才启动 Docker 守护进程，减少空闲资源占用。
- 若 systemd 未提供文件描述符，Docker 会启动失败（例如配置错误时）。
默认行为
- 在大多数 Linux 发行版中，Docker 的 systemd 服务文件默认配置为 -H fd://，此时实际监听的是 Unix Socket unix:///var/run/docker.sock。

# fd://的生成环境最佳实践

在生产环境中使用 Docker 的 fd:// 监听模式（即通过 systemd 的 Socket Activation 机制管理守护进程连接）时，需结合安全性、稳定性和可维护性制定最佳实践。以下是关键建议及操作指南：

# 🔒 1. 安全加固实践

避免直接暴露 TCP 端口
- 问题：fd:// 默认仅通过 Unix Socket (unix:///var/run/docker.sock) 通信，但若需远程访问，切勿直接开放无加密的 TCP 端口（如 tcp://0.0.0.0:2375），否则会暴露未授权访问风险。
- 解决方案：
  - 启用 TLS 加密：为远程连接配置证书认证，强制使用 tcp:// + --tlsverify 参数。
  - 通过 SSH 隧道访问：使用 docker -H ssh://user@host 建立加密通道，避免直接开放端口。
限制 Unix Socket 权限
- 默认风险：/var/run/docker.sock 的组权限为 docker，组成员可无密码操作 Docker。
- 加固措施：
  - 限制 docker 组的用户范围，仅授权必要运维人员。
  - 设置 Socket 文件权限为 660（所有者与组可读写）：
```
sudo chmod 660 /var/run/docker.sock
```
    1
启用安全增强机制
- AppArmor/SELinux：强制启用 Linux 安全模块，限制容器对宿主机的访问。
- 非 Root 用户运行容器：在 Dockerfile 中通过 USER 指令指定非特权用户，减少提权风险。

# ⚙️ 2. 配置与依赖管理

避免参数冲突
- 典型冲突：同时配置 -H fd://（systemd 托管）和 daemon.json 中的 hosts 数组会导致 Docker 启动失败。
- 统一配置源：
  - 优先使用 daemon.json 定义监听方式（如 "hosts": ["fd://", "unix:///var/run/docker.sock"]）。
  - 若需保留 fd://，需确保 systemd 服务文件（如 docker.service）中 移除 -H 参数。
依赖 systemd 的健壮性
- Socket 文件管理：确保 systemd 创建的 Socket 文件（如 docker.sock）在服务重启后正常继承。
- 按需启动优化：利用 fd:// 的按需启动特性（首次请求时激活 Docker），减少空闲资源占用。

# 📊 3. 资源与性能优化

资源限制配置
- Cgroup 限制：通过 --cpus、--memory 等参数限制容器资源，防止单容器耗尽宿主机资源：
```
docker run --cpus=2 --memory=512m your-image
```
  1
- 进程数限制：避免容器内 fork bomb 攻击，设置 --pids-limit。
存储与日志分离
- 数据目录独立：使用 --data-root 将 Docker 数据存储到高性能或大容量磁盘分区。
- 日志集中管理：配置 --log-driver=fluentd 或 syslog，将日志转发至 ELK/Splunk 等平台。

# 🛡️ 4. 监控与维护

健康检查与自愈
- 容器健康检查：在 Dockerfile 中定义 HEALTHCHECK，确保异常容器自动重启：
```
HEALTHCHECK --interval=30s --timeout=3s CMD curl -f http://localhost/health || exit 1
```
  1
- 守护进程监控：通过 docker stats 或 Prometheus 采集宿主机及容器指标。
定期维护任务
- 清理旧镜像/容器：定时执行 docker system prune 释放磁盘空间。
- 漏洞扫描：集成 docker scan 或 Trivy 扫描镜像漏洞，纳入 CI/CD 流程。

# ⚠️ 5.关键风险规避

禁止特权容器：避免使用 --privileged，除非极端场景。
禁用主机网络模式：禁止 --network=host，防止容器直接暴露宿主机端口。
限制流量转向：通过 iptables 规则阻止容器间非必要通信（如 ARP 欺骗）。

# 参数：自定义与容器进程通信地址

containerd是Docker的核心组件之一，负责管理容器的生命周期。从Docker 1.11版本开始，Docker将容器运行时部分剥离出来，由containerd负责。

参数--containerd作用：用于显式指定与 containerd 容器运行时通信的 Unix Socket 路径。当dockerd启动时，它需要连接到containerd服务来管理容器。默认情况下，dockerd会自动启动containerd并使用默认路径。但如果用户想手动控制containerd的启动，就可以使用这个参数指定socket路径。

以下是其作用详解：

# 🔧 核心作用

指定 containerd 的通信接口
- dockerd 本身不直接管理容器生命周期，而是通过 containerd 实现容器的创建、启动、停止等操作。
- --containerd 参数明确告知 dockerd：containerd 的服务监听在 /run/containerd/containerd.sock 这个 Unix Socket 路径上，两者通过该 Socket 进行 gRPC 通信。
避免自动启动 containerd
- 默认行为：若未指定此参数，dockerd 会自动启动一个内置的 containerd 子进程，并使用默认路径 /var/run/docker/libcontainerd/docker-containerd.sock。
- 显式控制：指定此参数后，dockerd 不会自动启动 containerd，而是直接连接用户预先启动的 containerd 服务。这要求用户手动启动并配置 containerd。

# ⚙️ 使用场景与必要性

# 1. 独立管理 containerd 生命周期

生产环境需求：在 Kubernetes 等编排系统中，containerd 可能由集群工具（如 kubelet）统一管理。手动启动 containerd 可确保其配置（如 CRI 插件、日志驱动）与集群策略一致。
升级隔离：独立升级 containerd 版本时，无需重启 dockerd，减少服务中断风险。

# 2. 自定义 containerd 配置

若需修改 containerd 的配置（如镜像加速、存储驱动、CNI 网络插件），需通过独立的 /etc/containerd/config.toml 文件配置。此时必须手动启动 containerd 并指定其 Socket 路径。 示例：手动启动 containerd

containerd --config /etc/containerd/config.toml

# 3. 避免资源冲突

若系统已运行其他容器平台（如独立部署的 containerd 或 CRI-O），显式指定 Socket 路径可防止 dockerd 启动冲突的 containerd 实例。

# ⚖️ 默认路径 vs 自定义路径

场景	Socket 路径	管理方式
默认行为（未指定参数）	`/var/run/docker/libcontainerd/docker-containerd.sock`	`dockerd` 自动启动 containerd
显式指定参数	用户自定义（如 `/run/containerd/containerd.sock`）	用户手动启动 containerd

# ⚠️ 注意事项

路径权限 Unix Socket 路径需确保 dockerd 进程有读写权限（通常属组为 docker 或 root）。
依赖启动顺序 必须先启动 containerd 服务，再启动 dockerd，否则 dockerd 会因连接失败而退出。
与 daemon.json 的冲突 若在 daemon.json 中配置了 "containerd" 字段，需确保与命令行参数一致，否则可能导致配置失效。

# 💎 总结

--containerd=/run/containerd/containerd.sock 的本质是 将 Docker 与 containerd 的解耦： ✅ 灵活控制：由用户管理 containerd 的生命周期，适应复杂环境需求。 ✅ 配置独立：支持自定义 containerd 配置（如镜像仓库、网络插件）。 ✅ 资源优化：避免冗余进程，提升系统稳定性。

生产建议：在 Kubernetes 或需精细控制容器运行时的场景中，优先采用此配置；若仅需单机 Docker 开发，默认自动启动即可。

Docker：安装

知识库

Choose mode