Showing errors in docker file in docker-run due to custom ENTRYPOINT in base image

[mehdihadeli]

Hi,
I've created a docker-run task but when it runs it doesn't show detail of errors in docker container and make debugging harder.
How can I get detail of errors in the container?

    {
      "label": "docker-run: catalogs-dev",
      "type": "docker-run",
      "platform": "netCore",
      "dependsOn": [
        "docker-build: catalogs-dev"
      ],
      "dockerRun": {
        "image": "catalogs:dev",
        "containerName": "catalogs-dev"
      },
      "netCore": {
        "appProject": "${workspaceFolder}/src/Services/Catalogs/ECommerce.Services.Catalogs.Api/ECommerce.Services.Catalogs.Api.csproj",
        "enableDebugging": true
      }
    }

[bwateratmsft]

Hey @mehdihadeli, I'd recommend doing the following--

1. In launch.json, in the docker launch config, set the removeContainerAfterDebug property to false to keep the container up:
   
2. Start debugging, allowing the container to start and then stop. Check the "Debug Console" tab, normally app log output goes here.
3. If there's nothing in the "Debug Console" tab, head to the explorer view, right click the container and do "View Logs". There may be some there.

Let us know if you're able to find the logs in one of those places!

[mehdihadeli]

I did this and in the Debug Console tab I have this error:

Starting: "docker" exec -i catalogs-dev /remote_debugger/vsdbg --interpreter=vscode
Error from pipe program 'docker': Error response from daemon: Container e490207f55e92538ae4c250c074d14a620aed9a26c163ebf044c13c099bd18a7 is not running
The pipe program 'docker' exited unexpectedly with code 1.

I think because container has an error, it doesn't show me the internal error of the container.
Maybe this is because of running in detached mode by docker-run task, this generated in my terminal output:

docker container run --detach --tty --name "catalogs-dev" 

[bwateratmsft]

That makes sense. Normally, we launch .NET containers with them doing absolutely nothing--just have vsdbg volume mapped in and the container runs a dummy shell process. Then, when debug resolving finishes, it launches vsdbg inside the container and instructs it to start the app. It seems that for whatever reason, your container is shutting down before vsdbg is launched.

There should hopefully be some logs indicating what's going wrong if you disable the container's auto-remove and then do "View Logs". Normally there is nothing--since the default process in the container is a do-nothing shell--but if it's crashing it might have more info.

[mehdihadeli]

So with vscode-docker we can just debug running containers, I mean it should run successfully before debugging, correct?
In this case, how can I find issue inner my container? Debugging was an easy way for catching error inner container. (I checked logs inner container with docker desktop, its log was not enough).
Is there another solution for debugging my case and catching error in the container?

[bwateratmsft]

For .NET in particular, the debugger can attach before the program starts, so that errors on startup can be debugged. But in this case, the container is crashing before even that can happen.

The next best thing to try would be to copy the docker container run command that is showing up in the terminal, replace --detach with --interactive, and run that command. This should hopefully reveal why the container is crashing when it should be starting up and doing nothing.

[mehdihadeli]

Hi,
I run docker-run produced command directly like this in my environment (gitpod), command was this without detached mode:

docker container run --rm --name 'catalogs-dev' --publish '4000:80/tcp' --network 'ecommerce'  --mount 'type=bind,source=/workspace/ecommerce-microservices,destination=/src' --mount 'type=bind,source=/home/gitpod/.vsdbg,destination=/remote_debugger,readonly' --mount 'type=bind,source=/home/gitpod/.nuget/packages,destination=/root/.nuget/packages,readonly' --mount 'type=bind,source=/home/gitpod/.nuget/packages,destination=/home/appuser/.nuget/packages,readonly' --mount 'type=bind,source=/workspace/ecommerce-microservices/src/Services/Catalogs/ECommerce.Services.Catalogs.Api,destination=/app' -it  catalogs:dev

and I get this error before running the container:

The command could not be loaded, possibly because:
  * You intended to execute a .NET application:
      The application 'ECommerce.Services.Catalogs.Api.dll' does not exist.
  * You intended to execute a .NET SDK command:
      No .NET SDKs were found.

Download a .NET SDK:
https://aka.ms/dotnet/download

Learn about SDK resolution:
https://aka.ms/dotnet/sdk-not-found

When I remove this part --mount 'type=bind,source=/workspace/ecommerce-microservices/src/Services/Catalogs/ECommerce.Services.Catalogs.Api,destination=/app of the above command, my container will run successfully. Actually, this command works:

docker container run --rm --name 'catalogs-dev' --publish '4000:80/tcp' --network 'ecommerce'  --mount 'type=bind,source=/workspace/ecommerce-microservices,destination=/src' --mount 'type=bind,source=/home/gitpod/.vsdbg,destination=/remote_debugger,readonly' --mount 'type=bind,source=/home/gitpod/.nuget/packages,destination=/root/.nuget/packages,readonly' --mount 'type=bind,source=/home/gitpod/.nuget/packages,destination=/home/appuser/.nuget/packages,readonly'  -it  catalogs:dev

What is the problem here? Also below is my task.json file for build and run, I get this error with running docker-run: catalogs-dev task in vscode:

task.json file:

