Używać debugera Visual Studio z aplikacją internetową ASP.NET Core działającą w Kubernetes?

Nasz zespół chce mieć możliwość uruchomienia debugera Visual Studio z wdrożonymi instancjami naszej aplikacji ASP.NET w naszym wewnętrznym klastrze Kubernetes. Muszę wymyślić, jak ukończyć układankę, ale nie znam się dobrze na Visual Studio 2019.

• Obraz Docker jest kompilowany z oficjalnymi obrazami .NET Core i ma / vsdbg zapełnione najnowszą wersją (która nie obsługuje --attach).
• Visual Studio współpracuje z moim Docker Desktop.
• Kubectl jest poprawnie skonfigurowany. Do testowania mogę użyć klastra kubernetes dołączonego do Docker Desktop lub naszego wewnętrznego klastra kubernetes.
• Azure nie jest obecnie opcją. Rozumiem z dokumentacji, że Microsoft preferuje właśnie to.

Jak skonfigurować Visual Studio, aby móc to zrobić?

Ok. Zacznijmy to. Przede wszystkim upewnij się, że opublikowałeś swoją aplikację w trybie debugowania! Wolę używać nowej, wieloetapowej kompilacji z funkcją Docker do budowania moich obrazów, dlatego napisałbym coś takiego na końcu etapu kompilacji w Dockerfile:

RUN dotnet publish -c Debug -o ./results

Aby przekazać obrazy do Minikube, używam lokalnego rejestru kontenerów, jak opisano tutaj. Ale możesz to zrobić tak jak zwykle. Kiedy już uruchomisz swój kontener, możemy zacząć hakować do niego. W tym celu użyję Powershell, ale to samo można łatwo przepisać w dowolnym innym języku terminali. Możesz postępować zgodnie z samouczkiem krok po kroku i wykonywać polecenia w terminalu jeden po drugim, sprawdzając wartości var za pomocą polecenia echo, jeśli to konieczne. W pliku * .yml powinieneś mieć selektor opisujący coś takiego:

selector:
  matchLabels:
    app: mywebapp

Chwyć go i użyj, aby zdefiniować zmienną $ Selector w swoim terminalu PowerShell:

$Selector = 'app=mywebapp'

Musisz znaleźć kapsułę, w której aplikacja kontenerowa jest uruchomiona przez selektor:

$pod = kubectl get pods --selector=$Selector -o jsonpath='{.items[0].metadata.name}';

Zakładając, że masz teraz tylko jeden pojemnik na kapsułce, możesz teraz wykonywać polecenia na tym pojemniku. Domyślnie kontener nie ma zainstalowanego vsdbg, więc zainstaluj go:

kubectl exec $pod -i -- apt-get update;
kubectl exec $pod -i -- apt-get install -y unzip;
kubectl exec $pod -i -- curl -sSL https://aka.ms/getvsdbgsh -o '/root/getvsdbg.sh';
kubectl exec $pod -i -- bash /root/getvsdbg.sh -v latest -l /vsdbg;

Następnie musisz znaleźć PID swojej aplikacji wewnątrz kontenera:

$prid = kubectl exec $pod -i -- pidof -s dotnet;

Zwykle jest równa 1, ale lepiej przyjąć mniej założeń. Otóż ​​to. Teraz możesz uruchomić debugger:

kubectl exec $pod -i -- /vsdbg/vsdbg --interpreter=mi --attach $prid;

Nie zapomnij wykonać następujących poleceń przed zamknięciem okna, w przeciwnym razie aplikacja utknie na zawsze:

-target-detach
-gdb-exit

Złóżmy wszystko razem, stwórz skrypt wielokrotnego użytku i zapisz go gdzieś blisko korzeni, ponieważ możesz go używać ze wszystkimi projektami ASP.NET Core:

param(
    # the selector from your yml file
    #  selector:
    #    matchLabels:
    #      app: myweb
    # -Selector app=myweb
    [Parameter(Mandatory=$true)][string]$Selector
)

