Linux App Service无法从Azure私有Container Registry部署原有镜像

我之前也碰到过类似的Azure Linux App Service从私有ACR拉取镜像失败的情况，结合你说的场景——镜像没做任何推送，但自动重部署（Azure的实例交换）时失败，咱们可以从这几个方向一步步排查：

1. 先检查ACR的访问权限是否失效 #

Azure App Service访问私有ACR一般靠**服务主体（Service Principal）或者托管标识（Managed Identity）**来授权，哪怕之前正常，也可能出现权限过期或被误删的情况：

• 如果用的是服务主体：去ACR的IAM设置里，确认这个SP还拥有acrpull角色；另外检查SP的密钥是否过期。用Azure CLI可以快速验证：

  az role assignment list --assignee <你的SP客户端ID> --scope <你的ACR资源ID>
  az ad sp credential list --id <你的SP客户端ID>
  

• 如果用的是系统分配托管标识：先确认App Service的托管标识没被禁用，再去ACR的IAM里核对它是否有acrpull权限。

2. 核对App Service的容器配置是否有误 #

有时候配置可能被意外修改，哪怕你没碰过，也得确认下：

• 进入App Service的容器设置页面，逐一核对：
  • 私有注册表地址是不是正确的（比如youracr.azurecr.io，别打错字）
  • 镜像名称和标签和之前正常运行的完全一致（别用latest标签，哪怕你没推新镜像，有时候也会有意外，不过你说没推送，还是确认下）
  • 如果用的是ACR管理员账户，用户名/密码是否有效；如果是服务主体，客户端ID和密钥有没有填错。

3. 检查ACR的网络访问限制 #

要是你的ACR设置了网络规则（比如只允许特定IP或虚拟网络访问），那App Service的出站IP可能不在允许列表里：

• 先去App Service的属性页面，把所有出站IP地址复制下来
• 再进ACR的网络规则设置，确认这些IP都在允许列表里；如果App Service和ACR在同一虚拟网络，检查对等连接是不是正常。

4. 获取完整的容器启动日志找具体错误 #

你给的Kudu日志只有开头，建议拿完整日志来定位问题：

• 打开Kudu控制台，进入LogFiles/ContainerLogs目录，看最新的日志文件，里面会有镜像拉取失败的具体原因——比如权限拒绝、镜像找不到、网络超时之类的
• 或者在Azure门户的App Service日志流里看实时日志，能更快看到错误细节。

5. 手动测试镜像拉取，排除镜像本身问题 #

你可以在本地用Azure CLI试试拉取镜像，模拟App Service的操作，看看是配置问题还是镜像的问题：

az acr login --name <你的ACR名称>
docker pull <你的ACR名称>.azurecr.io/<镜像名>:<标签>

如果本地拉取正常，那问题肯定在App Service的配置或权限上；如果本地也拉失败，那得检查ACR里的镜像是不是被意外删了。

另外你提到的Azure自动重部署（实例交换），确实是App Service的弹性维护行为，但只有当拉取镜像的流程出问题时才会失败，所以核心还是解决镜像拉取的问题。

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