如何缩短从Azure DevOps推送大型镜像至AWS ECR的部署时长

现有思路评估 #

• 方案1：接受现有上传速度
  仅适合镜像更新频率极低（月度及以上）的场景，一旦出现网络波动导致传输中断，重传成本极高，不推荐作为长期方案。
• 方案2：迁移构建环节到AWS CodeBuild
  是目前根治传输问题的高可行性方案，除成本外的其他影响如下：
  • 首次适配需要1-2天工作量，需将原Azure DevOps中的构建脚本、依赖配置、密钥权限同步到CodeBuild
  • 支持直接对接托管在Azure DevOps的代码仓库，通过OAuth、SSH密钥即可完成授权，无技术障碍
  • 可保留Azure DevOps作为CI流程总入口，仅触发CodeBuild执行构建、再同步构建结果即可，无需完全替换现有工作流
  • 同区域内CodeBuild到ECR的传输速率可达GB/s级，17GB镜像推送耗时通常不超过1分钟

更轻量化的替代优化方案 #

如果你暂时不想调整CI架构，可以优先尝试以下低改造成本的方案：

• 拆分镜像分层，固化ML模型基础层
  利用Docker镜像的分层推送机制，将不常变更的ML模型单独打包为基础镜像，提前上传到ECR，业务代码作为上层镜像单独构建。日常迭代仅需上传几十到几百MB的业务代码层，不需要每次全量传输17GB的模型层，适配成本极低，优先级最高。
• 开启BuildKit压缩传输
  在Azure DevOps构建节点配置环境变量DOCKER_BUILDKIT=1，启用BuildKit的镜像分层压缩能力，通常可降低30%-50%的传输体积，17GB镜像的实际传输大小可降到8-10GB左右，传输耗时直接减半。
• 替换为多线程分片上传
  放弃默认的docker push单线程传输逻辑，改用aws ecr put-image命令，配置分片大小为100MB、开启多线程上传，传输速度可提升2-3倍。
• 优化构建节点网络线路
  若使用自托管Azure DevOps构建节点，可将节点部署到与ECR同区域的AWS可用区，跨云内网传输速率远高于公网；若使用微软托管构建节点，选择与ECR同地域的节点池，也可大幅降低公网传输延迟。

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