通过 Docker 守护进程全局设置统一团队开发环境

通过 Docker 守护进程全局设置统一团队开发环境

无论是在本地还是服务器上使用 Docker，往往会在每个项目的 docker-compose.yml 中反复粘贴相同的配置。

• 将 DNS 固定为 1.1.1.1、8.8.8.8
• 将日志驱动固定为 json-file + max-size=10m
• 设置代理、insecure registry、默认网络段等

这些设置如果放在 容器级别 反而会导致管理繁琐。将它们提升为 宿主机全局默认值，即可大幅简化维护。

实现这一目标的工具就是 Docker 守护进程全局配置文件（daemon.json）。

下面从

• 需要编辑的文件
• 放置位置
• 写法
• 适用场景

等方面进行梳理。

1. Docker 守护进程配置方式

Docker 守护进程（dockerd）可以通过两种方式配置：

1. JSON 配置文件（daemon.json） ← 推荐
2. 在 dockerd 启动时使用 CLI 标志

两者可以混合使用，但 同一选项不能同时在文件和标志中出现，否则守护进程会直接报错并退出。例如同时在 --log-driver 标志和 daemon.json 中指定日志驱动，Docker 在启动时会报错。

为了团队或服务器环境的一致性，通常建议：

“尽量把所有配置集中在 daemon.json，只保留必要的 CLI 标志。”

2. daemon.json 的位置

下面给出不同操作系统和安装方式的默认路径，方便快速定位：

• 该文件默认可能不存在，若不存在请自行创建。
• 在团队或服务器标准化时，通常以 Linux 服务器 /etc/docker/daemon.json 为基准。

3. 基本使用流程：

1. 编写/修改 daemon.json

{
  "dns": ["1.1.1.1", "8.8.8.8"],
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3"
  }
}

2. 预先验证配置

sudo dockerd --validate --config-file=/etc/docker/daemon.json
# 若输出 configuration OK，则说明配置无误

3. 重启 Docker 守护进程

sudo systemctl restart docker

从此以后，所有新启动的容器在没有单独指定时都会继承这些全局默认值。

4. 示例 1 – 全局 DNS 固定

4.1 为什么要全局 DNS？

如果容器频繁出现 “无法解析外部 API” 或 “内部域名无法解析” 的问题，往往是宿主机 DNS 配置不一致导致。将 DNS 固定在守护进程层面，比在每个 docker-compose.yml 中添加 dns: 更方便。

4.2 配置示例（daemon.json）

{
  "dns": ["1.1.1.1", "8.8.8.8"]
}

若已有 daemon.json，只需在根对象中添加 "dns": [...] 即可。

⚠️ 注意：DNS 设置会写入容器内部的 /etc/resolv.conf。已运行的容器不会立即生效，只有新启动的容器才会使用。

4.3 适用人群

• 需要使用公司内部 DNS 或 Cloudflare DNS 的开发者
• 在多云环境中强制使用特定 DNS 的平台团队
• 在本地频繁切换 VPN 的个人开发者

5. 示例 2 – 日志驱动与选项全局化

容器日志默认使用 json-file 驱动，存放在 /var/lib/docker/containers/...。通过全局配置可以统一

• 日志格式
• 存储位置
• 轮转策略

5.1 基本 json-file + 轮转

{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "5"
  }
}

这样每个容器的日志文件最大 10 MB，最多保留 5 个，超出的会自动删除。

5.2 中央日志收集驱动（如 fluentd、journald）

平台或基础设施团队常将所有日志发送到集中日志系统。例如使用 Fluentd：

{
  "log-driver": "fluentd",
  "log-opts": {
    "fluentd-address": "localhost:24224",
    "tag": "{{.Name}}"
  }
}

这样无需在 docker run --log-driver=... 中单独指定，所有容器日志都会自动推送。

如果使用 journald，可以这样配置：

{
  "log-driver": "journald",
  "log-opts": {
    "tag": "{{.Name}}"
  }
}

journald 让所有日志集中在 systemd 的 journal 中，便于统一查询、过滤和保留策略。

5.3 Compose / docker run 的关系

• 全局 log-driver + log-opts 充当 默认值。
• 在 Compose 的 logging: 或 docker run 的 --log-driver、--log-opt 中指定时，只会覆盖该容器。

建议：

• 公共值放在 daemon.json。
• 需要特殊处理的服务单独覆盖。

6. 示例 3 – 代理、insecure registry 等全局网络设置

6.1 代理设置

如果公司只能通过代理访问外部网络，建议在守护进程层面统一配置：

{
  "proxies": {
    "http-proxy": "http://proxy.example.com:3128",
    "https-proxy": "http://proxy.example.com:3128",
    "no-proxy": "localhost,127.0.0.1,.corp.example.com"
  }
}

这样 Docker 在拉取镜像或构建时会自动使用该代理。

6.2 insecure registry

若必须使用无 TLS 的内部 registry，可配置：

{
  "insecure-registries": ["my-registry.local:5000"]
}

请仅在内部测试环境使用，避免安全风险。

7. 示例 4 – 默认网络段、存储驱动等

7.1 默认 bridge 网络段

为避免 VPN 或公司网络冲突，可自定义默认桥接网络段：

{
  "default-address-pools": [
    {
      "base": "10.20.0.0/16",
      "size": 24
    }
  ]
}

此后新建的 bridge 网络将使用 10.20.x.0/24。

7.2 强制存储驱动

不同 Linux 发行版默认存储驱动可能不同。若团队统一使用 overlay2：

{
  "storage-driver": "overlay2"
}

具体支持的驱动请参考 dockerd 文档和发行版指南。

8. 何时、谁最受益？

8.1 个人开发者

• 在多个侧项目中使用相同 Docker 选项
• VPN、代理等网络环境频繁切换
• 本地日志/磁盘管理繁琐

只需维护一个 daemon.json，即可统一环境，省去重复配置。

8.2 小型/中型团队

• 团队成员本地 Docker 配置不一致导致 “在我机器上能跑，别人跑不起来” 的情况
• 希望 CI 与本地环境的网络/日志设置保持一致
• 想强制使用公司 DNS、代理、镜像仓库

通过 daemon.json 定义团队 Docker 基础配置，配合 Ansible/Chef/Terraform 等工具统一部署。

8.3 平台团队 / DevOps / SRE

• 需要在数十到数百个容器节点上统一日志、存储、网络策略
• 需要将日志、监控、合规规则统一到宿主机层面

daemon.json 成为 Docker 节点策略文件，实现全局一致性。

9. 调试技巧

1. 标志与重复配置 - 检查 systemd 单元文件（如 /lib/systemd/system/docker.service）中是否已传递 --log-driver 等标志。 - 同一选项在标志和 daemon.json 中同时出现会导致守护进程启动失败。
2. Docker Desktop - Desktop 的 GUI 通过 ~/.docker/daemon.json 进行配置。 - 手动编辑文件后，Desktop UI 可能会覆盖，建议统一使用其中一种方式。

结语

• Docker 的全局默认值由 daemon.json 管理。
• 典型配置包括 DNS、日志驱动、代理、insecure registry、默认网络段、存储驱动等。
• 对个人开发者而言，减少重复配置；对团队或平台而言，提升环境一致性与可维护性。
• 当你发现自己在 docker-compose.yml 或 docker run 中频繁写同样的选项时，考虑把它们迁移到 daemon.json。