本质是jenkins slave容器无法访问宿主机docker守护进程，需挂载/var/run/docker.sock并确保jenkins用户属docker组，才能安全复用宿主机docker引擎。
这个问题本质是权限与路径隔离问题：Jenkins Slave 容器默认无法访问宿主机 Docker 守护进程，不挂载 /var/run/docker.sock 就等于没给它调用 docker 的“钥匙”。修复核心在于让 Slave 容器能安全、可靠地复用宿主机的 Docker 引擎。
确认故障表现
典型日志会直接报错：
- Cannot connect to the Docker daemon at unix:///var/run/docker.sock
- 或提示 Is the docker daemon running?（实际宿主机 docker 是正常运行的）
- Pipeline 中执行
docker build、docker images等命令均失败
必须挂载 docker.sock 到 Slave 容器
这是最直接、最常用的解法。无论 Slave 是通过 Docker Plugin 动态创建，还是手动 docker run 启动，都需显式挂载：
- 启动命令中加入：
-v /var/run/docker.sock:/var/run/docker.sock - 若 Slave 容器内 Jenkins 进程以非 root 用户运行（如 jenkins 用户），还需确保该用户属于
docker组；否则即使挂载了，也会因权限不足被拒绝 - 验证是否生效：进入 Slave 容器，执行
docker info，能正常输出即说明连通成功
补充挂载 docker CLI 和配置（推荐）
仅挂载 socket 有时仍会出问题，尤其当容器镜像里没有 docker 命令，或需要读取镜像加速配置时：
- 挂载宿主机
docker二进制：-v /usr/bin/docker:/usr/bin/docker:ro - 挂载 Docker 配置目录：
-v /etc/docker:/etc/docker:ro（让 client 自动识别 insecure-registries、registry-mirrors 等） - 若使用 TLS 认证的远程 dockerd，还需挂载证书目录并设置
DOCKER_HOST和DOCKER_TLS_VERIFY
避免使用 --privileged 模式（除非真需 DinD）
有些方案建议用 --privileged 启动 Slave 并在内部运行完整 dockerd（DinD），但这会带来额外开销和安全隐患：
- DinD 容器内构建的镜像不会出现在宿主机
docker images列表中，不利于调试和清理 -
--privileged赋予容器近乎宿主机 root 的权限，违背最小权限原则 - 绝大多数场景下，共享宿主机 dockerd（即挂载 socket）已完全满足需求，更轻量、更可控
