如何验证经Azure Pipeline推送的.NET Core Docker镜像并排查异常？

首先澄清一个常见认知误区：Azure容器注册表（ACR）完全遵循OCI镜像标准存储数据，你在仓库界面看到的tar.gz压缩包、JSON格式清单文件，就是容器镜像的原生存储形态，并非镜像损坏。

• 拉取并校验镜像基础元数据
  执行以下命令从ACR拉取对应镜像，确认拉取过程无报错、镜像可被正常解析：
  docker pull <你的ACR登录服务器地址>/<镜像仓库名>:<版本标签>
  拉取完成后检查镜像核心配置，重点核对3类问题：
  • 基础运行时版本是否匹配.NET Core应用的目标框架（避免错用SDK镜像、或运行时版本和应用目标框架不兼容）
  • 入口点（Entrypoint）、启动命令是否指向正确的应用dll路径
  • 工作目录配置是否和Dockerfile中COPY应用文件的路径完全匹配
• 启动临时容器验证应用功能
  基于拉取的镜像启动测试容器，映射本地访问端口，验证应用全链路可用性：
  docker run -d --name test-dotnet-app -p 8080:80 <你的ACR登录服务器地址>/<镜像仓库名>:<版本标签>
  验证动作包括：
  • 查看容器实时日志，确认无启动阶段的文件缺失、运行时加载失败类报错
  • 访问映射端口对应的应用健康检查端点，确认服务可正常响应
  • 对核心业务逻辑做最小链路测试，对比容器内的应用行为和本地测试环境的结果一致性
• 镜像一致性校验
  对比流水线阶段本地构建的镜像、和从ACR拉取的远端镜像的唯一ID，确认推送过程无镜像损坏、篡改：
  docker image inspect --format "{{.Id}}" <本地流水线产出的镜像>
docker image inspect --format "{{.Id}}" <从ACR拉取的远端镜像>
  两者ID完全一致即可证明推送链路无问题。

整个排查流程分为3个递进阶段，无需手动解压仓库内的tar.gz文件：

• 第一阶段：镜像结构排查
  直接基于镜像生成临时的可交互文件系统，核对应用文件完整性：
  对带shell的基础镜像（比如官方aspnet运行时镜像），直接执行对应命令查看应用目录结构：
  docker run --rm -it --entrypoint sh <镜像名称:标签> ls -la /app
  核对应用dll、配置文件、静态资源是否完整存在；对distroless类无shell的精简镜像，通过docker export命令将镜像文件系统导出到本地，逐目录核对文件结构。
  同时对比镜像和对应官方基础镜像的层结构，确认没有因为Dockerfile路径配置错误导致的文件漏拷贝。
• 第二阶段：运行时行为排查
  针对容器启动即退出、服务无响应类问题，以前台模式直接启动容器，绕过默认入口点手动执行启动命令，直接抓取原始异常栈：
  docker run --rm --entrypoint sh <镜像名称:标签> dotnet /app/<你的应用dll名称>.dll
  这种方式可以直接定位权限不足、依赖缺失、版本不匹配类的核心报错。复现问题时尽量对齐生产环境的环境变量配置、运行用户、端口映射规则，减少环境差异带来的排查干扰。
• 第三阶段：构建链路排查
  针对Azure Pipeline的构建场景，重点核对：
  • Docker构建任务的上下文路径配置是否正确，是否存在构建产物拷贝路径偏差
  • .NET Core发布步骤的参数是否合规，是否采用了正确的Release发布配置
  • 镜像推送的标签映射是否正确，避免出现同标签下覆盖错误镜像的问题

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