Personnaliser des images de conteneurs pour le débogage
Remarque
Cette section explique comment personnaliser vos conteneurs Docker lorsque vous choisissez le type de build du conteneur Dockerfile. Si vous utilisez le type de build du Kit de développement logiciel (SDK) .NET, les options de personnalisation sont différentes et la plupart des informations de cette section ne s’appliquent pas. Au lieu de cela, consultez Containerisez une application .NET avec dotnet publish.
Lorsque vous compilez dans la configuration Debug, Visual Studio effectue plusieurs optimisations qui améliorent les performances du processus de construction pour les projets conteneurisés. Le processus de génération pour les applications conteneurisées n’est pas aussi simple que de suivre les étapes décrites dans le fichier Dockerfile. La création dans un conteneur est plus lente que la génération sur l’ordinateur local. Ainsi, lorsque vous générez dans la configuration Débogage, Visual Studio génère vos projets sur l’ordinateur local, puis partage le dossier de sortie dans le conteneur à l’aide du montage de volume. Une compilation avec cette optimisation activée est appelée compilation en mode rapide.
En mode rapide, Visual Studio appelle docker build avec un argument qui indique à Docker de générer uniquement la première étape du fichier Dockerfile (normalement la phase base). Vous pouvez le modifier en définissant la propriété MSBuild, DockerfileFastModeStage, décrite à propriétés MSBuild des outils de conteneur. Visual Studio gère le reste du processus sans tenir compte du contenu du fichier Dockerfile. Par conséquent, lorsque vous modifiez votre fichier Dockerfile, par exemple pour personnaliser l’environnement de conteneur ou installer des dépendances supplémentaires, vous devez placer vos modifications dans la première étape. Les étapes personnalisées placées dans les étapes build, publishou final du Dockerfile ne sont pas exécutées.
Cette optimisation des performances se produit normalement uniquement lorsque vous générez dans la configuration Debug. Dans la configuration Release, la build se produit dans le conteneur, comme spécifié dans le fichier Dockerfile. Vous pouvez activer ce comportement pour la configuration Libération en définissant ContainerDevelopmentMode sur Rapide dans le fichier-projet :
<PropertyGroup Condition="'$(Configuration)' == 'Release'">
<ContainerDevelopmentMode>Fast</ContainerDevelopmentMode>
</PropertyGroup>
Si vous souhaitez désactiver l’optimisation des performances pour toutes les configurations et construire selon les spécifications du Dockerfile, définissez la propriété ContainerDevelopmentMode sur Regular dans le fichier projet comme suit :
<PropertyGroup>
<ContainerDevelopmentMode>Regular</ContainerDevelopmentMode>
</PropertyGroup>
Pour restaurer l’optimisation des performances, supprimez la propriété du fichier projet.
Lorsque vous démarrez le débogage (F5), un conteneur démarré précédemment est réutilisé, si possible. Si vous ne souhaitez pas réutiliser le conteneur précédent, vous pouvez utiliser reconstruire ou commandes Clean dans Visual Studio pour forcer Visual Studio à utiliser un nouveau conteneur.
Le processus d’exécution du débogueur dépend du type de projet et du système d’exploitation conteneur :
| Scénario | Processus du débogueur |
|---|---|
| applications de .NET Core (conteneurs Linux) | Visual Studio télécharge vsdbg et le mappe au conteneur, puis il est appelé avec votre programme et vos arguments (c'est-à-dire, dotnet webapp.dll), et le débogueur se joint au processus. |
| Applications .NET Core (conteneurs Windows) | Visual Studio utilise onecoremsvsmon et le mappe au conteneur, l’exécute comme point d’entrée, puis Visual Studio se connecte à celui-ci et l’attache au programme. |
| Applications .NET Framework | Visual Studio utilise msvsmon et le mappe au conteneur, l’exécute dans le cadre du point d’entrée où Visual Studio peut se connecter à celui-ci et l’attache au programme. Cela est similaire à la façon dont vous configurez normalement le débogage à distance sur un autre ordinateur ou une machine virtuelle. |
Pour plus d’informations sur vsdbg.exe, consultez débogage offroad de .NET Core sur Linux et OS X à partir de Visual Studio.
Modifier l’image conteneur pour le débogage et la production
Pour modifier l’image conteneur à la fois pour le débogage et pour la production, modifiez l'étape base. Ajoutez vos personnalisations au fichier Dockerfile dans la section de la phase de base, généralement la première section du fichier Dockerfile. Pour plus d’informations sur les commandes Dockerfile, reportez-vous à la référence Dockerfile dans la documentation Docker.
# This stage is used when running from VS in fast mode (Default for Debug configuration)
FROM mcr.microsoft.com/dotnet/aspnet:6.0 AS base
WORKDIR /app
EXPOSE 80
EXPOSE 443
# <add your commands here>
# This stage is used to build the service project
FROM mcr.microsoft.com/dotnet/sdk:6.0 AS build
WORKDIR /src
COPY ["WebApplication3/WebApplication3.csproj", "WebApplication3/"]
RUN dotnet restore "WebApplication3/WebApplication3.csproj"
COPY . .
WORKDIR "/src/WebApplication3"
RUN dotnet build "WebApplication3.csproj" -c Release -o /app/build
# This stage is used to publish the service project to be copied to the final stage
FROM build AS publish
RUN dotnet publish "WebApplication3.csproj" -c Release -o /app/publish
# This stage is used in production or when running from VS in regular mode (Default when not using the Debug configuration)
FROM base AS final
WORKDIR /app
COPY --from=publish /app/publish .
ENTRYPOINT ["dotnet", "WebApplication3.dll"]
Modifier l’image du conteneur uniquement pour le débogage
Vous pouvez personnaliser vos conteneurs de certaines façons pour faciliter le débogage, comme l’installation de quelque chose à des fins de diagnostic, sans affecter les builds de production.
Pour modifier le conteneur uniquement pour le débogage, créez une étape, puis utilisez la propriété MSBuild DockerfileFastModeStage pour indiquer à Visual Studio d’utiliser votre étape personnalisée lors du débogage. Pour plus d’informations sur les commandes Dockerfile, reportez-vous à la référence Dockerfile dans la documentation Docker.
Remarque
Les instructions ici s’appliquent à la casse à conteneur unique. Vous pouvez également faire la même chose pour plusieurs conteneurs avec Docker Compose, mais les techniques requises pour Docker Compose sont légèrement différentes. Par exemple, la phase est contrôlée par un paramètre dans le fichier dockercompose.debug.yml.
Dans l’exemple suivant, nous installons le package procps-ng, mais uniquement en mode débogage. Ce package fournit la commande pidof, que Visual Studio requiert (lors du ciblage de .NET 5 et versions antérieures), mais n’est pas dans l’image Mariner utilisée ici. La phase que nous utilisons pour le débogage en mode rapide est debug, une étape personnalisée définie ici. L’étape de mode rapide n’a pas besoin d’hériter de la build ou de l’étape de publish, elle peut hériter directement de l’étape de base, car Visual Studio monte un volume qui contient tout ce qui est nécessaire pour exécuter l’application, comme décrit plus haut dans cet article.
#See https://aka.ms/containerfastmode to understand how Visual Studio uses this Dockerfile to build your images for faster debugging.
# This stage is used when running from VS in fast mode (Default for Debug configuration)
FROM mcr.microsoft.com/dotnet/aspnet:6.0-cbl-mariner2.0 AS base
WORKDIR /app
EXPOSE 80
EXPOSE 443
FROM base AS debug
RUN tdnf install procps-ng -y
# This stage is used to build the service project
FROM mcr.microsoft.com/dotnet/sdk:6.0-cbl-mariner2.0 AS build
WORKDIR /src
COPY ["WebApplication1/WebApplication1.csproj", "WebApplication1/"]
RUN dotnet restore "WebApplication1/WebApplication1.csproj"
COPY . .
WORKDIR "/src/WebApplication1"
RUN dotnet build "WebApplication1.csproj" -c Release -o /app/build
# This stage is used to publish the service project to be copied to the final stage
FROM build AS publish
RUN dotnet publish "WebApplication1.csproj" -c Release -o /app/publish
# This stage is used in production or when running from VS in regular mode (Default when not using the Debug configuration)
FROM base AS final
WORKDIR /app
COPY --from=publish /app/publish .
ENTRYPOINT ["dotnet", "WebApplication1.dll"]
Dans le fichier projet, ajoutez ce paramètre pour indiquer à Visual Studio d’utiliser votre étape personnalisée debug lors du débogage.
<PropertyGroup>
<!-- other property settings -->
<DockerfileFastModeStage>debug</DockerfileFastModeStage>
</PropertyGroup>
Personnalisez les images de débogage avec le déploiement AOT
Pour prendre en charge le déploiement AOT natif, le débogueur GNU (GDB) est installé, mais uniquement sur l’image utilisée lors du débogage, et non sur l’image finale du runtime. Le fichier Dockerfile inclut un argument de build LAUNCHING_FROM_VS qui peut être true ou false. Si true, la phase de aotdebug est utilisée, c’est-à-dire l’emplacement où GDB est installé. Notez que Visual Studio prend uniquement en charge les conteneurs AOT et GDB natifs pour Linux.
# These ARGs allow for swapping out the base used to make the final image when debugging from VS
ARG LAUNCHING_FROM_VS
# This sets the base image for final, but only if LAUNCHING_FROM_VS has been defined
ARG FINAL_BASE_IMAGE=${LAUNCHING_FROM_VS:+aotdebug}
# ... (other stages omitted)
# This stage is used as the base for the final stage when launching from VS to support debugging in regular mode (Default when not using the Debug configuration)
FROM base as aotdebug
USER root
# Install GDB to support native debugging
RUN apt-get update \
&& apt-get install -y --no-install-recommends \
gdb
USER app
# This stage is used in production or when running from VS in regular mode (Default when not using the Debug configuration)
FROM ${FINAL_BASE_IMAGE:-mcr.microsoft.com/dotnet/runtime-deps:8.0} AS final
WORKDIR /app
EXPOSE 8080
COPY --from=publish /app/publish .
ENTRYPOINT ["./WebApplication1"]
Vous pouvez utiliser aotstage dans le fichier Dockerfile pour personnaliser l’image utilisée au moment du débogage, sans affecter l’image finale utilisée lorsque vous ne lancez pas à partir de Visual Studio ou en production. Par exemple, vous pouvez installer un outil à utiliser uniquement pendant le débogage.