go不直接部署容器，而是通过调用docker cli、docker engine api或kubernetes client-go实现自动化；本地开发宜用exec.command调cli，生产集群应优先使用client-go。
Go 本身不直接部署容器，它通过调用 docker CLI、Docker Engine API 或 Kubernetes Client（如 client-go）来实现自动化控制——关键在于选对交互层，而不是“用 Go 写个 Docker”。
用 exec.Command 调用 docker CLI 最快上手
适合本地开发、CI 环境或轻量级部署场景，依赖系统已安装 docker 且当前用户有权限执行。
- 必须确保
DOCKER_HOST环境变量正确（默认走 Unix socket，远程需显式设为tcp://...） - 命令失败时，
err不等于nil，但错误信息藏在cmd.CombinedOutput()里，直接打印err.Error()只会显示 “exit status 1” - 敏感参数（如镜像 tag、环境变量）建议用
cmd.Args显式构造，避免字符串拼接引入注入风险
示例：拉取并运行容器
cmd := exec.Command("docker", "run", "-d", "--name", "myapp", "-p", "8080:8080", "my-registry/app:v1.2")
out, err := cmd.CombinedOutput()
if err != nil {
log.Printf("docker run failed: %s, output: %s", err, out)
}
对接 Docker Engine REST API 更可靠、更可控
绕过 CLI，直连 /var/run/docker.sock（Unix）或 http://localhost:2375（TCP），适合嵌入服务或需要细粒度状态判断的场景。
立即学习“go语言免费学习笔记（深入）”；
- Go 标准库
net/http即可完成，无需第三方 SDK；但注意 socket 文件权限（通常需将用户加入docker组） - 创建容器后返回的是
id，启动需额外发POST /containers/{id}/start请求，不能一步到位 - 响应体是 JSON，但 Docker API 的字段命名混用下划线和驼峰（如
Created,status），反序列化要核对文档版本（v1.41 和 v1.44 字段可能不同）
生产环境优先用 client-go + Kubernetes 部署
当目标是集群而非单机时，硬编码 docker run 会迅速失控；client-go 是官方维护、支持 RBAC、滚动更新、健康探针等真实运维能力的唯一合理选择。
- 必须提前配置好
rest.Config（从~/.kube/config或 service account token 加载） - Deployment 创建后不会立即就绪，需轮询
status.replicas和status.availableReplicas判断是否生效 - 镜像拉取失败常因
imagePullPolicy: Always配合私有仓库未配imagePullSecrets，错误日志藏在 Pod 事件里（kubectl describe pod xxx）
别忽略容器生命周期与错误恢复
自动化不是“执行一次命令就完事”，而是处理退出、OOM kill、网络抖动、镜像拉取超时等真实故障。
- 用
os/exec启动的进程若父进程退出，子进程可能变成孤儿；加syscall.Setpgid(0, 0)并监听os.Interrupt做 cleanup - Docker API 返回 500 错误可能是守护进程卡住，重试前应 sleep 并检查
docker info是否响应 - Kubernetes 中
Job失败后默认不重试，需设置backoffLimit和activeDeadlineSeconds防止无限挂起
真正的难点不在“怎么启动一个容器”，而在于判断它是否按预期运行、何时该重启、日志从哪捞、权限够不够、失败了要不要告警——这些没法靠一个 go run deploy.go 解决。
