Tárolólemezképek testreszabása hibakereséshez

Ez a cikk azt ismerteti, hogyan szabhatja testre a tárolókat a Dockerfile-tároló buildtípusának kiválasztásakor. Ha a .NET SDK buildtípust használja, a testreszabási beállítások eltérőek, és az ebben a szakaszban található információk többsége nem alkalmazható. Ehelyett tekintse meg .NET-alkalmazás tárolása a dotnet publish használatával.

Előfeltételek

• Docker Desktop vagy Podman Desktop.
• A Visual Studio, vagy a Visual Studio 2026 a Podman támogatásához, az ASP.NET és webfejlesztés feladattal, az Azure fejlesztés feladattal, és/vagy a .NET asztali fejlesztési feladattal telepítve.

Gyors mód optimalizálása

Amikor a Hibakeresési konfigurációban épít, a Visual Studio számos optimalizálást végez, amelyek segítenek a tárolóalapú projektek buildelési folyamatának teljesítményében. A tárolóalapú alkalmazások buildelési folyamata nem olyan egyszerű, mint a Dockerfile-ban ismertetett lépések követése. A tárolóban való építés lassabb, mint a helyi gépen való építés. Így amikor a Hibakeresési konfigurációban épít, a Visual Studio ténylegesen a helyi gépen készíti el a projekteket, majd kötet csatlakoztatásával megosztja a kimeneti mappát a tárolóval. Az optimalizálást engedélyező buildeket Gyors módú buildnek nevezzük.

Gyors módban a Visual Studio meghívja docker build vagy podman build egy olyan argumentummal, amely arra utasítja a tároló futtatókörnyezetét, hogy csak a Dockerfile első szakaszát hozza létre (általában a base szakaszt). Ezt úgy módosíthatja, hogy beállítja az MSBuild tulajdonságot, ContainerFastModeStageamely lecseréli az elavultat DockerfileFastModeStage. Lásd: Container Tools MSBuild tulajdonságok. A Visual Studio a dockerfile tartalmától függetlenül kezeli a folyamat többi részét. Ezért amikor módosítja a Dockerfile-t, például testre szabja a tárolókörnyezetet, vagy további függőségeket telepít, a módosításokat az első szakaszban kell elvégeznie. A Dockerfile build, publishvagy final szakaszában elhelyezett egyéni lépések nem lesznek végrehajtva.

Ez a teljesítményoptimalizálás általában csak akkor fordul elő, ha a Hibakeresési konfigurációban épít. A Kiadás konfigurációban a build a Dockerfile-ban megadott tárolóban történik. A kiadási beállításhoz így engedélyezheti ezt a viselkedést: a projektfájlban állítsa be ContainerDevelopmentModeGyors.

<PropertyGroup Condition="'$(Configuration)' == 'Release'">
   <ContainerDevelopmentMode>Fast</ContainerDevelopmentMode>
</PropertyGroup>

Ha le szeretné tiltani az összes konfiguráció teljesítményoptimalizálását, és a Dockerfile által megadott buildelést, állítsa a ContainerDevelopmentMode tulajdonságot úgy, hogy Normál a projektfájlban az alábbiak szerint:

<PropertyGroup>
   <ContainerDevelopmentMode>Regular</ContainerDevelopmentMode>
</PropertyGroup>

A teljesítményoptimalizálás visszaállításához távolítsa el a tulajdonságot a projektfájlból.

A hibakeresés megkezdésekor (F5) a korábban elindított tárolót újra felhasználja a rendszer, ha lehetséges. Ha nem szeretné újra felhasználni az előző tárolót, a Újraépítés vagy a Tisztítás parancsokat használva kényszerítheti a Visual Studio-t, hogy új tárolót használjon.

A hibakereső futtatásának folyamata a projekt és a tároló operációs rendszerének típusától függ:

Forgatókönyv	Hibakereső folyamat
.NET Core-alkalmazások (Linux-tárolók)	A Visual Studio letölti vsdbg, és társítja a tárolóhoz, majd a programjával és argumentumaival (azaz dotnet webapp.dll) meghívja azt.
.NET Core-alkalmazások (Windows-tárolók)	A Visual Studio a onecoremsvsmon elemet a tárolóra leképezi, és belépési pontként futtatja.

Információért a(z) vsdbg.exetémakörben, lásd a .NET Core offroad hibakeresését Linuxon és OS X-en a Visual Studiosegítségével.

Konténerkép módosítása hibakereséshez és éles környezethez

A konténerkép mind hibakereséshez, mind éles környezethez való módosításához módosítsa a Dockerfile első szakaszát, amelyet általában base szakasznak neveznek. A Docker-parancsokkal kapcsolatos információkért tekintse meg a Docker-dokumentáció Dockerfile-referencia.

Jótanács

Ha a projekt az ContainerFastModeStage (vagy az elavult DockerfileFastModeStage) MSBuild tulajdonságot használja, válasszon ki egy megfelelő szakaszt a testreszabásra, amely eljut a végső fázisba és ContainerFastModeStage-ba, ha lehetséges. Lásd a Container Tools build tulajdonságok.

# This stage is used when running from VS in fast mode (Default for Debug configuration)
FROM mcr.microsoft.com/dotnet/aspnet:8.0 AS base
USER $APP_UID
WORKDIR /app
EXPOSE 8080
EXPOSE 8081
# <add your commands here>

