Docker客户端与服务端通过REST API实现标准化HTTP通信,客户端解析命令并封装为JSON请求发送至守护进程,后者执行操作并返回结构化响应;默认使用Unix套接字(/var/run/docker.sock),支持TCP+TLS远程调用,全程基于HTTP/1.1协议。

Docker 的客户端与服务端通信机制,核心在于“命令下发—请求处理—结果返回”这一闭环流程,不依赖用户手动干预,也不需要理解底层实现细节,只要知道命令怎么发、谁来执行、消息怎么传就够了。
客户端只负责发指令,不干活
Docker 客户端(docker 命令行工具)本质是个“传话员”。你输入 docker run nginx,它不做任何构建或运行动作,只是把这条指令按标准格式打包成一个 HTTP 请求,然后发给服务端。
- 所有操作都走统一入口:无论
pull、build、ps还是exec,客户端都只做解析参数 + 构造 API 请求两件事 - 默认用 Unix 套接字(
/var/run/docker.sock)通信,速度快、无需网络配置;也可配成 TCP 模式,支持远程调用 - 不装守护进程也能用客户端——比如在 Windows 上只装 Docker CLI,连远程 Linux 服务器上的 daemon,照样能操作容器
服务端(daemon)才是真干活的人
Docker 守护进程(dockerd)常驻后台,监听 API 请求,拿到指令后才真正调度资源:拉镜像、启容器、配网络、挂卷……它直接跟操作系统内核打交道,管理命名空间、cgroups、存储驱动等。
在 Linux 上通过 Docker 运行 OpenClaw,并使用 Tailscale 实现远程访问。⚠️ 涉及 sudo、Docker、Tailscale和凭证挂载——请先查阅安全章节...
- 它不认命令行语法,只认 RESTful 接口定义的路径和参数,比如
POST /containers/create对应docker create - 所有状态都由它维护:正在运行的容器列表、本地镜像缓存、自定义网络配置,客户端查
docker ps其实是在读它的内存快照 - 出错时返回标准 HTTP 状态码(如 404 表示镜像不存在,500 表示内部错误),客户端再转成易读提示
通信靠的是标准化协议,不是私有连接
Docker 把通信逻辑完全抽象成一套公开的 API,这意味着只要符合接口规范,任何语言写的程序都能当客户端——不一定是官方 docker 命令。
- API 版本随 Docker 升级迭代,比如 v1.41 支持 cgroup v2,旧客户端连新 daemon 可能部分功能不可用
- 实际传输用 HTTP/1.1,头部带认证信息(如 TLS 证书),体内容是 JSON 格式,结构清晰可调试
- 你可以用
curl --unix-socket /var/run/docker.sock http://localhost/containers/json直接绕过客户端查容器列表,验证通信是否通畅
本地和远程其实是一回事
区别只在连接地址,通信模型完全一致。本地模式是客户端直连本机 socket;远程模式是客户端通过 TCP 连到另一台机器的 dockerd,其余流程丝毫不变。
- 启用远程访问需修改 daemon 配置(
-H tcp://0.0.0.0:2376)并开启 TLS 认证,否则存在安全风险 - 云平台常用这种分离方式:开发机装轻量 CLI,生产环境跑高可用 daemon 集群,CI 流水线用 API 自动触发部署
- Swarm 或 Kubernetes 管理多节点时,也是多个 daemon 组成服务端集群,客户端仍只对单一接入点发请求

















