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 la 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 di compilazione DockerfileFastModeStage 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. Consultare invece Containerizzare un'app .NET con dotnet publish e utilizzare le proprietà descritte in Personalizzare il contenitore per configurare il processo di compilazione del contenitore.
Compilazione multistadio
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 genere bin) 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 intermedia base 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 fase build inizia da un'immagine originale diversa dal Registro di sistema (sdk anziché aspnet), anziché continuare dalla base. L'immagine sdk include 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 il COPY --from=publish per 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). |
| costruire | 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. |
| pubblicare | Questa fase deriva dalla fase di compilazione e pubblica il progetto, che verrà copiato nella fase finale. |
| finale | 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 fase aotdebug è supportata solo per i contenitori Linux. Viene utilizzato in Visual Studio 2022 17.11 e versioni successive se la distribuzione nativa Ahead Of Time (AOT) è abilitata nel progetto.
Riscaldamento del progetto
Project warmup fa riferimento a una serie di passaggi che si verificano quando il profilo Docker viene selezionato per un progetto (ossia quando un progetto viene caricato o viene aggiunto il supporto Docker) per migliorare le prestazioni delle esecuzioni successive (F5 o CTRL+F5). Questo comportamento è configurabile in Strumenti di >Opzioni>Strumenti contenitore. 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.
- Scaricare le immagini nella prima fase del Dockerfile (la fase
basenella maggior parte dei Dockerfile). - Compilare il Dockerfile e avviare il contenitore.
Il riscaldamento avviene solo in modalità veloce, quindi il contenitore in esecuzione ha l'app volume montato nella cartella. 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 diagnostico, è possibile abilitare determinati log degli Strumenti contenitore. È possibile abilitare questi log impostando determinate variabili di ambiente. Per i progetti a contenitore singolo, la variabile di ambiente è impostata su MS_VS_CONTAINERS_TOOLS_LOGGING_ENABLED, che viene poi registrata in %tmp%\Microsoft.VisualStudio.Containers.Tools. Per i progetti Docker Compose, è MS_VS_DOCKER_TOOLS_LOGGING_ENABLED, che quindi si connette in %tmp%\Microsoft.VisualStudio.DockerCompose.Tools.
Avvertimento
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. Consulta Configura le immagini del contenitore per il debug.