用 go 调用 docker swarm 管理 api 需通过 http.client 访问 dockerd 的 http 接口，必须正确配置 tcp 监听与 tls 认证；列出 service 调用 /v1.41/services，需在 manager 节点且启用 swarm mode；创建 service 时镜像拉取失败应配置 authconfig 或提前 docker login；更新 service 后需轮询 task 状态确认执行结果。
怎么用 Go 调用 Docker Swarm 的管理 API
Swarm 管理 API 本质是 Docker Engine 的 HTTP 接口，不是独立服务。Go 里直接用 http.Client 发请求就行，不需要额外 SDK。关键在于认证方式和 endpoint 路径——本地 socket 默认不暴露 HTTP，必须显式启用 dockerd 的 TCP 监听（比如 -H tcp://0.0.0.0:2375 或带 TLS 的 -H tcp://0.0.0.0:2376）。
常见错误：直接连 localhost:2375 却没改 dockerd 配置，返回 dial tcp [::1]:2375: connect: connection refused；或开了 TLS 却没配证书，卡在 x509: certificate signed by unknown authority。
- 开发环境可临时用
dockerd -H unix:///var/run/docker.sock -H tcp://0.0.0.0:2375启动（仅限测试） - 生产环境必须用 TLS：生成 CA、server、client 证书，启动时指定
--tlsverify --tlscacert=ca.pem --tlscert=server.pem --tlskey=server-key.pem - Go 客户端要加载 client 证书：
tls.Config{Certificates: []tls.Certificate{cert}}，否则 403
如何列出 Swarm 集群里的所有 service
调用 /v1.41/services 这个 endpoint 就行，但注意两点：一是 API 版本得对得上你连的 Docker 版本（v1.41 对应 Docker 20.10），二是必须在 manager 节点上调用，worker 节点会返回空列表或 404。
容易踩的坑是忽略 swarm mode 是否启用。即使 docker daemon 在运行，如果没执行过 docker swarm init，/services 返回的是空数组，而不是报错。
立即学习“go语言免费学习笔记（深入）”；
- GET 请求头必须带
Content-Type: application/json - 若要过滤，加 query 参数如
?filters={"name":["myapp"]}，注意 JSON 字符串需 URL 编码 - 响应 body 是 JSON 数组，每个元素含
ID、Spec、Version等字段，Spec.TaskTemplate.ContainerSpec.Image才是镜像名
用 Go 创建 service 时 image 拉取失败怎么办
调用 /v1.41/services/create 提交 JSON 后返回 500 并带 "error": "pull access denied"，说明 manager 节点本地没镜像，且没权限拉取远程仓库。
根本原因不是 Go 代码写错了，而是 Swarm 的镜像拉取机制：它不会自动帮你登录 registry，所有节点都得提前配置好 ~/.docker/config.json，或者在 service spec 里显式指定 AuthConfig 字段。
- 推荐做法：在每个 manager 节点运行
docker login，让 daemon 自动读取 config - 如果不能登，在 Go 请求体的
TaskTemplate.ContainerSpec下加AuthConfig字段，值为 base64 编码后的{"username":"u","password":"p","email":"e"} - 避免用
latest标签——Swarm 不会主动 re-pull，更新 service 时得改 tag 或加ForceUpdate: true
为什么 service 更新后 task 一直 pending
调用 /v1.41/services/{id}/update 成功，但 docker service ps 显示 task 状态是 pending，常见于资源约束或网络配置问题。
Go 里发完 update 请求别急着认为成功——得轮询 /v1.41/tasks?filters={"service":["xxx"]} 看 task 的 Status.State 字段，直到变成 running 或明确的 failed。
- 典型触发条件：service 指定了
Placement.Constraints（如node.role==manager），但符合条件的节点没空闲资源 - network 配置错误：指定的
Networks名字不存在，或 attachable network 没在对应节点上创建 - healthcheck 失败也会卡在 starting，但状态显示为
starting而非pending，注意区分
Swarm 的异步性比想象中强，API 返回 200 只代表“已接收更新指令”，不保证执行完成。真正落地要看 task 状态，这个细节很容易被忽略。
