Add support for C#/.NET for skaffold debug

[briandealwis]

Add support for debugging .NET-based applications. This language runtime requires additional debugging support files that will be installed via the "duct-tape" image defined by the container-debug-support project.

The .NET debugging support currently installs VSDBG, which is not open-source and specific to the VisualStudio IDEs. VSDBG is normally accessed by attaching to a process over SSH, and we'll need to figure out how to make this work.

[briandealwis]

Found a document describing how to configure vsdbg for k8s. It looks to be a bit involved, with its communication going across stdin/stdout. It's not immediately clear how to leverage port-forwarding to connect. We might need to use netcat or socat.

[Alksar]

Rather useful feature because the Draft project stopped developing actively and "scaffold" seems a good alternative in the dotnet world.

[loligans]

@briandealwis how much has changed on this front?

I find that I am able to debug .NET based applications using the VSCode Docker and Omnisharp extensions together. It appears that the VSCode Docker extension attaches the following volumes:

-v "/home/loligans/Workspace/Application/Application.Api:/app:rw" 
-v "/home/loligans/Workspace/Application:/src:rw" 
-v "/home/loligans/.vsdbg:/remote_debugger:ro" 
-v "/home/loligans/.nuget/packages:/root/.nuget/packages:ro" 
-v "/usr/share/dotnet/sdk/NuGetFallbackFolder:/root/.nuget/fallbackpackages:ro"

Then when launching the application for debugging the following command gets executed:
docker exec -i loligansidentity-dev /remote_debugger/vsdbg --interpreter=vscode

Here is a peek of my launch configuration if you're interested. If you want to see the docker-run: debug task let me know.

{
    "name": "Launch Api (Docker)",
    "type": "docker",
    "request": "launch",
    "preLaunchTask": "docker-run: debug",
    "netCore": {
        "appProject": "${workspaceFolder}/Application.Api/Application.Api.csproj"
    }
}

I don't believe this method uses SSH like the article you mentioned about a year ago. Debugging .NET Core using skaffold would be a dream come true for me, so I'm willing to contribute what I can.

[briandealwis]

@loligans thanks for that information. docker exec is functionally equivalent to SSH. From the volumes mounted, my guess is that the .vsdbg is really the only relevant volume for debugging sake.

There are three aspects here:

• Packaging up vsdbg in a form that can be installed in a pod. This is done.
• Adding support to Skaffold debug to identify a .NET container and rewrite the manifest to mount the vsdbg debugging aids. The Python transformer shows what needs to be done.
• Implementing the plumbing on the VS Code side to call out to kubectl exec -it <<pod>> -c container /dbg/netcore/bin/vsdbg --interpreter=vscode?

[loligans]

@briandealwis Does skaffold have a way to place vsdbg on to the target container? Place as in copy/paste or sync specified files from the host machine to the target container.

I am able to debug using vscode, but it requires some manual intervention. The only manual part is updating the container name in the launch.json. I have opened up an issue for exposing the available Pod names as a command here: vscode-kubernetes-tools/vscode-kubernetes-tools#745. This would allow the launch.json to choose the correct pod without having to be manually updated.

You see here I would replace loligansidentity-69db745998-j7mfv with something like ${command:extension.kubernetes.pods}. This would solve your 3rd bullet.

If skaffold has a way to place files onto the target container then I wouldn't have to specify installing vsdbg in my Dockerfile which would save some time due to latency. I don't completely understand your second bullet, but this might solve it.

I couldn't find in the skaffold.yml specification anything about providing a mechanism for placing files onto the target container.

[briandealwis]

@loligans skaffold debug uses an initContainer and volume mounts to copy in debugging support files into the container in question. So we take a pod like:

apiVersion: v1
kind: Pod
metadata:
  name: getting-started
spec:
  containers:
  - name: getting-started
    image: skaffold-example

and transform it to something like:

kind: Pod
metadata:
  annotations:
    debug.cloud.google.com/config: '{"getting-started":{"artifact":"skaffold-example","runtime":"go","ports":{"dlv":56268}}}'
  creationTimestamp: null
  labels:
    app.kubernetes.io/managed-by: skaffold-unknown
    skaffold.dev/builder: local
    skaffold.dev/cleanup: "true"
    skaffold.dev/deployer: kubectl
    skaffold.dev/docker-api-version: "1.40"
    skaffold.dev/run-id: 0c5bf53c-b7b7-445b-9972-ae7924e8d127
    skaffold.dev/tag-policy: git-commit
    skaffold.dev/tail: "true"
  name: getting-started
  namespace: default
spec:
  containers:
  - args:
    - /dbg/go/bin/dlv
    - exec
    - --headless
    - --continue
    - --accept-multiclient
    - --listen=localhost:56268
    - --api-version=2
    - ./app
    image: skaffold-example:37d452b62efe9c9217cbf68ae4ec558f553eb9c78a5c1fea135d108f235f03c3
    name: getting-started
    ports:
    - containerPort: 56268
      name: dlv
    resources: {}
    volumeMounts:
    - mountPath: /dbg
      name: debugging-support-files
  initContainers:
  - image: gcr.io/gcp-dev-tools/duct-tape/go
    name: install-go-support
    resources: {}
    volumeMounts:
    - mountPath: /dbg
      name: debugging-support-files
  volumes:
  - emptyDir: {}
    name: debugging-support-files

We have a series of "duct tape" images at gcr.io/gcp-dev-tools/duct-tape/ that copy any needed debugging runtime support files into a common volume. We have a netcore duct tape image with vsdbg.

With .NET, I guess you wouldn't need to rewrite the container's command/args.