Azure DevOps Docker镜像构建与ACR发布流水线配置及问题咨询

Hey，你的思路完全正确——构建与发布职责分离确实是更合理的DevOps实践，我来帮你逐个解决这些问题，结合Azure DevOps的实际用法给你落地建议：

1. 构建完成后，Docker镜像存在哪里？ #

当你在Azure DevOps构建流水线中执行Docker构建任务时，镜像会存储在执行构建的代理服务器的本地Docker守护进程仓库里。简单说，就是构建代理机器上执行docker images能看到的本地镜像，它不会自动上传到Azure DevOps工件库或ACR，除非你显式执行推送操作。

2. 能否把镜像作为工件传递给发布流水线？ #

直接把Docker镜像作为Azure DevOps的「工件（Artifact）」是行不通的——因为Azure DevOps工件系统主要针对文件/包类资源，而Docker镜像是Docker守护进程管理的分层对象。不过有两种可行的替代方案：

• 方案1（推荐）：构建时推送到ACR的临时构建仓库
  在构建流水线中，给刚构建的镜像打一个唯一标签（比如带构建ID），推送到ACR的专门存储构建产物的位置（或者同一个仓库的构建标签，比如myimage:build-$(Build.BuildId)）。发布流水线直接从ACR拉取这个镜像进行后续操作，这种方式避免了大文件传输，效率更高。
• 方案2：导出镜像为Tar包作为工件
  用docker save命令把镜像导出为.tar文件，通过Azure DevOps的「发布构建工件」任务上传这个Tar包。发布流水线中再用docker load导入镜像，然后推送到ACR。但这个方案因为Tar包体积大，传输和存储成本高，只适合小镜像或特殊场景。

3. 如何给镜像添加版本号，告别latest标签？ #

完全不要依赖latest标签——它极易导致环境不一致。你可以用Azure DevOps的内置变量生成唯一版本标签，常用的变量包括：

• $(Build.BuildId)：Azure DevOps自动生成的唯一自增构建ID，适合作为核心版本号
• $(Build.SourceVersionShort)：Git提交哈希的前7位，适合追踪源码版本
• $(Build.SourceBranchName)：当前分支名（比如main、feature-xxx），适合区分分支构建

举个例子，构建命令可以写成：

docker build -t myacr.azurecr.io/myapp:$(Build.BuildId) .

或者更清晰的组合标签：

docker build -t myacr.azurecr.io/myapp:$(Build.SourceBranchName)-$(Build.BuildId) .

在Azure DevOps的Docker构建任务中，直接在「镜像名称和标签」字段填入这些变量即可。

4. 是否需要创建多个构建任务推送到Staging和UAT？ #

绝对不需要！这违背了「一次构建，多次部署」的核心原则。正确的做法是：

• 构建流水线只做一次构建：构建镜像并推送到ACR的构建专用位置（比如myapp:build-$(Build.BuildId)）
• 发布流水线负责多环境推送与部署：
  • Staging阶段：拉取构建好的镜像，重新打标签myapp:staging-$(Build.BuildId)，推送到ACR后部署到Staging环境
  • UAT阶段：在Staging验证通过后（可添加手动审批），拉取同一个构建镜像，打标签myapp:uat-$(Build.BuildId)，推送到ACR后部署到UAT环境

这样保证了Staging和UAT用的是同一个构建产物，避免了重复构建带来的一致性问题。

5. Azure DevOps中Docker构建与发布的推荐工作流 #

这里给你一套贴合职责分离的标准端到端工作流：

构建流水线（Build Pipeline） #

• 步骤1：拉取源代码（用Git任务拉取仓库代码）
• 步骤2：Docker镜像构建与推送
  • 使用Docker任务构建镜像，标签用$(Build.BuildId)或组合变量
  • 推送镜像到ACR的构建专用标签/仓库，比如myacr.azurecr.io/myapp:build-$(Build.BuildId)
• 步骤3：传递镜像版本信息
  • 把镜像标签（比如$(Build.BuildId)）写入image-tag.txt文件，上传为构建工件
  • 或者直接把镜像标签存入Azure DevOps变量组，供发布流水线读取

发布流水线（Release Pipeline） #

• 触发方式：设置为「构建完成后自动触发」，关联对应的构建流水线
• 阶段1：Staging环境部署
  • 步骤1：从构建工件中读取镜像标签
  • 步骤2：从ACR拉取myapp:build-$(Build.BuildId)镜像，重新打标签myapp:staging-$(Build.BuildId)并推送至ACR
  • 步骤3：部署到Staging环境（比如用Azure Web App for Containers任务，或AKS的Helm任务）
  • 步骤4：添加自动化测试任务，验证Staging环境
• 阶段2：UAT环境部署
  • 前置条件：添加手动审批（需要测试团队确认Staging验证通过）
  • 步骤1：读取相同的镜像标签
  • 步骤2：拉取构建镜像，打标签myapp:uat-$(Build.BuildId)并推送至ACR
  • 步骤3：部署到UAT环境
  • 步骤4：触发UAT验收测试

额外最佳实践 #

• 镜像安全扫描：在构建阶段添加镜像扫描任务（比如Azure DevOps的Trivy扩展），提前发现镜像中的漏洞
• 变量管理：用Azure DevOps变量组统一管理ACR连接字符串、环境配置参数，避免硬编码
• 清理旧镜像：在ACR中设置生命周期规则，自动清理旧的构建镜像和环境镜像，节省存储成本
• 生产环境管控：生产环境发布阶段一定要添加多级审批，并且保留镜像的生产标签（比如myapp:prod-$(Build.BuildId)），方便快速回滚

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