EC2实例中并行运行Docker构建耗时更长，原因何在？

我们在云端通过以下Golang代码构建多个Docker镜像，将构建函数放入goroutine并行执行后，EC2实例上的总耗时反而比串行更长，但本地M1 Mac上并行构建符合预期（更快）。我们已经尝试提升EC2的计算/存储资源、提高IOPS，但问题依旧。

构建代码 #

func BuildM1Image(tags []string, dockerfile string, contextPath string, dockerRepoUrl string) error {
    dockerExecutable, _ := exec.LookPath("docker")
    awsExecutable, _ := exec.LookPath("aws")
    toTag := tags[0]
    Log("building image with tag " + toTag)
    // to push --> I need the AWS credentials to live in the cloud, pull them

    os.Setenv("AWS_ACCESS_KEY_ID", Secrets[ECR_ACCESS_KEY_NAME])
    os.Setenv("AWS_SECRET_ACCESS_KEY", Secrets[ECR_SECRET_ACCESS_KEY_NAME])
    ecrGetCredentialsCMD := &exec.Cmd{
        Path: awsExecutable,
        Args: []string{awsExecutable, "ecr", "get-login-password", "--region", GetRegion()},
        // Stderr: os.Stderr,
        // Stdout: os.Stdout,
    }

    out, _ := ecrGetCredentialsCMD.CombinedOutput()
    // if err != nil {
    //  errorChannel <- err
    //  return
    // }

    dockerEcrLoginCMD := &exec.Cmd{
        Path: dockerExecutable,
        Args: []string{dockerExecutable, "login", "--username", "AWS", "-p", string(out), dockerRepoUrl},
    }

    if err := dockerEcrLoginCMD.Run(); err != nil {
        fmt.Println("Docker login failed")
        fmt.Println("error: ", err)
        return err
    }

    buildDockerImage := &exec.Cmd{
        Path: dockerExecutable,
        Args: []string{dockerExecutable, "buildx", "build", "--platform", "linux/amd64", "-t", toTag, "-f", dockerfile, contextPath},
    }

    if err := buildDockerImage.Run(); err != nil {
        fmt.Println("docker build failed")
        logError(err)
        return err
    }
    return nil
}

已尝试操作 #

• 提升EC2实例的计算/存储资源
• 提高存储IOPS

原因分析 #

1. Docker Buildx跨平台构建的资源竞争 #

代码中使用docker buildx build进行linux/amd64跨平台构建，EC2实例默认的Buildx配置未限制并发资源配额。当多个goroutine同时启动构建任务时，会出现：

• CPU上下文切换频繁，每个任务的实际可用计算资源被严重稀释
• 磁盘IO排队阻塞，镜像层的拉取、解压、构建操作互相抢占资源
• 内存不足触发swap分区使用，大幅拖慢构建速度

而本地M1 Mac的Docker Desktop对Buildx并发资源做了动态调度优化，且Apple Silicon的多核心调度对轻量并发任务更友好，因此未出现资源过度竞争问题。

2. 重复ECR登录的资源浪费 #

每个goroutine都会独立执行完整的ECR登录流程：调用aws ecr get-login-password再执行docker login，这会导致：

• 重复的AWS API调用，增加网络延迟和API配额消耗
• 多次写入Docker配置文件（~/.docker/config.json），引发文件锁竞争，导致登录操作阻塞等待

3. 全局环境变量的并发污染风险 #

代码通过os.Setenv设置AWS凭证，这是全局环境变量。多个goroutine并行执行时，会出现凭证被覆盖的情况，可能导致部分登录操作失败或重复执行，间接增加构建耗时。

4. 无限制的goroutine引发资源过饱和 #

未对并发构建的goroutine数量做限制，当任务数量超过EC2实例的资源承载能力时，会进入"过饱和"状态，此时系统资源被完全耗尽，反而比串行执行效率更低。

解决方案建议 #

• 限制Buildx并发数：在Buildx命令中添加--max-parallel参数（例如--max-parallel 2），或通过docker buildx create创建自定义构建器并配置资源限制
• 复用ECR登录会话：在所有构建任务执行前统一完成一次ECR登录，避免重复操作；或共享Docker配置文件给所有构建进程
• 使用局部环境变量：放弃os.Setenv，通过Cmd.Env为每个exec命令单独设置AWS凭证，避免goroutine间的变量污染
• 添加并发控制：使用带缓冲的channel限制同时运行的构建任务数量，例如设置为EC2实例CPU核心数的1.5倍左右

内容的提问来源于stack exchange，提问作者praks5432