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érez 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 ne sont pas évidentes à partir du fichier Dockerfile.
Supposons que vous souhaitez apporter une modification dans le fichier Dockerfile et voir les résultats dans le débogage et dans les conteneurs 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 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 de manière détaillée le processus de build Visual Studio pour les applications en conteneur, et fournit des informations sur la modification du fichier Dockerfile pour impacter à la fois les builds de débogage et de production, ou uniquement 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 Containerize 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. Pour un projet conteneurisé, toutefois, le processus de génération prend en compte les instructions de Dockerfile pour la création de l’application conteneurisée. Le fichier Dockerfile que Visual Studio utilise 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 multistage 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 bits dont votre application a besoin au moment de l’exécution. La build Multistage est utilisée pour les projets .NET Core, et non pour les projets .NET Framework.
La build multistage permet de créer des images conteneur en phases 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 ne nécessitent pas 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 intermédiaire base qui expose les ports 80 et 443, et définit le répertoire de travail sur /app.
L’étape suivante est build, qui apparaît 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), plutôt que de continuer à partir de base. L’image sdk a tous les outils de génération et, pour cette raison, elle est beaucoup plus grande que l’image aspnet, qui contient uniquement des composants d’exécution. 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 recommence à partir de baseet comprend COPY --from=publish pour copier le résultat publié vers 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 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 sont disponibles ici, tels que les ports et les variables d’environnement. Cette étape est utilisée lors de l’exécution à partir de VS en mode rapide (par défaut pour la configuration de débogage). |
| build | Le projet est construit à cette étape. L’image de base du Kit de développement logiciel (SDK) .NET est utilisée, qui contient les composants requis pour générer votre projet. |
| publier | Cette étape dérive de l'étape de construction et publie votre projet, qui sera copié à l'étape finale. |
| final | Cette étape configure comment démarrer l’application et est utilisée en production ou lors de l’exécution à partir de VS en mode normal (par défaut quand la configuration de débogage n’est pas utilisée). |
| aotdebug | Cette étape est utilisée comme base pour la dernière étape lors du 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
La phase de aotdebug est prise en charge uniquement pour les conteneurs Linux. Il est utilisé dans Visual Studio 2022 17.11 et versions ultérieures si Déploiement natif à l’avance (AOT) est activé sur le projet.
Préchauffement du projet
de préchauffement du projet fait référence à une série d’étapes qui se produisent lorsque le profil Docker est sélectionné pour un projet (autrement dit, lorsqu’un projet est chargé ou qu’une prise en charge 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 les performances de débogage et réduit considérablement le temps d’attente pour les tâches longues, telles que 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 les projets à conteneur unique, la variable d’environnement est MS_VS_CONTAINERS_TOOLS_LOGGING_ENABLED, qui se connecte ensuite dans %tmp%\Microsoft.VisualStudio.Containers.Tools. Pour les projets Docker Compose, il s’agit de MS_VS_DOCKER_TOOLS_LOGGING_ENABLED, qui se connecte ensuite dans %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 sous forme de texte brut. Consultez Configurer l’authentification Azure.
Étapes suivantes
Découvrez comment utiliser les étapes 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. Voir Configurer des images de conteneurs pour le débogage.