使用Azure CLI更新Azure Container App未生效原因排查

以下是按出现概率排序的排查方向：

• CLI操作未触发新镜像拉取或新修订生成
  如果你执行az containerapp update时使用固定镜像标签（比如latest），且未显式配置镜像拉取策略为Always，Azure Container App默认会复用节点本地缓存的同标签镜像，不会主动拉取你推送到镜像仓库的新版本；如果命令没有携带任何会触发模板变更的参数（比如镜像地址、环境变量、资源配额修改），甚至不会生成新的修订版本，哪怕CLI返回操作成功，实际运行的版本完全不会变化。
• 多修订模式下流量未切到新修订
  如果你开启了ACA的多修订模式，新修订创建完成后默认分配的流量权重为0，所有请求依然会打到旧的健康修订上。CLI返回成功仅代表修订资源创建完成，不代表流量规则已经更新，此时你访问接口拿到的自然是旧版本内容。
• 新修订启动失败触发自动回滚
  如果新部署的镜像存在启动异常，ASP.NET Core 6应用常见的问题包括：未监听ACA要求的默认80端口、缺少必填配置/连接字符串、程序启动阶段抛异常、健康检查路径配置错误，ACA的存活/就绪探针探测失败后，会自动将100%流量切回健康的旧修订。这个回滚动作是异步执行的，不会在你执行CLI命令的同步响应里返回错误，很容易误以为部署成功。
• CLI操作指向了错误的资源实例
  本地Azure CLI如果保存了多环境的登录上下文，很容易出现当前选中订阅、资源组和你实际访问的应用不匹配的问题：比如你在CLI里操作的是开发环境的ACA实例，自己浏览器访问的是生产环境地址，自然看不到更新效果。
• ASP.NET Core 6 缓存导致的“假更新失效”
  很多时候容器已经成功更新，但ASP.NET Core 6配置的响应缓存中间件、输出缓存、CDN/入口层缓存会返回旧的响应内容，和容器版本无关。你可以通过添加随机查询参数、携带Cache-Control: no-cache请求头测试，同时直接查看容器启动日志打印的版本号确认实际运行的代码版本。
• 镜像拉取失败静默复用缓存镜像
  如果你的镜像存储在私有仓库（比如Azure Container Registry），拉取凭证过期、镜像标签打错、镜像推送未完成，都会导致ACA拉取新镜像失败，此时平台会静默使用节点本地存储的历史缓存镜像启动，不会抛出阻断性的错误提示。
• 后台配置覆盖手动更新
  如果你的订阅配置了Azure Policy合规策略，会强制将ACA的配置（比如镜像版本、环境变量）重置为合规值；或是后台有运行的CI/CD管道、自动化脚本在定时同步配置，你手动通过CLI做的更新会在短时间内被覆盖回原有状态。
• 平台侧配置同步延迟
  ACA的入口、Dapr Sidecar等组件的配置同步存在最长数分钟的延迟，刚执行完更新操作立即访问可能命中旧的配置缓存，等待3-5分钟后再验证即可。

你可以通过以下命令快速定位问题：

# 确认当前CLI上下文的订阅、资源组匹配
az account show --query "name"
az group exists -n <你的资源组名>

# 查看所有修订的流量分配、镜像版本、运行状态
az containerapp revision list -n <你的ACA实例名> -g <你的资源组名> --query "[].{RevisionName:name, Active:properties.active, TrafficPercent:properties.trafficWeight, RunningImage:properties.template.containers[0].image, ProvisionStatus:properties.provisioningState}" -o table

# 拉取最新修订的启动日志排查启动错误
az containerapp logs show -n <你的ACA实例名> -g <你的资源组名> --revision <上一步查到的最新修订名> --tail 100

内容的提问来源于stack exchange，提问作者Owusu Bright Debrah