Thumbnail: kubernetes

Remote Debugging ASP.NET Core Applications on Kubernetes

by on under development
3 minute read
Image: dotnet_kubernetes_docker.png

Recently, after moving our platform to Kubernetes, I needed remote debugging to identify issues that I could not see in error logs easily. This is the easiest method I found:

1. Preparing Docker Image

First of all, I added Visual Studio Remote Debugger (VSDBG) to our docker image. I was using Alpine image, but even though I added all the dependencies I wasn’t able to make it work, so I decided to use the Debian image as you can see in the example below:

FROM microsoft/dotnet:2.1-aspnetcore-runtime-stretch-slim AS base
WORKDIR /app
EXPOSE 80

ENV ASPNETCORE_ENVIRONMENT Docker
ENV DOTNET_RUNNING_IN_CONTAINER=true
ENV DOTNET_USE_POLLING_FILE_WATCHER=true

FROM microsoft/dotnet:2.1-sdk-stretch AS build
WORKDIR /src
COPY ["PrimeApps.App/PrimeApps.App.csproj", "PrimeApps.App/"]

RUN dotnet restore "PrimeApps.App/PrimeApps.App.csproj"
COPY . .
WORKDIR "/src/PrimeApps.App"
RUN dotnet build "PrimeApps.App.csproj" --no-restore -c Debug -o /app

FROM build AS publish
RUN dotnet publish "PrimeApps.App.csproj" --no-restore -c Debug -o /app

FROM base AS final
WORKDIR /app
COPY --from=publish /app .

# Install the dependencies for Visual Studio Remote Debugger
RUN apt-get update && apt-get install -y --no-install-recommends unzip procps

# Install Visual Studio Remote Debugger
RUN curl -sSL https://aka.ms/getvsdbgsh | bash /dev/stdin -v latest -l ~/vsdbg  

ENTRYPOINT ["dotnet","PrimeApps.App.dll"]

2. Deploying New Image to Kubernetes Cluster

After preparing the new docker image, I updated my deployment on Kubernetes with the new image. If you want to debug your code without having a Kubernetes access on the machine, where you are debugging your code, you can also install a SSH Server like OpenSSH to the docker image, with proper configuration and also authentication. Since I have kubectl installed on my machine with the access to the cluster I want to work on, there is no need for SSH access and it is not recommended.

3. Debugging

Visual Studio Remote debugger allows debugging with Visual Studio or Visual Studio Code. I use the latter, so I will only explain the configuration of VS Code.

In Visual Studio Code, launch.json is used to configure debugging behavior. Therefore, It was necessary to add a new configuration entry to attach the debugger to the pod container on Kubernetes Cluster.

In config file, pod name should be configured, so I simply used kubectl to get it. You can also check it from Kubernetes Dashboard.

The command I used to get the pod’s name:

kubectl --namespace app-namespace -l release=app-release-name get pod -o jsonpath={.items[0].metadata.name}

You should place the resulting name in pipeArgs section after -i parameter. After running this configuration below VS Code will prompt a message containing the id’s of running processes, asking which one to attach the debugger. The ID we are looking for is usually 1 so you can replace ${command:pickRemoteProcess} with it, if you don’t want to see the prompt everytime you start debugging.

That’s all. If you have any question or suggestion, you can write under the comments section below. Good luck!

        {
            "name": "Attach to k8s",
            "type": "coreclr",
            "request": "attach",
            "processId" : "${command:pickRemoteProcess}", #usually 1
            "justMyCode": true, #dotnet debug=true,dotner release=false
            "pipeTransport": {
                "pipeProgram": "kubectl",
                "pipeArgs": [
                    "exec",
                    "-i",
                    "pod-name", #name of the pod you debug.
                    "--"
                ],
                "pipeCwd": "${workspaceFolder}",
                "debuggerPath": "/root/vsdbg/vsdbg", #location where vsdbg binary installed.
                "quoteArgs": false
            },
            "sourceFileMap": {
                "/app": "${workspaceFolder}",
                "/src": "${workspaceFolder}"
            }
        }
dotnet, devops, kubernetes, docker
comments powered by Disqus