Azure容器应用作业通过CLI传递自定义参数失败问题排查

你遇到的问题核心是没搞清楚az containerapp job start的--command/--args和Docker ENTRYPOINT/CMD的映射逻辑，二者和Docker run的参数规则完全一致，但你之前的尝试都踩了逻辑误区：

核心规则先明确 #

• --command 等价于 Docker 的 --entrypoint，直接替换容器的ENTRYPOINT主命令
• --args 等价于 Docker run 末尾的参数，作为ENTRYPOINT的参数传入（如果ENTRYPOINT存在），或替换CMD（如果ENTRYPOINT未指定）

逐个分析你的尝试错误 #

1. ENTRYPOINT配置 + --command "my_argument"
   这会把容器启动的主命令直接换成my_argument，而不是把它作为参数传给dotnet MyApp.dll。my_argument不是可执行命令，自然跑不起来。

2. ENTRYPOINT配置 + --args "my_argument"
   理论上这是正确的，但如果你的Job在创建时已经预设了固定args，启动时的--args会覆盖原有配置，但如果原有args是多个值，单个参数会替换掉所有；另外，检查Job的容器配置，是否门户里设置的“命令覆盖”还在生效——如果之前设过固定命令/参数，会优先使用配置里的，忽略启动时传的--args。

3. CMD配置 + --command "dotnet" "MyApp.dll" "my_argument"
--command只能指定一个主命令，多个值会被解析错误。这里相当于把ENTRYPOINT设为dotnet，后面的MyApp.dll和my_argument根本不会被当成参数传递，启动逻辑完全错了。

4. CMD配置 + --args "dotnet" "MyApp.dll" "my_argument"
   当Dockerfile只写CMD时，容器默认ENTRYPOINT是sh -c，此时--args的内容会被当成sh -c的参数，相当于执行sh -c "dotnet MyApp.dll my_argument"。这种shell包裹的执行方式会让你的.NET应用无法正确捕获命令行参数——因为应用拿到的是shell的参数，而非真正的命令行输入，这就是和本地ENTRYPOINT配置差异的原因。

正确的操作方式 #

保持你本地正常运行的Dockerfile配置：

ENTRYPOINT ["dotnet", "MyApp.dll"]

然后启动Job时只传--args：

az containerapp job start -n <job> -g <rg> --args "your-request-id"

如果之前在Job配置里设过固定的命令或参数，先清理掉（用门户或az containerapp job update命令），确保启动时的动态参数能正确传递给ENTRYPOINT。

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