17370845950

权限被拒应将用户加入docker组：sudo usermod -aG docker $USER；开发时可临时用TCP方式（DOCKER_HOST=tcp://localhost:2375），但生产禁用。

用 docker-go 连接 Docker Daemon 时权限被拒怎么办

直接调用 docker-go 客户端（如 github.com/docker/docker/api/types + github.com/docker/docker/client）失败，常见错误是 connection refused 或 permission denied。根本原因不是代码写错，而是 Go 进程没权限访问 Docker socket。

• Linux 下默认 socket 路径是 /var/run/docker.sock，属主为 root:docker；你的 Go 程序若非 root 或未加入 docker 用户组，会拒绝连接
• 别硬改 socket 权限（比如 chmod 666 /var/run/docker.sock），这是安全隐患；正确做法是把运行 Go 程序的用户加进 docker 组：

  sudo usermod -aG docker $USER

  ，然后重新登录终端
• 开发时可用 TCP 方式绕过 socket 权限问题（仅限测试）：启动 dockerd 时加 -H tcp://0.0.0.0:2375，Go 客户端设 DOCKER_HOST=tcp://localhost:2375；但生产环境禁用该方式，无 TLS 认证等于裸奔

启动容器时 ContainerCreate 返回 “no such image” 却已执行过 docker pull

调用 cli.ContainerCreate() 报错 No such image，即使 shell 里 docker images 明明能看到该镜像——这通常是因为 Go 客户端和 CLI 使用了不同上下文（context）或命名空间。

• 确认你用的是同一 DOCKER_CONTEXT；默认是 default，但如果你切换过（比如用 docker context use mycloud），Go 程序不会自动继承，需显式指定：

  cli, err := client.NewClientWithOpts(client.FromEnv, client.WithAPIVersionNegotiation(), client.WithHost("unix:///var/run/docker.sock"))

• 镜像名必须带 tag；"nginx" 不等价于 "nginx:latest"，Docker daemon 默认只认带完整 tag 的引用；建议始终写全，比如 "nginx:1.25-alpine"
• 如果是私有 registry 镜像，确保已用 docker login 登录，并且 Go 进程能读取 ~/.docker/config.json（路径不可被 chroot 或容器隔离干扰）

容器日志实时流式读取卡住或丢数据

用 cli.ContainerLogs() 获取日志时，发现 io.Copy 阻塞、goroutine 挂起，或者前几行日志没出来就结束了——这不是 Go bug，而是 Docker 日志 API 的流式行为与 reader 缓冲机制不匹配。

• 必须设置 Follow: true 才能持续读；但光设这个不够，还要配 Timestamps: true 和 Stdout/Stderr: true，否则可能拿不到输出流
• 别直接用 io.Copy(os.Stdout, reader)；日志流没有 EOF，io.Copy 会一直等；应改用 bufio.Scanner 按行读，或用 io.ReadCloser 配合 context.WithTimeout 控制生命周期
• 示例关键片段：

  options := types.ContainerLogsOptions{
      Follow:     true,
      Timestamps: true,
      Stdout:     true,
      Stderr:     true,
  }
  reader, err := cli.ContainerLogs(ctx, containerID, options)
  if err != nil {
      log.Fatal(err)
  }
  scanner := bufio.NewScanner(reader)
  for scanner.Scan() {
      fmt.Println(scanner.Text())
  }
  // 注意：scanner.Err() 可能非 nil，但 reader.Close() 仍需调用

Stop/Remove 容器时遇到 “container is not running” 或 “conflict: unable to remove repository reference”

调用 ContainerStop 后立刻 ContainerRemove，却报错说容器不存在或正被占用——这是因为 Stop 是异步触发，Remove 却同步执行，中间存在竞态窗口。

• Stop 不等于立即终止；它发 SIGTERM，等默认 10 秒才发 SIGKILL；Remove 前必须确认状态已变成 exited，不能只靠 Stop 返回就认为完事
• 安全做法：Stop 后轮询 ContainerInspect，检查 .State.Status 是否为 "exited"，超时后强制 Remove；或直接用 Force: true 参数跳过等待，但会丢失 graceful shutdown 机会
• “conflict” 错误常因镜像被多个容器引用；Remove 容器时加 RemoveVolumes: true 和 Force: true 通常可解，但注意 volume 数据会一并清掉

Docker API 的每个操作背后都有明确的状态机和时序约束，G

olang 客户端只是薄封装；真正难的不是调哪个函数，而是理解 Stop/Start/Remove 在 daemon 内部触发了什么，以及如何用 Go 的并发原语守住这些边界。