Personalizzare i contenitori Docker in Visual Studio
È possibile personalizzare le immagini del contenitore modificando il Dockerfile generato da Visual Studio quando si aggiunge il supporto Docker al progetto. Sia che si crei un contenitore personalizzato dall'IDE di Visual Studio o si stia configurando una compilazione da riga di comando, è necessario sapere come Visual Studio usa il Dockerfile per compilare i progetti. È necessario conoscere questi dettagli perché, per motivi di prestazioni, Visual Studio segue un processo speciale per la compilazione e l'esecuzione di app in contenitori che non sono evidenti dal Dockerfile.
Si supponga di voler apportare una modifica nel Dockerfile e visualizzare i risultati sia nel debug che nei contenitori di produzione. In tal caso, è possibile aggiungere comandi nel Dockerfile per modificare la prima fase (in genere base). Vedere Modificare l'immagine del contenitore per il debug e l'ambiente di produzione. Tuttavia, se si vuole apportare una modifica solo quando si esegue il debug, ma non in produzione, è necessario creare un'altra fase e usare l'impostazione DockerfileFastModeStage di compilazione per indicare a Visual Studio di usare tale fase per le compilazioni di debug. Vedere Modificare l'immagine del contenitore solo per il debug.
Questo articolo illustra in dettaglio il processo di compilazione di Visual Studio per le app in contenitori, quindi contiene informazioni su come modificare il Dockerfile in modo da influire sia sul debug che sulle compilazioni di produzione o solo per il debug.
Compilazioni Dockerfile in Visual Studio
Nota
Questa sezione descrive il processo di compilazione del contenitore usato da Visual Studio quando si sceglie il tipo di compilazione del contenitore Dockerfile. Se si usa il tipo di compilazione .NET SDK, le opzioni di personalizzazione sono diverse e le informazioni contenute in questa sezione non sono applicabili. Vedere invece Containerize a .NET app with dotnet publish and use the properties described in Customize your container to configure the container build process (Personalizzare il contenitore per configurare il processo di compilazione del contenitore ).
Compilazione a più fattori
Quando Visual Studio compila un progetto che non usa contenitori Docker, richiama MSBuild nel computer locale e genera i file di output in una cartella (in bingenere ) nella cartella della soluzione locale. Per un progetto in contenitori, tuttavia, il processo di compilazione tiene conto delle istruzioni del Dockerfile per la compilazione dell'app in contenitori. Il Dockerfile usato da Visual Studio è suddiviso in più fasi. Questo processo si basa sulla funzionalità di compilazione a più fasi di Docker.
La funzionalità di compilazione a più fasi consente di rendere più efficiente il processo di compilazione dei contenitori e rende i contenitori più piccoli consentendo loro di contenere solo i bit necessari per l'app in fase di esecuzione. La compilazione a più istanze viene usata per i progetti .NET Core, non per i progetti .NET Framework.
La compilazione a più fasi consente di creare immagini del contenitore in fasi che producono immagini intermedie. Si consideri ad esempio un Dockerfile tipico. La prima fase viene chiamata base nel Dockerfile generato da Visual Studio, anche se gli strumenti non richiedono tale nome.
# 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
Le righe nel Dockerfile iniziano con l'immagine ASP.NET da Registro Contenitori Microsoft (mcr.microsoft.com) e creano un'immagine base intermedia che espone le porte 80 e 443 e imposta la directory di lavoro su /app.
La fase successiva è build, che viene visualizzata come segue:
# 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
È possibile notare che la build fase inizia da un'immagine originale diversa dal Registro di aspnetsistema (sdk anziché ), anziché continuare dalla base. L'immagine sdk ha tutti gli strumenti di compilazione e per questo motivo è molto più grande dell'immagine aspnet, che contiene solo i componenti di runtime. Il motivo dell'uso di un'immagine separata diventa chiaro quando si esamina il resto del 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 fase finale inizia di nuovo da basee include per COPY --from=publish copiare l'output pubblicato nell'immagine finale. Questo processo rende possibile che l'immagine finale sia molto più piccola, poiché non è necessario includere tutti gli strumenti di compilazione presenti nell'immagine sdk .
La tabella seguente riepiloga le fasi usate nel dockerfile tipico creato da Visual Studio:
| Fase | Descrizione |
|---|---|
| base | Crea l'immagine di runtime di base in cui viene pubblicata l'app compilata. Le impostazioni che devono essere disponibili in fase di esecuzione sono disponibili qui, ad esempio porte e variabili di ambiente. Questa fase viene usata durante l'esecuzione da Visual Studio in modalità rapida (impostazione predefinita per la configurazione di debug). |
| build | Il progetto viene compilato in questa fase. Viene usata l'immagine di base di .NET SDK, che include i componenti necessari per compilare il progetto. |
| pubblica | Questa fase deriva dalla fase di compilazione e pubblica il progetto, che verrà copiato nella fase finale. |
| final | Questa fase configura come avviare l'app e viene usata nell'ambiente di produzione o quando viene eseguita da Visual Studio in modalità regolare (impostazione predefinita quando non si usa la configurazione di debug). |
| aotdebug | Questa fase viene usata come base per la fase finale durante l'avvio da Visual Studio per supportare il debug in modalità regolare (impostazione predefinita quando non si usa la configurazione di debug). |
Nota
La aotdebug fase è supportata solo per i contenitori Linux. Viene usato in Visual Studio 2022 17.11 e versioni successive se la distribuzione nativa di Ahead Of Time (AOT) è abilitata nel progetto.
Riscaldamento del progetto
Il riscaldamento del progetto fa riferimento a una serie di passaggi che si verificano quando viene selezionato il profilo Docker per un progetto ( ovvero quando viene caricato un progetto o viene aggiunto il supporto docker) per migliorare le prestazioni delle esecuzioni successive (F5 o CTRL+F5). Questo comportamento è configurabile in Strumenti>Opzioni>Strumenti. Ecco le attività eseguite in background:
- Verificare che Docker Desktop sia installato e in esecuzione.
- Assicurarsi che Docker Desktop sia impostato sullo stesso sistema operativo del progetto.
- Eseguire il pull delle immagini nella prima fase del Dockerfile (la
basefase nella maggior parte dei Dockerfile). - Compilare il Dockerfile e avviare il contenitore.
Il riscaldamento avviene solo in modalità veloce, quindi il contenitore in esecuzione ha il volume della cartella dell'app montato. Ciò significa che le modifiche apportate all'app non invalidano il contenitore. Questo comportamento migliora notevolmente le prestazioni di debug e riduce il tempo di attesa per le attività a esecuzione prolungata, ad esempio il pull di immagini di grandi dimensioni.
Abilitare i log dettagliati degli strumenti contenitore
A scopo di diagnostica, è possibile abilitare determinati log di Strumenti contenitore. È possibile abilitare questi log impostando determinate variabili di ambiente. Per i progetti a contenitore singolo, la variabile di ambiente è MS_VS_CONTAINERS_TOOLS_LOGGING_ENABLED, che quindi esegue l'accesso a %tmp%\Microsoft.VisualStudio.Containers.Tools. Per i progetti Docker Compose, è , che quindi esegue l'accesso MS_VS_DOCKER_TOOLS_LOGGING_ENABLEDin %tmp%\Microsoft.VisualStudio.DockerCompose.Tools.
Avviso
Quando la registrazione è abilitata e si usa un proxy di token per l'autenticazione di Azure, è possibile registrare le credenziali di autenticazione come testo normale. Vedere Configurare l'autenticazione di Azure.
Passaggi successivi
Informazioni su come usare le fasi Dockerfile per personalizzare le immagini usate per il debug e la produzione, ad esempio come installare uno strumento nell'immagine solo durante il debug. Vedere Configurare le immagini del contenitore per il debug.