如何在Azure DevOps CI/CD流水线中跨多个ACR推广Docker镜像？

一、直接镜像复制（ACR间镜像同步） #

这是最直接解决镜像跨ACR问题的方案，在CD流水线的QA、Prod部署阶段前，把Dev ACR里的镜像复制到对应环境的ACR即可。

方法1：Azure CLI acr import 命令实现复制 #

在CD流水线的QA和Prod阶段分别添加Azure CLI任务，执行以下命令完成镜像复制：

# 复制镜像到QA环境ACR
az acr import \
  --name qaacr \
  --source devacr.azurecr.io/your-node-app:${BUILD_VERSION} \
  --image your-node-app:${BUILD_VERSION} \
  --username ${DEV_ACR_USERNAME} \
  --password ${DEV_ACR_PASSWORD}

# 复制镜像到Prod环境ACR
az acr import \
  --name prodacr \
  --source devacr.azurecr.io/your-node-app:${BUILD_VERSION} \
  --image your-node-app:${BUILD_VERSION} \
  --username ${DEV_ACR_USERNAME} \
  --password ${DEV_ACR_PASSWORD}

• 权限要求：流水线使用的服务主体需要对Dev ACR拥有acrpull权限，对QA/Prod ACR拥有acrpush权限。
• 核心优势：完全复用已构建的镜像，确保各环境部署的是同一工件，避免重复构建带来的一致性问题。

方法2：ACR Tasks自动复制（可选） #

如果需要自动化触发复制，可以在Dev ACR中创建ACR任务，当有新镜像推送到Dev ACR时自动同步到QA/Prod ACR。不过对于CD流水线的按需部署场景，CLI命令的灵活性更高。

二、单一ACR+环境标签方案（轻量推荐） #

如果业务不需要强隔离的独立ACR，可以用同一个ACR，通过给镜像打不同环境标签来区分部署版本：

1. CI构建时，给镜像打基础版本标签（如v1.0.0）和dev标签，推送到ACR。
2. CD到QA阶段，给同一镜像打qa标签并推送：

docker tag devacr.azurecr.io/your-node-app:v1.0.0 devacr.azurecr.io/your-node-app:qa
docker push devacr.azurecr.io/your-node-app:qa

3. CD到Prod阶段同理，打prod标签推送。
4. 各环境的App Service拉取对应环境标签的镜像即可。

• 优势：减少ACR的管理成本，流水线步骤更简洁，镜像复用逻辑更直观。

三、最佳实践建议 #

• 严格版本控制：使用语义化版本号（如v1.2.3）作为镜像核心标签，禁止使用latest，确保各环境部署的镜像版本可追溯、可回滚。
• 最小权限原则：流水线服务主体只授予必要的ACR权限，避免过度授权带来的安全风险。
• 镜像完整性校验：复制镜像后，添加校验步骤对比源镜像和目标镜像的digest值，确保镜像未被篡改：

# 获取Dev ACR镜像的digest
SOURCE_DIGEST=$(az acr repository show-manifests --name devacr --repository your-node-app --query "[?tags[0]=='${BUILD_VERSION}'].digest" -o tsv)
# 获取QA ACR镜像的digest
TARGET_DIGEST=$(az acr repository show-manifests --name qaacr --repository your-node-app --query "[?tags[0]=='${BUILD_VERSION}'].digest" -o tsv)
# 对比校验，不一致则终止流水线
if [ "$SOURCE_DIGEST" != "$TARGET_DIGEST" ]; then exit 1; fi

• 流水线阶段审批：在CD流水线的QA→Prod阶段添加手动审批环节，确保镜像经过测试验证后再推广到生产环境。
• ACR网络隔离：如果必须保留独立ACR，配置ACR之间的专用链接（Private Link），让镜像复制走内网，提升安全性和传输速度。

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