docker守护进程（dockerd）是docker系统的服务端核心，作为常驻后台的单一进程，负责镜像、容器、网络、存储等全生命周期管理，并通过模块化分层（server/engine/job）协同containerd、runc等底层组件，经unix套接字或tls加密tcp与客户端通信。
Docker 守护进程（dockerd）不是后台“小工具”，而是整个 Docker 系统的调度中枢和执行引擎。它不直接响应用户敲命令，但所有命令最终都靠它落地——理解它的架构，关键在于抓住“角色定位 + 组件协作 + 通信路径”这三点。
使用 Python 脚本下载 Docker 镜像并打包为 tar 文件。用户说“下载镜像”“拉取镜像”“pull xxx”“帮我下载 nginx 镜像”等时触发。支持 SOCKS5 代理直连（推荐）和国内镜像站加速两种模式。
它是 Docker 的服务端核心
守护进程是常驻内存的单一进程（dockerd），启动后持续监听请求，不退出、不依赖交互式终端。它不处理 UI 或用户输入逻辑，只专注三件事：
- 管理镜像、容器、网络、卷等对象的全生命周期
- 协调底层运行时（如 containerd）、存储驱动（如 overlay2）、网络插件（如 bridge）
- 对接远程 Registry（拉取/推送镜像）或 Swarm 集群节点（编排调度）
内部按职责分层协作
它并非“一整块代码”，而是模块化设计，典型分层包括：
- Server 层：接收客户端请求（通过 socket 或 HTTP），做初步解析和路由
- Engine 层：核心业务逻辑，比如解析 docker run 参数、校验镜像是否存在、准备 rootfs
- Job 层：把具体任务拆成可并发/可重试的最小单元（例如“下载某层镜像”“配置 iptables 规则”“启动 runc 进程”）
通信方式决定安全与使用边界
默认只监听本地 Unix 套接字 /var/run/docker.sock，这是最安全、性能最好的方式。
若需远程操作（如 CI 服务器触发构建），必须显式启用 TCP 监听（如 -H tcp://0.0.0.0:2375），并配套 TLS 认证——否则等于把宿主机控制权暴露给网络。
它和客户端不是“平级关系”，而是严格主从
docker CLI 只是请求封装器：你敲 docker ps，CLI 把它转成 HTTP GET 请求发给 dockerd；返回 JSON 后再格式化成表格输出。
这意味着：
- 没有守护进程，docker 命令会报错 “Cannot connect to the Docker daemon”
- 客户端可跨机器连接（只要网络通、权限开），但守护进程必须运行在目标宿主机上
- 所有资源隔离（cgroups、namespace）、镜像解压、容器进程启动，全部由 dockerd 触发并监督
