docker-in-docker（dind）指在docker容器内运行docker守护进程，用于ci/cd中提供隔离、并行、可重现的构建环境；需以--privileged模式运行docker:dind镜像，并注意安全与性能权衡。
确保 Docker 守护进程已就绪并可被 CI 进程访问
Docker 守护进程（dockerd）必须运行在 CI 服务器上，且 CI 工具（如 Jenkins）启动的构建任务需能与之通信。默认通过 Unix socket /var/run/docker.sock 交互：
- 确认 docker 服务已启动：
systemctl is-active docker应返回active - Jenkins 默认以
jenkins用户运行，该用户需加入docker用户组：sudo usermod -aG docker jenkins - 重启 Jenkins 使组权限生效：
sudo systemctl restart jenkins - 避免使用
root用户运行 Jenkins，也不建议直接挂载--privileged，最小权限原则更安全
在 Jenkins 容器中启用 Docker 支持（推荐方式）
若 Jenkins 本身运行在 Docker 容器中（如 jenkins/jenkins:lts），需将宿主机的 Docker socket 和 CLI 工具透传进去：
- 启动 Jenkins 容器时挂载 socket：
-v /var/run/docker.sock:/var/run/docker.sock - 同时挂载 Docker CLI 二进制文件（避免“docker: command not found”）：
-v $(which docker):/usr/bin/docker - 确保容器内用户有权限访问 socket，通常需设置
user: "1001:1001"或对应 UID/GID - 验证方式：进入 Jenkins 容器执行
docker info，应能正常输出 daemon 信息
处理构建环境中的 Docker-in-Docker（DinD）场景
某些 CI 场景要求完全隔离的 Docker 环境（如多项目并发构建互不干扰），此时可启用 Docker-in-Docker 模式：
- 使用官方
docker:dind镜像作为 sidecar 容器或构建节点 - 必须启用
--privileged或添加必要 capabilities：--cap-add=SYS_ADMIN --cap-add=NET_ADMIN - DinD 启动后需等待 dockerd 就绪（例如用
wait-for-it.sh或循环检查docker ps） - 注意 DinD 的镜像层不共享宿主机 cache，构建速度略慢，适合强隔离需求而非日常推荐
验证与常见问题排查
配置完成后，应在实际 Pipeline 中快速验证是否真正可用：
- 写一段最简 Pipeline：
sh 'docker --version && docker run --rm hello-world' - 若报错
Cannot connect to the Docker daemon，检查 socket 路径挂载是否正确、用户组是否生效 - 若报错
permission denied while trying to connect to the Docker daemon socket，确认jenkins用户已加入docker组且未因 shell 会话缓存旧组信息 - CI 服务器若为云厂商实例（如 AWS EC2、阿里云 ECS），还需确认安全组/防火墙未拦截本地 socket 访问（一般不影响）
