Azure创建BC容器: image与artifactUrl需一致?镜像访问报错

关于“注册表凭据”报错的本质 #

该报错是Azure容器实例的通用拉取失败提示，并非真的要求你输入MCR（微软公共容器注册表）的账号密码——MCR上的公开镜像本身不需要凭据即可拉取。触发这个提示的实际原因通常有三类：

• 指定的镜像tag在MCR上已下架、不存在
• 所选Windows镜像对应的内核版本，和Azure容器实例当前提供的宿主机内核版本不兼容，直接拒绝拉取
• az container create 命令存在语法错误，参数拆分、拼接逻辑出错，导致Azure接收到的镜像名称和你预期的不一致

imageName与artifactUrl的匹配规则 #

二者不需要完全版本绑定，属于解耦关系：

• imageName 是容器的底层运行基础，负责提供Business Central运行所需的Windows系统环境、基础依赖组件
• artifactUrl 是Business Central应用层的安装包地址，容器启动过程中会根据这个地址动态拉取对应版本的BC应用完成部署

你第一次使用的镜像mcr.microsoft.com/businesscentral/sandbox:16.2.13509.23270-us 就是典型的已下架老tag，当前MCR上不存在这个镜像条目，是触发拉取报错的直接诱因。

你调整后脚本的硬伤 #

你修改后的脚本存在两处会导致创建失败的语法问题：

• 多行命令没有使用PowerShell反引号做续行标记，az container create 的参数被拆成两条独立命令执行，Azure无法识别完整的创建请求
• -- os-type 参数中多了多余空格，正确的参数格式应为--os-type

• 先验证所选镜像的可用性：本地执行docker pull拉取目标镜像，能正常拉取再传入Azure命令，拉不动就换MCR上当前公开可用的BC基础镜像tag
• 修正命令语法：补全所有续行的反引号，删除参数名中的多余空格
• 确认所在Azure区域支持你所选Windows版本的容器SKU，避免内核不兼容导致的拉取拒绝

注意：如果选择“基础镜像+动态拉取BC制品”的部署方案，不要将BC版本号硬编码在镜像tag中，否则容易和artifactUrl指定的版本产生兼容冲突，推荐固定基础镜像的Windows内核版本匹配ACI的支持范围，单独通过artifactUrl指定需要的BC版本即可。

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