# This stage is used to build the service project
FROM mcr.microsoft.com/dotnet/sdk:8.0 AS build
WORKDIR /src
COPY ["WebApplication3/WebApplication3.csproj", "WebApplication3/"]
RUN dotnet restore "WebApplication3/WebApplication3.csproj"
COPY . .
WORKDIR "/src/WebApplication3"
RUN dotnet build "WebApplication3.csproj" -c Release -o /app/build

# This stage is used to publish the service project to be copied to the final stage
FROM build AS publish
RUN dotnet publish "WebApplication3.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", "WebApplication3.dll"]

Tárolórendszerkép módosítása csak hibakereséshez

A tárolókat bizonyos módon testreszabhatja, hogy segítsen a hibakeresésben, például telepíthet valamit diagnosztikai célokra anélkül, hogy befolyásolná az éles verziókat.

Ha csak hibakeresésre szeretné módosítani a tárolót, hozzon létre egy fázist, majd használja az ContainerFastModeStage MSBuild tulajdonságot, hogy a Visual Studio a hibakereséskor az Ön által testre szabott fázist használja. A Docker-parancsokkal kapcsolatos információkért tekintse meg a Docker-dokumentáció Dockerfile-referencia.

Jegyzet

Az itt található utasítások az egytárolós esetre vonatkoznak. Ugyanezt megteheti több tároló esetében is a Docker Compose használatával, de a Docker Compose-hoz szükséges technikák kissé eltérőek. A szakaszt például a dockercompose.debug.yml fájl egyik beállítása vezérli.

Az alábbi példában a csomagot procps-ngtelepítjük, de csak hibakeresési módban. Ez a csomag biztosítja a pidofparancsot, amelyet a Visual Studio igényel (a .NET 5-ös és korábbi célzáskor), de nem szerepel az itt használt Mariner-képen. A gyors módú hibakereséshez használt szakasz debug, egy egyéni szakasz, amely itt van definiálva. A gyors módú szakasznak nem kell örökölnie a build vagy publish szakaszból, közvetlenül a base fázisból örökölhet, mivel a Visual Studio csatlakoztat egy kötetet, amely tartalmazza az alkalmazás futtatásához szükséges összes elemet, a cikk korábbi részében leírtak szerint.

#See https://aka.ms/containerfastmode to understand how Visual Studio uses this Dockerfile to build your images for faster debugging.

# This stage is used when running from VS in fast mode (Default for Debug configuration)
FROM mcr.microsoft.com/dotnet/aspnet:8.0 AS base
USER $APP_UID
WORKDIR /app
EXPOSE 8080
EXPOSE 8081

FROM base AS debug
RUN tdnf install procps-ng -y

# This stage is used to build the service project
FROM mcr.microsoft.com/dotnet/sdk:8.0 AS build
WORKDIR /src
COPY ["WebApplication1/WebApplication1.csproj", "WebApplication1/"]
RUN dotnet restore "WebApplication1/WebApplication1.csproj"
COPY . .
WORKDIR "/src/WebApplication1"
RUN dotnet build "WebApplication1.csproj" -c Release -o /app/build

# This stage is used to publish the service project to be copied to the final stage
FROM build AS publish
RUN dotnet publish "WebApplication1.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", "WebApplication1.dll"]

A projektfájlban adja hozzá ezt a beállítást, amely utasítja a Visual Studiót, hogy hibakereséskor használja a saját szakaszát debug.

  <PropertyGroup>
     <!-- other property settings -->
     <ContainerFastModeStage>debug</ContainerFastModeStage>
  </PropertyGroup>

Az AOT üzembe helyezésével hibakeresési képeket testreszabhat.

A natív AOT-telepítés támogatásához a GNU-hibakereső (GDB) telepítve van, de csak a hibakereséskor használt lemezképre, a végleges futtatókörnyezeti rendszerképre nem. A Dockerfile tartalmaz egy összeállítási argumentumot LAUNCHING_FROM_VS, amely lehet true vagy false. Ha true, a rendszer a aotdebug szakaszt használja, ahol a GDB telepítve van. Vegye figyelembe, hogy a Visual Studio csak a natív AOT- és GDB-tárolókat támogatja Linux-tárolókhoz.

# These ARGs allow for swapping out the base used to make the final image when debugging from VS
ARG LAUNCHING_FROM_VS
# This sets the base image for final, but only if LAUNCHING_FROM_VS has been defined
ARG FINAL_BASE_IMAGE=${LAUNCHING_FROM_VS:+aotdebug}

# ... (other stages omitted)

# This stage is used as the base for the final stage when launching from VS to support debugging in regular mode (Default when not using the Debug configuration)
FROM base as aotdebug
USER root
# Install GDB to support native debugging
RUN apt-get update \
    && apt-get install -y --no-install-recommends \
    gdb
USER app

# This stage is used in production or when running from VS in regular mode (Default when not using the Debug configuration)
FROM ${FINAL_BASE_IMAGE:-mcr.microsoft.com/dotnet/runtime-deps:8.0} AS final
WORKDIR /app
EXPOSE 8080
COPY --from=publish /app/publish .
ENTRYPOINT ["./WebApplication1"]

A Dockerfile aotstage használatával személyre szabhatja a hibakereséskor használt képfájlt anélkül, hogy hatással lenne a Visual Studióból való indításkor vagy éles környezetben alkalmazott végső képre. Például telepíthet egy eszközt, amely csak hibakeresés során használható.

Kapcsolódó tartalom

• Docker-tárolók testreszabása a Visual Studio-ban
• Tárolóprojekt létrehozása a parancssorból