Anpassa Docker-containrar i Visual Studio
Du kan anpassa dina containeravbildningar genom att redigera Den Dockerfile som Visual Studio genererar när du lägger till Docker-stöd i projektet. Oavsett om du skapar en anpassad container från Visual Studio IDE eller konfigurerar en kommandoradsversion måste du veta hur Visual Studio använder Dockerfile för att skapa dina projekt. Du måste känna till sådan information eftersom Visual Studio av prestandaskäl följer en särskild process för att skapa och köra containerbaserade appar som inte är uppenbara från Dockerfile.
Anta att du vill göra en ändring i Dockerfile och se resultatet i både felsökning och i produktionscontainrar. I så fall kan du lägga till kommandon i Dockerfile för att ändra den första fasen (vanligtvis base). Se Ändra containeravbildningen för felsökning och produktion. Men om du bara vill göra en ändring vid felsökning, men inte produktion, bör du skapa en annan fas och använda inställningen DockerfileFastModeStage build för att be Visual Studio att använda den fasen för felsökningsversioner. Se Ändra containeravbildningen endast för felsökning.
I den här artikeln beskrivs Visual Studio-byggprocessen för containerbaserade appar i detalj. Den innehåller sedan information om hur du ändrar Dockerfile för att påverka både felsökning och produktionsversioner, eller bara för felsökning.
Dockerfile-kompilering i Visual Studio
Not
I det här avsnittet beskrivs processen för att skapa containrar som Visual Studio använder när du väljer Container build-typen Dockerfile. Om du använder .NET SDK-byggtypen är anpassningsalternativen olika och informationen i det här avsnittet är inte tillämplig. I stället kan du läsa Containerize a .NET app med dotnet publish och använda de egenskaper som beskrivs i Anpassa din container för att konfigurera containerbyggprocessen.
Flerstegsversion
När Visual Studio skapar ett projekt som inte använder Docker-containrar anropar det MSBuild på den lokala datorn och genererar utdatafilerna i en mapp (vanligtvis bin) under din lokala lösningsmapp. För ett containerbaserat projekt tar dock byggprocessen hänsyn till Dockerfile-instruktionerna för att skapa den containerbaserade appen. Dockerfile som Visual Studio använder är indelad i flera steg. Den här processen förlitar sig på Docker multistage build- funktion.
Multistage build-funktionen hjälper till att göra processen med att skapa containrar effektivare och gör containrar mindre genom att tillåta att de endast innehåller de bitar som din app behöver vid körning. Flerstegsversion används för .NET Core-projekt, inte .NET Framework-projekt.
Med flerstegsversionen kan containeravbildningar skapas i steg som skapar mellanliggande avbildningar. Tänk dig till exempel en typisk Dockerfile. Den första fasen kallas base i Dockerfile som Visual Studio genererar, även om verktygen inte kräver det namnet.
# 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
Raderna i Dockerfile börjar med ASP.NET avbildningen från Microsoft Container Registry (mcr.microsoft.com) och skapar en mellanliggande avbildning base som exponerar portarna 80 och 443 och anger arbetskatalogen till /app.
Nästa steg är build, som visas på följande sätt:
# 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
Du kan se att build-fasen börjar från en annan originalavbildning från registret (sdk i stället för aspnet), i stället för att fortsätta från basen. Den sdk avbildningen har alla byggverktyg och därför är den mycket större än aspnet-avbildningen, som bara innehåller körningskomponenter. Orsaken till att du använder en separat avbildning blir tydlig när du tittar på resten av 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"]
Det sista steget startar igen från baseoch innehåller COPY --from=publish för att kopiera publicerade utdata till den slutliga bilden. Den här processen gör det möjligt för den slutliga avbildningen att vara mycket mindre, eftersom den inte behöver inkludera alla byggverktyg som fanns i sdk avbildningen.
I följande tabell sammanfattas de faser som används i den typiska Dockerfile som skapats av Visual Studio:
| Etapp | Beskrivning |
|---|---|
| bas | Skapar basbilden för körning där den byggda appen distribueras. Inställningar som måste vara tillgängliga vid körning går här, till exempel portar och miljövariabler. Det här steget används när du kör från VS i snabbt läge (standard för felsökningskonfiguration). |
| bygga | Projektet byggs i det här steget. .NET SDK-basavbildningen används, som har de komponenter som krävs för att skapa projektet. |
| publicera | Den här fasen härleds från byggfasen och publicerar projektet, som kopieras till den sista fasen. |
| slutlig | Det här steget konfigurerar hur du startar appen och används i produktion eller när den körs från VS i vanligt läge (standard när du inte använder felsökningskonfigurationen). |
| aotdebug | Den här fasen används som bas för den sista fasen när du startar från VS för att stödja felsökning i vanligt läge (standard när du inte använder felsökningskonfigurationen). |
Anteckning
aotdebug-fasen stöds endast för Linux-containrar. Den används i Visual Studio 2022 17.11 och senare om intern distribution i förväg (AOT) är aktiverad i projektet.
Projektuppvärmning
project warmup refererar till en serie steg som inträffar när Docker-profilen väljs för ett projekt (dvs. när ett projekt läses in eller Docker-stöd läggs till) för att förbättra prestandan för efterföljande körningar (F5- eller Ctrl+F5). Det här beteendet kan konfigureras under Tools>Options>Container Tools. Här är de aktiviteter som körs i bakgrunden:
- Kontrollera att Docker Desktop är installerat och körs.
- Kontrollera att Docker Desktop är inställt på samma operativsystem som projektet.
- Ladda ner bilderna i den första fasen av Dockerfile (den
base-fasen i de flesta Dockerfiles). - Skapa Dockerfile och starta containern.
Uppvärmning sker bara i Fast läge, så den körande containern har app-mappen volymmonterad. Det innebär att alla ändringar i appen inte ogiltigförklarar containern. Det här beteendet förbättrar felsökningsprestanda avsevärt och minskar väntetiden för tidskrävande uppgifter, till exempel att hämta stora bilder.
Aktivera detaljerade containerverktygsloggar
I diagnostiksyfte kan du aktivera vissa containerverktygsloggar. Du kan aktivera dessa loggar genom att ange vissa miljövariabler. För enskilda containerprojekt är miljövariabeln MS_VS_CONTAINERS_TOOLS_LOGGING_ENABLED, som sedan loggar in %tmp%\Microsoft.VisualStudio.Containers.Tools. För Docker Compose-projekt är det MS_VS_DOCKER_TOOLS_LOGGING_ENABLED, som sedan loggar in %tmp%\Microsoft.VisualStudio.DockerCompose.Tools.
Varning
När loggning är aktiverat och du använder en tokenproxy för Azure-autentisering kan autentiseringsuppgifter loggas som oformaterad text. Se Konfigurera Azure-autentisering.
Nästa steg
Lär dig hur du använder Dockerfile-stegen för att anpassa avbildningarna som används för felsökning och produktion, till exempel hur du installerar ett verktyg på avbildningen endast vid felsökning. Se Konfigurera containerbilder för felsökning.