Использовать отладчик Visual Studio с веб-приложением ASP.NET Core, работающим в Kubernetes?

Наша команда хочет иметь возможность запускать отладчик Visual Studio для развернутых экземпляров нашего приложения ASP.NET во внутреннем кластере Kubernetes. Мне нужно выяснить, как закончить головоломку, но я не очень знаком с Visual Studio 2019.

• Образ Docker скомпилирован с официальными образами .NET Core и содержит / vsdbg с последней версией (которая не поддерживает --attach).
• Visual Studio работает с моим Docker Desktop.
• Kubectl правильно настроен. Я могу использовать для тестирования либо кластер kubernetes, включенный в Docker Desktop, либо наш внутренний кластер kubernetes.
• Azure в настоящее время не вариант. Из документации я понимаю, что это то, что Microsoft предпочитает мне делать.

Как мне настроить Visual Studio, чтобы можно было это сделать?

Хорошо. Начнем. Прежде всего убедитесь, что вы опубликовали свое приложение в режиме отладки! Я предпочитаю использовать новую многоэтапную сборку Docker для создания моих изображений, поэтому я напишу что-то вроде этого в конце этапа сборки в Dockerfile:

RUN dotnet publish -c Debug -o ./results

Чтобы отправить изображения в Minikube, я использую локальный реестр контейнеров, как описано здесь. Но вы можете сделать это, как обычно. Когда ваш контейнер будет запущен и запущен, мы сможем взломать его. Я буду использовать Powershell для этой цели, но то же самое можно легко переписать на любом другом терминальном языке. Вы можете шаг за шагом следовать инструкциям и выполнять команды на своем терминале, проверяя значения var с помощью команды echo, когда это необходимо. В вашем файле * .yml должен быть описан селектор примерно так:

selector:
  matchLabels:
    app: mywebapp

Возьмите его и используйте для определения переменной $ Selector в вашем терминале Powershell:

$Selector = 'app=mywebapp'

Вам нужно найти модуль, в котором ваше контейнерное приложение запускается своим селектором:

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

Предполагая, что у вас есть только один контейнер в модуле, вы можете выполнять команды для этого контейнера. По умолчанию в контейнере не установлен vsdbg, поэтому установите его:

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;

Далее вам нужно найти PID вашего приложения внутри контейнера:

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

Обычно он равен 1, но лучше делать меньше предположений. Вот и все. Теперь вы можете запустить отладчик:

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

Не забудьте выполнить следующие команды перед закрытием окна, иначе ваше приложение застрянет навсегда:

-target-detach
-gdb-exit

Давайте соберем все воедино, создадим повторно используемый скрипт и сохраним его где-то рядом с корнями, поскольку вы можете использовать его со всеми вашими проектами 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;

Теперь вы можете выполнить этот скрипт следующим образом, когда терминал работает из папки скриптов:

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

Но разве мы не должны отлаживать в Visual Studio? Да! Давайте пойдем дальше и запустим наш процесс терминала из Visual Studio MIEngine. Откройте свой проект в Visual Studio. Добавьте новый XML-файл со следующим содержимым и назовите его 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>

В -Fileпараметре нужно указать абсолютный путь к файлу скрипта, который мы создали ранее. Затем нажмите Ctrl + Alt + A, чтобы открыть окно командной строки, и выполните следующую команду: Debug.MIDebugLaunch /Executable:dotnet /OptionsFile:absolute_path_to_kubedbg_xml Эта команда запустит процесс отладки в Visual Studio со всеми ожидаемыми стандартными преимуществами. Но не прекращайте отладку другим способом, кроме как нажатием кнопки «Отключить все» в меню «Отладка»! Хотя эту команду не очень удобно писать постоянно. К счастью, в Visual Studio вы можете указать псевдонимы для команд с параметрами. В конце концов вам понадобится новый kubedbg.xmlфайл для каждого проекта. Помня об этом, создайте свой первый псевдоним, введя в командной строке следующую команду:

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

После этого вы можете начать отладку, просто выполнив kubedbg.mywebapp в окне командной строки. Более того, вы можете запустить ту же команду из комбинированного списка инструментов «Найти», но с префиксом: >kubedbg.mywebapp.это не сложно, так как есть текстовое завершение. Вы можете прочитать больше о псевдонимах команд здесь. Удачной отладки! PS: В качестве бонуса абсолютно точно так же вы можете отлаживать свое приложение даже при работе в публичном облаке. Когда kubectl назначается кластеру в общедоступном облаке, он просто работает с тем же сценарием и окупает меньше предположений, так как внутри реального кластера ID процесса не равен 1