Personnaliser des conteneurs Docker dans Visual Studio
Vous pouvez personnaliser vos images conteneur en modifiant le fichier Dockerfile généré par Visual Studio lorsque vous ajoutez la prise en charge de Docker à votre projet. Que vous génériez un conteneur personnalisé à partir de l’IDE Visual Studio ou que vous configuriez une build de ligne de commande, vous devez savoir comment Visual Studio utilise le fichier Dockerfile pour générer vos projets. Vous devez connaître ces détails, car, pour des raisons de performances, Visual Studio suit un processus spécial pour la création et l’exécution d’applications conteneurisées qui n’est pas évident à partir du fichier Dockerfile.
Supposons que vous souhaitiez apporter une modification au fichier Dockerfile et voir les résultats à la fois dans les conteneurs de débogage et de production. Dans ce cas, vous pouvez ajouter des commandes dans le fichier Dockerfile pour modifier la première étape (généralement base). Consultez Modifier l’image conteneur pour le débogage et la production. Toutefois, si vous souhaitez apporter une modification uniquement lors du débogage, mais pas lors de la production, vous devez créer une autre étape et utiliser le paramètre de génération DockerfileFastModeStage pour indiquer à Visual Studio d’utiliser cette étape pour les builds de débogage. Consultez Modifier l’image conteneur uniquement pour le débogage.
Cet article explique en détail le processus de génération de Visual Studio pour les applications conteneurisées, puis il propose des informations sur la façon de modifier le fichier Dockerfile pour affecter à la fois le débogage et les builds de production, ou simplement pour le débogage.
Générations Dockerfile dans Visual Studio
Remarque
Cette section décrit le processus de génération de conteneur utilisé par Visual Studio 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 les informations contenues dans cette section ne s’appliquent pas. Au lieu de cela, consultez Mettre en conteneur une application .NET avec dotnet publish et utilisez les propriétés décrites dans Personnaliser votre conteneur pour configurer le processus de génération de conteneur.
Génération multi-étapes
Lorsque Visual Studio génère un projet qui n’utilise pas de conteneurs Docker, il appelle MSBuild sur l’ordinateur local et génère les fichiers de sortie dans un dossier (généralement bin) sous votre dossier de solution local. Toutefois, pour un projet conteneurisé, le processus de génération prend en compte les instructions de Dockerfile pour générer l’application conteneurisée. Le fichier Dockerfile utilisé par Visual Studio est divisé en plusieurs étapes. Ce processus s’appuie sur la fonctionnalité de génération multi-étapes de Docker.
La fonctionnalité de génération multi-étapes permet de rendre le processus de création de conteneurs plus efficace et de réduire la taille des conteneurs en leur permettant de contenir uniquement les parties dont votre application a besoin au moment de l’exécution. La génération multi-étapes est utilisée pour les projets .NET Core, et non pour les projets .NET Framework.
La génération multi-étapes permet de créer des images conteneur par étapes qui produisent des images intermédiaires. Prenons l’exemple d’un fichier Dockerfile classique. La première étape est appelée base dans le fichier Dockerfile généré par Visual Studio, bien que les outils n’aient pas besoin de ce nom.
# This stage is used when running from VS in fast mode (Default for Debug configuration)
FROM mcr.microsoft.com/dotnet/aspnet:3.1-buster-slim AS base
WORKDIR /app
EXPOSE 80
EXPOSE 443
Les lignes du fichier Dockerfile commencent par l’image ASP.NET de Microsoft Container Registry (mcr.microsoft.com) et créent une image base intermédiaire qui expose les ports 80 et 443 et définit le répertoire de travail sur /app.
L’étape suivante est build, qui se présente comme suit :
# This stage is used to build the service project
FROM mcr.microsoft.com/dotnet/sdk:3.1-buster-slim AS build
WORKDIR /src
COPY ["WebApplication43/WebApplication43.csproj", "WebApplication43/"]
RUN dotnet restore "WebApplication43/WebApplication43.csproj"
COPY . .
WORKDIR "/src/WebApplication43"
RUN dotnet build "WebApplication43.csproj" -c Release -o /app/build
Vous pouvez voir que l’étape build commence à partir d’une autre image d’origine du registre (sdk plutôt que aspnet), au lieu de continuer à partir de la base. L’image sdk possède tous les outils de génération, et c’est pourquoi elle est beaucoup plus grande que l’image aspnet, qui contient uniquement les composants de runtime. La raison de l’utilisation d’une image distincte devient claire lorsque vous examinez le reste du fichier Dockerfile :
# This stage is used to publish the service project to be copied to the final stage
FROM build AS publish
RUN dotnet publish "WebApplication43.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", "WebApplication43.dll"]
La dernière étape démarre à nouveau à partir de base et inclut le COPY --from=publish pour copier la sortie publiée dans l’image finale. Ce processus permet à l’image finale d’être beaucoup plus petite, car elle n’a pas besoin d’inclure tous les outils de génération qui se trouvaient dans l’image sdk.
Le tableau suivant récapitule les étapes utilisées dans le fichier Dockerfile classique créé par Visual Studio :
| Étape | Description |
|---|---|
| base | Crée l’image du runtime de base où l’application générée est publiée. Les paramètres qui doivent être disponibles au moment de l’exécution vont ici, par exemple les ports et les variables d’environnement. Cette étape est utilisée en cas d’exécution à partir de VS en mode rapide (par défaut pour la configuration de débogage). |
| build | Le projet est généré à cette étape. L’image de base du kit SDK .NET, contenant les composants requis pour générer votre projet, est utilisée. |
| Publier | Cette étape dérive de la phase de génération et publie votre projet, qui sera copié dans la dernière étape. |
| final | Cette étape configure comment démarrer l’application ; elle est utilisée en production ou cas d’exécution à partir de VS en mode normal (par défaut lorsque vous n’utilisez pas la configuration de débogage). |
| aotdebug | Cette étape est utilisée comme base pour l’étape finale en cas de lancement à partir de VS pour prendre en charge le débogage en mode normal (par défaut lorsque vous n’utilisez pas la configuration de débogage). |
Remarque
L’étape aotdebug est prise en charge uniquement pour les conteneurs Linux. Elle est utilisée dans Visual Studio 2022 17.11 et les versions ultérieures si le déploiement Ahead Of Time (AOT) natif est activé sur le projet.
Échauffement du projet
L’échauffement de projet fait référence à une série d’étapes qui se produisent lorsque le profil Docker est sélectionné pour un projet (c’est-à-dire, lorsqu’un projet est chargé ou que la prise en charge de Docker est ajoutée) afin d’améliorer les performances des exécutions suivantes (F5 ou Ctrl+F5). Ce comportement est configurable sous Outils>Options>Outils de conteneurs. Voici les tâches qui s’exécutent en arrière-plan :
- Vérifiez que Docker Desktop est installé et en cours d’exécution.
- Vérifiez que Docker Desktop est défini sur le même système d’exploitation que le projet.
- Extrayez les images dans la première étape du fichier Dockerfile (l’étape
basepour la plupart des fichiers Dockerfile). - Générez le fichier Dockerfile et démarrez le conteneur.
La préparation n’a lieu qu’en mode Rapide. Par conséquent, le conteneur en cours d’exécution dispose du volume monté du dossier de l’application. Cela signifie que les modifications apportées à l’application n’invalident pas le conteneur. Ce comportement améliore considérablement le niveau de performance de débogage et réduit le temps d’attente pour les tâches durables comme l’extraction d’images volumineuses.
Activer des journaux des outils de conteneur détaillés
À des fins de diagnostic, vous pouvez activer certains journaux d’outils de conteneur. Vous pouvez activer ces journaux en définissant certaines variables d’environnement. Pour des projets de conteneur unique, la variable d’environnement est MS_VS_CONTAINERS_TOOLS_LOGGING_ENABLED, qui se connecte ensuite à %tmp%\Microsoft.VisualStudio.Containers.Tools. Pour les projets Docker Compose, il s’agit de MS_VS_DOCKER_TOOLS_LOGGING_ENABLED qui se connecte ensuite à %tmp%\Microsoft.VisualStudio.DockerCompose.Tools.
Avertissement
Lorsque la journalisation est activée et que vous utilisez un proxy de jeton pour l’authentification Azure, les informations d’identification d’authentification peuvent être enregistrées en tant que texte brut. Voir Configurer l’authentification Azure.
Étapes suivantes
Découvrez comment utiliser les étapes du Dockerfile pour personnaliser les images utilisées pour le débogage et la production, par exemple comment installer un outil sur l’image uniquement lors du débogage. Consultez l’article Configurer des images de conteneur pour le débogage.