Azure-docs: DotNet Container Error

[nastassiar]

I wanted to leave a comment for anyone else struggling with getting a dotnet core container running on Linux and see if there was an explanation or I'm just misunderstanding.

I kept getting errors saying that it couldn't find dotnet even though the container ran fine locally and on ACI. After reading the section Container settings for the task I decided to randomly try changing the dockerfile to the absolute path of the dotnet runtime and it magically worked. I'm not entirely sure why as my assumption was that since dotnet was on the path regardless of the working directory it should be found but it seems that is not the case.

Working container: https://hub.docker.com/r/jefking/imageresizer/tags/ version 1.2.4

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: 206a4592-16ac-8ef7-7a33-508535c3ea50
• Version Independent ID: 24785e7d-1caf-dd48-dc26-e5d258d899b1
• Content: Container workloads on Azure Batch
• Content Source: articles/batch/batch-docker-container-workloads.md
• Service: batch
• GitHub Login: @dlepow
• Microsoft Alias: danlep

[mimckitt]

Thanks for the feedback! We are currently investigating and will update you shortly.

[mimckitt]

@nastassiar I have assigned this to the content author to review and see if we can add anything to this doc to make it more clear.

[dlepow]

@nastassiar - Thanks for pointing out this issue. I believe this behavior is specific to the Batch implementation of containers in the task context. This guidance in the article tries to alert customers:

"Because Batch changes the default working directory in your container, the task runs in a location different from the typical container entry point (for example, c: by default on a Windows container, or / on Linux). Make sure that your task command line or container entry point specifies an absolute path, if it isn't already configured that way."

I think this covers the point, but perhaps this guidance needs to be more prominent?

[jefking]

I find this really confusing. I was able to run the container on several other platforms, while it was failing on Azure Batch. Unless there is some really good logging and rational brought to the users attention; I don't feel this is a good experience.
Lastly, a huge selling point of containers is to have portability; and we took a code change to get it to run on Azure Batch. There will be more and more workloads, overtime; where the container will not be able to be modified just to run it on Azure Batch.

[cfe84]

Agreed with Jef, it's really weird that Batch would be a specific case when it comes to running containers, we should follow the _de facto_ standard of the industry and leave the default entry point.

[xingwu1]

The problem is batch doesn't honor WORKDIR of image, we added workitem to track this issue,

[xingwu1]

During the meantime, in order to let this image work, please add "-w /app" to taskContainerSetting. This extra setting will override the Batch default working directory.

[dlepow]

This feedback is all very helpful. I am submitting a pull request with a small doc update to clarify the current behavior and suggested workaround.

[dlepow]

Doc update merged.

please-close