使用 libcontainer 在单个容器中运行多个进程的完整实践指南-Golang-PHP中文网

使用 libcontainer 在单个容器中运行多个进程的完整实践指南

本文详解如何基于 libcontainer 实现类似 docker run 与 docker exec 的功能，重点解决在已运行容器内安全、并发地启动新进程的核心问题，并提供可验证的代码示例与关键注意事项。

本文详解如何基于 libcontainer 实现类似 `docker run` 与 `docker exec` 的功能，重点解决在已运行容器内安全、并发地启动新进程的核心问题，并提供可验证的代码示例与关键注意事项。

在容器运行时开发中，libcontainer（runc 的底层容器执行引擎）原生支持在同一个容器命名空间内启动多个进程——这正是 docker exec 的技术基础。但与 docker run 不同，exec 并非重启容器，而是复用现有 cgroup、mount、network、PID 等命名空间，仅注入新进程。若你的 Exec 函数出现“等待主进程退出”或内存持续增长，通常源于以下三类典型错误：TTY 生命周期管理失当、信号处理器重复注册、标准流未正确隔离。

✅ 正确实现 Exec 的核心原则

复用容器状态，不重建命名空间
container.Start(process) 必须作用于已创建且正在运行的容器实例（即 f.CreateContainer() 后未被销毁），而非新建容器。确保 container.Status() 返回 libcontainer.Running。
TTY 必须独立初始化，且不可复用主进程 TTY
主进程的 TTY 是独占资源；exec 进程需创建专属 TTY 实例（如通过 pty.StartWithArgs 或 newTty(true, process, uid)），并确保其生命周期严格绑定当前 exec 调用（defer tty.Close() 正确放置）。
信号处理需按进程粒度隔离
每个 exec 进程应拥有独立 SignalHandler 实例。共享 handler 会导致信号转发冲突、goroutine 泄漏，最终引发内存暴涨（你观察到的 5–7 次后 100% 内存占用即典型表现）。
I/O 流必须显式重定向，禁用继承
错误示例中 process.Stdin = os.Stdin 将宿主机 stdin 直接注入容器，极易导致阻塞或竞态。正确做法是：
- 使用 io.Pipe() 构建双向通道；
- 通过 tty.SetStdin(pipeReader) 等方式桥接；
- 避免 defer 关闭写端前读端已退出。

✅ 可运行的 Exec 实现（精简版）

func Exec(container libcontainer.Container, spec specs.Process, onData func([]byte), onErr func(error)) (int, error) {
    // 1. 创建新进程对象（非复用主进程）
    process := &libcontainer.Process{
        Args: spec.Args,
        Env:  spec.Env,
        Cwd:  spec.Cwd,
        UserID: uint32(spec.User.UID),
        Terminal: spec.Terminal,
    }

    // 2. 初始化专属 TTY（关键！）
    rootUID, err := container.Config().HostUID()
    if err != nil {
        return -1, fmt.Errorf("get host UID: %w", err)
    }
    tty, err := newTty(spec.Terminal, process, rootUID)
    if err != nil {
        return -1, fmt.Errorf("create tty: %w", err)
    }
    defer tty.Close() // 确保在此处 defer

    // 3. 创建独立信号处理器
    sigHandler := NewSignalHandler(tty)
    defer sigHandler.Close() // 每次 exec 独立 handler

    // 4. 安全重定向 I/O（以 stdout 为例）
    stdoutPipeR, stdoutPipeW := io.Pipe()
    process.Stdout = stdoutPipeW
    process.Stderr = stdoutPipeW

    // 5. 启动进程（非阻塞！）
    if err := container.Run(process); err != nil { // 注意：此处用 Run() 而非 Start()
        return -1, fmt.Errorf("run process: %w", err)
    }

    // 6. 异步读取输出
    go func() {
        scanner := bufio.NewScanner(stdoutPipeR)
        for scanner.Scan() {
            onData(scanner.Bytes())
        }
        if err := scanner.Err(); err != nil {
            onErr(err)
        }
        stdoutPipeW.Close() // 关闭写端，使读端 EOF
    }()

    // 7. 转发信号并等待退出
    return sigHandler.forward(process)
}

? 关键修正点：

使用 container.Run()（同步等待进程结束）替代 Start() + forward() 组合，避免信号 handler 状态错乱；

Run() 内部会自动调用 wait4()，确保进程生命周期受控；

所有 defer 均置于函数起始处，防止资源泄漏。

⚠️ 必须规避的陷阱

*❌ 复用主进程的 `os.File句柄**（如os.Stdin`）→ 导致容器与宿主机 stdin 争用；
❌ 在 Exec 中调用 container.Destroy() → 销毁整个容器，而非仅当前进程；
❌ 忽略 process.Init 字段 → 对于需要 init 进程语义的场景（如 PID 1 行为），需显式设置 process.Init = false；
❌ 未校验容器状态 → container.Status() 应为 Running，否则 Run() 会失败。

✅ 验证方法

启动一个长期运行的容器（如 sleep infinity）；
循环调用 Exec(container, &specs.Process{Args: []string{"sh", "-c", "whoami; ps aux"}}) 10 次；
观察：
- ps aux | grep whoami 应显示多个独立进程（非子进程树）；
- top -p $(pgrep -f "whoami") 内存占用稳定无增长；
- cat /proc//cgroup 中所有进程位于同一 cgroup 路径下。