Ok. Cominciamo. Prima di tutto assicurati di aver pubblicato la tua app in modalità Debug! Preferisco usare una nuova funzionalità Docker per la creazione di più fasi per creare le mie immagini, quindi scriverei qualcosa del genere alla fine di una fase di compilazione in Dockerfile:
RUN dotnet publish -c Debug -o ./results
Per inviare le immagini su Minikube, uso il registro dei container locale come descritto qui. Ma puoi farlo come al solito. Quando il container è attivo e funzionante, possiamo iniziare ad hackerarlo. Userò Powershell a tale scopo, ma lo stesso può essere facilmente riscritto in qualsiasi altra lingua terminale. Puoi seguire il tutorial passo dopo passo ed eseguire i comandi nel tuo terminale uno per uno controllando i valori di var con il comando echo quando necessario. Nel tuo file * .yml dovresti avere un selettore descritto in questo modo:
selector:
matchLabels:
app: mywebapp
Prendilo e usalo per definire un var $ Selector nel tuo terminale Powershell:
$Selector = 'app=mywebapp'
È necessario trovare un pod in cui l'applicazione containerizzata è in esecuzione dal relativo selettore:
$pod = kubectl get pods --selector=$Selector -o jsonpath='{.items[0].metadata.name}';
Supponendo che sul pod sia presente un solo contenitore, è possibile eseguire comandi su quel contenitore. Per impostazione predefinita, sul contenitore non è installato vsdbg, quindi procedere e installarlo:
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;
Successivamente, devi trovare il PID della tua app all'interno del contenitore:
$prid = kubectl exec $pod -i -- pidof -s dotnet;
Normalmente è uguale a 1 ma è meglio fare meno ipotesi. Questo è tutto. Ora puoi avviare un debugger:
kubectl exec $pod -i -- /vsdbg/vsdbg --interpreter=mi --attach $prid;
Non dimenticare di eseguire i seguenti comandi prima di chiudere la finestra, altrimenti l'app rimarrà bloccata per sempre:
-target-detach
-gdb-exit
Mettiamo tutto insieme, creiamo uno script riutilizzabile e salviamolo da qualche parte vicino alle radici poiché puoi usarlo con tutti i tuoi progetti 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;
Ora puoi eseguire questo script in questo modo quando il terminale è in esecuzione dalla cartella degli script:
powershell -ExecutionPolicy Bypass -File kubedbg.ps1 -Selector app=mywebapp
Ma non dovremmo eseguire il debug da Visual Studio? Sì! Andiamo oltre e lanciamo il nostro processo terminale da Visual Studio MIEngine. Apri il tuo progetto in Visual Studio. Aggiungi un nuovo file XML con il seguente contenuto e chiamalo 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>
Nel -Fileparametro è necessario specificare il percorso assoluto del file di script creato in precedenza. Quindi premi Ctrl + Alt + A per aprire la finestra di comando ed eseguire il comando seguente:
Debug.MIDebugLaunch /Executable:dotnet /OptionsFile:absolute_path_to_kubedbg_xml
Questo comando avvierà il processo di debug all'interno di Visual Studio con tutti i vantaggi standard che ti aspetteresti. Ma non interrompere il debug in altro modo se non premendo Stacca tutto dal menu Debug! Sebbene questo comando non sia molto comodo da scrivere tutto il tempo. Fortunatamente in Visual Studio, è possibile specificare gli alias per i comandi con parametri. Alla fine, avresti bisogno di un nuovo kubedbg.xmlfile per ogni progetto. Con questo in mente vai avanti e crea il tuo primo alias digitando il seguente comando nella finestra di comando:
alias kubedbg.mywebapp Debug.MIDebugLaunch /Executable:dotnet
/OptionsFile:absolute_path_to_kubedbg.xml
Successivamente, puoi iniziare il debug semplicemente eseguendo kubedbg.mywebapp nella finestra di comando. Ancora meglio, puoi eseguire lo stesso comando dalla casella combinata della barra degli strumenti Trova, ma con il prefisso: >kubedbg.mywebapp.non è difficile poiché c'è anche un completamento del testo. Puoi leggere di più sugli alias di comando qui. Buon debug! PS: come bonus assolutamente allo stesso modo puoi eseguire il debug della tua app anche quando corri all'interno di un cloud pubblico. Quando kubectl è assegnato a un cluster nel cloud pubblico, funziona solo con lo stesso script e rende meno ipotesi rimborsate poiché l'ID processo del cluster reale non è uguale a 1