Docker API 中正确获取容器内执行命令的退出码（Exit Code）-Golang-PHP中文网

Docker API 中正确获取容器内执行命令的退出码（Exit Code）

本文详解如何通过 Docker Engine API 的 ContainerExecAttach 配合流式读取，可靠等待命令执行完成并准确获取其退出码，避免因过早调用 ContainerExecInspect 导致返回错误的 0 值。

本文详解如何通过 docker engine api 的 `containerexecattach` 配合流式读取，可靠等待命令执行完成并准确获取其退出码，避免因过早调用 `containerexecinspect` 导致返回错误的 0 值。

在使用 Docker Engine API（如 github.com/docker/engine-api 或现代等效的 github.com/docker/docker/api/types + github.com/docker/docker/client）执行容器内命令时，一个常见误区是依赖 ContainerExecInspect 轮询获取退出码。由于该接口不阻塞、不保证命令已结束，在命令仍在运行时调用会返回默认/缓存值（通常是 0），导致逻辑错误——尤其当批量执行 shell 脚本（如 /bin/bash -c "exit 233"）且需精确判断结果时，问题尤为突出。

正确的做法是：利用 ContainerExecAttach 建立流式连接，并通过读取 stdout/stderr 直到 EOF 来隐式等待命令终止。Docker 在 exec 进程退出后会主动关闭连接，因此读取到 io.EOF 即代表命令执行完毕，此时再调用 ContainerExecInspect 获取的 ExitCode 才是真实可靠的。

Dolphindb Docker

自动化 DolphinDB Docker 部署，支持自动架构检测（ARM64/x86_64），智能内存分配（50% 规则）以及完整数据持久化。

下载

✅ 关键配置要点

ExecConfig.Detach = false：必须禁用分离模式，否则 Attach 将立即返回空连接；
ExecConfig.AttachStdout = true（及可选 AttachStderr = true）：确保 stdout 流被挂载，为 EOF 检测提供依据；
ExecConfig.Tty = false：避免 TTY 干扰流式读取（除非明确需要交互式终端）；
不要设置 AttachStdin = true（除非需输入），否则可能阻塞连接。

✅ 完整示例代码（Go）

import (
    "io"
    "time"
    "context"
    "github.com/docker/docker/api/types"
    "github.com/docker/docker/client"
)

func execAndAwaitExit(ctx context.Context, cli *client.Client, containerID, cmd string) (int, error) {
    // 1. 创建 exec 实例
    execConfig := types.ExecConfig{
        Cmd:          []string{"/bin/sh", "-c", cmd},
        AttachStdout: true,
        AttachStderr: true,
        Detach:       false,
        Tty:          false,
    }
    execResp, err := cli.ContainerExecCreate(ctx, containerID, execConfig)
    if err != nil {
        return 0, err
    }
    execID := execResp.ID

    // 2. 附加到 exec 流（阻塞直到命令启动，但不等待结束）
    attachOpts := types.ExecStartCheck{Detach: false, Tty: false}
    attachResp, err := cli.ContainerExecAttach(ctx, execID, attachOpts)
    if err != nil {
        return 0, err
    }
    defer attachResp.Close()

    // 3. 消费 stdout/stderr 直到 EOF（即命令结束）
    // 注意：即使不关心输出，也必须读取，否则连接不会关闭
    var buf [1]byte
    for {
        _, err := attachResp.Reader.Read(buf[:])
        if err == io.EOF {
            break // 命令已退出，连接关闭
        }
        if err != nil && err != io.ErrUnexpectedEOF {
            return 0, err
        }
        // 继续读取，忽略内容
    }

    // 4. 此时命令必然已结束，安全获取退出码
    inspectResp, err := cli.ContainerExecInspect(ctx, execID)
    if err != nil {
        return 0, err
    }
    return inspectResp.ExitCode, nil
}

// 使用示例
func main() {
    ctx, cancel := context.WithTimeout(context.Background(), 30*time.Second)
    defer cancel()

    cli, _ := client.NewClientWithOpts(client.FromEnv, client.WithAPIVersionNegotiation())

    exitCode, err := execAndAwaitExit(ctx, cli, "my-container", "sleep 1 && exit 233")
    if err != nil {
        panic(err)
    }
    println("Actual exit code:", exitCode) // 输出：233
}

⚠️ 注意事项与最佳实践

必须消费流数据：即使不需要输出内容，也需持续 Read() 直到 EOF；若完全不读，连接可能永不关闭，导致超时或死锁。
超时控制：建议为 ctx 设置合理超时（如 context.WithTimeout），防止因命令卡死导致整个流程阻塞。
错误处理：Read() 可能返回 io.ErrUnexpectedEOF（如容器异常终止），应结合 inspectResp.Running 字段二次校验状态。
资源清理：务必 defer attachResp.Close()，避免连接泄漏。
替代方案（高级）：若需实时捕获输出，可用 io.Copy(ioutil.Discard, attachResp.Reader) 替代循环读取；若需结构化日志，建议配合 StdoutPipe()/StderrPipe()（需适配新版 client 接口）。