{
  "label": "docker-build: catalogs-dev",
  "type": "docker-build",
  "dependsOn": [
	"build: catalogs service"
  ],
  "platform": "netCore",
  "dockerBuild": {
	"dockerfile": "${workspaceFolder}/src/Services/Catalogs/Dockerfile",
	"context": "${workspaceFolder}",
	"tag": "catalogs:dev",
	"pull": true
  },
  "netCore": {
	"appProject": "${workspaceFolder}/src/Services/Catalogs/ECommerce.Services.Catalogs.Api/ECommerce.Services.Catalogs.Api.csproj"
  }
},
{
  "label": "docker-run: catalogs-dev",
  "type": "docker-run",
  "platform": "netCore",
  "dependsOn": [
	"docker-build: catalogs-dev"
  ],
  "dockerRun": {
	"network": "ecommerce",
	"ports": [
	  {
		"containerPort": 80,
		"hostPort": 4000,
		"protocol": "tcp"
	  }
	],
	"command": "",
	"customOptions": "-it",
	"remove": true,
	"containerName": "catalogs-dev"
  },
  "netCore": {
	"appProject": "${workspaceFolder}/src/Services/Catalogs/ECommerce.Services.Catalogs.Api/ECommerce.Services.Catalogs.Api.csproj",
	"enableDebugging": true
  }
}

[danegsta]

It looks like we're assuming we're running the runtime image directly via a multi-stage Dockerfile (as that's the Dockerfile layout the extension scaffolds), with a default entrypoint that will leave the container running without launching the application. In your case, you're building and running your entire Dockerfile (there's no "target" property specifying a build stage in your "dockerBuild" options for the docker-build task).

This is definitely a scenario that we should handle better (at least by overriding the default entrypoint for an image when launching the container), but you can hopefully workaround the issue by updating the "customOptions" section of the docker-run task to include --entrypoint \"sh\".

[danegsta]

Specifically, your docker-run task would look like this after updating:

{
  "label": "docker-run: catalogs-dev",
  "type": "docker-run",
  "platform": "netCore",
  "dependsOn": [
	"docker-build: catalogs-dev"
  ],
  "dockerRun": {
	"network": "ecommerce",
	"ports": [
	  {
		"containerPort": 80,
		"hostPort": 4000,
		"protocol": "tcp"
	  }
	],
	"command": "",
	"customOptions": "-it --entrypoint \"sh\"",
	"remove": true,
	"containerName": "catalogs-dev"
  },
  "netCore": {
	"appProject": "${workspaceFolder}/src/Services/Catalogs/ECommerce.Services.Catalogs.Api/ECommerce.Services.Catalogs.Api.csproj",
	"enableDebugging": true
  }
}

[mehdihadeli]

@danegsta Thanks for your response, yes I have a multi-stage docker file and this is my docker file. Yes, my problem fixed (debugger attached correctly to the .net process) with specifying my build stage name in my docker file that has .net skd image with stage name builder. Could you tell my why we should specify this build stage in target property or using --entrypoint \"sh\" in customOptions of docker-run?

  "dockerBuild": {
	"dockerfile": "${workspaceFolder}/src/Services/Catalogs/Dockerfile",
	"context": "${workspaceFolder}",
        "target": "builder", //my build stage in the dockerfile
	"tag": "catalogs:dev",
	"pull": true
  },

Should I use my build-stage or artifact stage?

[danegsta]

@mehdihadeli in order to support debugging .NET applications in a container, we depend on running a local build and mounting the assembly and symbols into the container as a volume (to ensure the debugger can find and load the necessary symbols) as well as mounting the vscode remote debugger, then use the debugger to manually launch the application in the container when we attach from vscode. This allows us to support debugging from application launch (vs. just attaching to a running container).

In the default scaffolding, we setup a base stage that is the same image as the runtime FROM mcr.microsoft.com/dotnet/aspnet:latest as base and then build and run that as the debug environment. In your case, you don't have a base runtime stage, so you would either need to reconfigure your stages somewhat (see the template we use to scaffold a Dockerfile if one isn't present) or continue doing a full build and override the entrypoint for now.

[mehdihadeli]

@danegsta thanks for your explanation. If we just use base stage of our dockerfile we will skip our next stages and we can't ensure whole of process in our docker file works correct for producing a artifact. what about using this stage for debugging?
I think we shouldn't use last stage because last stage will launch our app and we don't want launch app here, instead we want launch app in launch.json file with lunching app inner docker remotely.

[danegsta]

@mehdihadeli with your Dockerfile, the first stage isn't a good candidate to build and run by itself, as it's an SDK image rather than a runtime image. In our default Dockerfile, there's a basic runtime stage named base that is used for debug launch and the final runtime stage is an extension of that base stage using FROM base as final.

With your Dockerfile, you can do the full build as long as you apply the entrypoint override via the tasks config, since that will prevent your container from actually trying to start the application during VS launch and allows the debugger to handle the actual application launch. The fix for this in the extension will be to override entrypoint by default during debug launch, which would remove the need to do a custom config override of entrypoint yourself.

[mehdihadeli]

@dbreshears thanks, I used my latest stage in my dockerfile and override entrypoint to --entrypoint bash and it works fine :)

[dbreshears]

Let's override the entrypoint in this case for debugging

[alexyaang]

This has now been released in Docker extension version 1.26.0