Write-Host '1. searching pod by selector:' $Selector '...';
$pod = kubectl get pods --selector=$Selector -o jsonpath='{.items[0].metadata.name}';

Write-Host '2. installing updates ...';
kubectl exec $pod -i -- apt-get update;

Write-Host '3. installing unzip ...';
kubectl exec $pod -i -- apt-get install -y --no-install-recommends unzip;

Write-Host '4. downloading getvsdbgsh ...';
kubectl exec $pod -i -- curl -sSL https://aka.ms/getvsdbgsh -o '/root/getvsdbg.sh';

Write-Host '5. installing vsdbg ...';
kubectl exec $pod -i -- bash /root/getvsdbg.sh -v latest -l /vsdbg;

$cmd = 'dotnet';
Write-Host '6. seaching for' $cmd 'process PID in pod:' $pod '...';
$prid = kubectl exec $pod -i -- pidof -s $cmd;

Write-Host '7. attaching debugger to process with PID:' $pid 'in pod:' $pod '...';
kubectl exec $pod -i -- /vsdbg/vsdbg --interpreter=mi --attach $prid;

Teraz możesz wykonać ten skrypt w ten sposób, gdy terminal działa z folderu skryptów:

powershell -ExecutionPolicy Bypass -File kubedbg.ps1 -Selector app=mywebapp

Ale czy nie powinniśmy debugować z Visual Studio? Tak! Idźmy dalej i uruchom nasz proces terminalowy z Visual Studio MIEngine. Otwórz swój projekt w Visual Studio. Dodaj nowy plik XML o następującej treści i nazwij go kubedbg.xml:

<PipeLaunchOptions xmlns="http://schemas.microsoft.com/vstudio/MDDDebuggerOptions/2014"
    PipePath="powershell" TargetArchitecture="x64" MIMode="clrdbg"
    PipeArguments="
      -ExecutionPolicy Bypass
      -File C:\kube\kubedbg.ps1
      -Selector app=mywebapp">
  <LaunchCompleteCommand>None</LaunchCompleteCommand>
</PipeLaunchOptions>

W -Fileparametrze musisz podać bezwzględną ścieżkę do pliku skryptu, który wcześniej utworzyliśmy. Następnie naciśnij Ctrl + Alt + A, aby otworzyć okno poleceń i uruchom następujące polecenie: Debug.MIDebugLaunch /Executable:dotnet /OptionsFile:absolute_path_to_kubedbg_xml To polecenie rozpocznie proces debugowania w programie Visual Studio ze wszystkimi standardowymi korzyściami, których można oczekiwać. Ale nie przestawaj debugować w inny sposób niż naciskając Odłącz wszystko z menu debugowania! Chociaż to polecenie nie jest zbyt wygodne do pisania przez cały czas. Na szczęście w Visual Studio możesz określić aliasy dla poleceń z parametrami. W końcu będziesz potrzebować nowego kubedbg.xmlpliku dla każdego projektu. Mając to na uwadze, stwórz swój pierwszy alias, wpisując następujące polecenie w oknie poleceń:

alias kubedbg.mywebapp Debug.MIDebugLaunch /Executable:dotnet 
/OptionsFile:absolute_path_to_kubedbg.xml

Następnie możesz rozpocząć debugowanie, uruchamiając plik kubedbg.mywebapp w oknie poleceń. Jeszcze lepiej możesz uruchomić to samo polecenie z paska narzędzi Znajdź Combobox, ale z prefiksem: >kubedbg.mywebapp.Nie jest to trudne, ponieważ istnieje również uzupełnianie tekstu. Możesz przeczytać więcej o aliasach poleceń tutaj. Miłego debugowania! PS: Jako bonus absolutnie w ten sam sposób możesz debugować swoją aplikację, nawet gdy działa w chmurze publicznej. Gdy kubectl jest przypisany do klastra w chmurze publicznej, po prostu działa z tym samym skryptem i spłaca mniej założeń, ponieważ wewnątrz rzeczywistego ID procesu klastra nie jest równy 1