Personalización de imágenes de contenedor para la depuración
Nota:
En esta sección se describe cómo personalizar los contenedores Docker al elegir el tipo de compilación de contenedor Dockerfile. Si usa el tipo de compilación del SDK de .NET, las opciones de personalización son diferentes y la mayoría de la información de esta sección no es aplicable. En su lugar, consulte Inclusión de una aplicación .NET en un contenedor mediante dotnet publish.
Cuando compila en la configuración Depuración, varias de las optimizaciones que realiza Visual Studio ayudan con el rendimiento del proceso de compilación para proyectos en contenedores. El proceso de compilación de aplicaciones en contenedores no es tan sencillo como seguir los pasos descritos en el Dockerfile. La compilación en un contenedor es mucho más lenta que la compilación en el equipo local. Por lo tanto, al compilar en la configuración Debug, Visual Studio compila los proyectos en el equipo local y, a continuación, comparte la carpeta de salida con el contenedor mediante el montaje del volumen. Una compilación con esta optimización habilitada se denomina compilación en modo rápido.
En el modo rápido, Visual Studio llama a docker build con un argumento que le indica a Docker que compile solo la fase base. Puede cambiarlo estableciendo la propiedad MSBuild, DockerfileFastModeStage, que se describe en Propiedades de MSBuild de herramientas de contenedor. Visual Studio controla el resto del proceso sin tener en cuenta el contenido de Dockerfile. Por lo tanto, cuando modifique el archivo Dockerfile, como para personalizar el entorno del contenedor o instalar dependencias adicionales, debe colocar las modificaciones en la primera fase. No se ejecutará ningún paso personalizado colocado en las fases build, publish o final del archivo Dockerfile.
Esta optimización del rendimiento normalmente solo se produce cuando compila en la configuración Debug. En la configuración Release, la compilación se produce en el contenedor tal y como se especifica en el archivo Dockerfile. Puede habilitar este comportamiento para la configuración de versión estableciendo ContainerDevelopmentMode en Rápido en el archivo de proyecto:
<PropertyGroup Condition="'$(Configuration)' == 'Release'">
<ContainerDevelopmentMode>Fast</ContainerDevelopmentMode>
</PropertyGroup>
Si desea deshabilitar la optimización del rendimiento para todas las configuraciones y compilar como se especifica en el archivo Dockerfile, establezca la propiedad ContainerDevelopmentMode en Regular en el archivo del proyecto de la siguiente manera:
<PropertyGroup>
<ContainerDevelopmentMode>Regular</ContainerDevelopmentMode>
</PropertyGroup>
Para restaurar la optimización del rendimiento, quite la propiedad del archivo de proyecto.
Cuando se inicia la depuración (F5), se vuelve a usar un contenedor iniciado previamente, si es posible. Si no desea volver a usar el contenedor anterior, puede usar los comandos Rebuild o Clean en Visual Studio para obligar a Visual Studio a usar un nuevo contenedor.
El proceso de ejecución del depurador depende del tipo de proyecto y del sistema operativo del contenedor:
| Escenario | Proceso del depurador |
|---|---|
| Aplicaciones .NET Core (contenedores de Linux) | Visual Studio descarga vsdbg y lo asigna al contenedor, después se llama con el programa y los argumentos (es decir, dotnet webapp.dll) y luego el depurador se asocia al proceso. |
| Aplicaciones .NET Core (contenedores de Windows) | Visual Studio usa onecoremsvsmon y lo asigna al contenedor, lo ejecuta como punto de entrada y luego Visual Studio se conecta a él y se asocia al programa. |
| Aplicaciones .NET Framework | Visual Studio usa msvsmon y lo asigna al contenedor, lo ejecuta como parte del punto de entrada, donde Visual Studio se puede conectar a él, y se asocia al programa. Es similar a como normalmente se configuraría la depuración remota en otro equipo o máquina virtual. |
Para obtener información sobre vsdbg.exe, vea Depuración fuera de ruta de .NET Core en Linux y OS X desde Visual Studio.
Modificación de la imagen de contenedor para la depuración y producción
Para modificar la imagen de contenedor para la depuración y la producción, modifique la fase base. Agregue las personalizaciones al Dockerfile en la sección de fase base, normalmente la primera sección del Dockerfile. Consulte la referencia de Dockerfile en la documentación de Docker para obtener información sobre los comandos de Dockerfile.
# This stage is used when running from VS in fast mode (Default for Debug configuration)
FROM mcr.microsoft.com/dotnet/aspnet:6.0 AS base
WORKDIR /app
EXPOSE 80
EXPOSE 443
# <add your commands here>
# This stage is used to build the service project
FROM mcr.microsoft.com/dotnet/sdk:6.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"]
Modificación de la imagen de contenedor solo para la depuración
Puede personalizar los contenedores de determinadas maneras para ayudar en la depuración, como la instalación de algo con fines de diagnóstico, sin afectar a las compilaciones de producción.
Para modificar el contenedor solo para la depuración, cree una fase y, a continuación, use la propiedad DockerfileFastModeStage de MSBuild para indicar a Visual Studio que use la fase personalizada al depurar. Consulte la referencia de Dockerfile en la documentación de Docker para obtener información sobre los comandos de Dockerfile.
Nota:
Las instrucciones que se indican aquí se aplican al caso de contenedor único. También puede hacer lo mismo para varios contenedores con Docker Compose, pero las técnicas necesarias para Docker Compose son ligeramente diferentes. Por ejemplo, la fase se controla mediante un valor del archivo dockercompose.debug.yml.
En el ejemplo siguiente, instalamos el paquete procps-ng, pero solo en modo de depuración. Este paquete proporciona el comando pidof, que Visual Studio requiere (cuando el destino es .NET y versiones anteriores), pero no está en la imagen de Mariner que se usa aquí. La fase que usamos para la depuración en modo rápido es debug, una fase personalizada definida aquí. La fase de modo rápido no necesita heredar de la fase build o publish, puede heredar directamente de la fase base, ya que Visual Studio monta un volumen que contiene todo lo necesario para ejecutar la aplicación, como se ha descrito anteriormente en este artículo.
#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:6.0-cbl-mariner2.0 AS base
WORKDIR /app
EXPOSE 80
EXPOSE 443
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:6.0-cbl-mariner2.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"]
En el archivo del proyecto, agregue esta configuración para indicar a Visual Studio que use la fase personalizada debug al depurar.
<PropertyGroup>
<!-- other property settings -->
<DockerfileFastModeStage>debug</DockerfileFastModeStage>
</PropertyGroup>
Personalización de imágenes de depuración con la implementación de AOT
Para incluir la implementación nativa de AOT, se instala el depurador GNU (GDB), pero solo en la imagen usada al depurar, no en la imagen en tiempo de ejecución final. Dockerfile incluye un argumento de compilación LAUNCHING_FROM_VS que puede ser true o false. Si es true, se aplicará la fase aotdebug, que es donde se instala GDB. Tenga en cuenta que Visual Studio solo admite contenedores nativos de AOT y GDB para Linux.
# 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"]
Puede usar aotstage en el Dockerfile para personalizar la imagen que se usa en tiempo de depuración, sin afectar a la imagen final que se usa al no iniciarse en Visual Studio o en fase de producción. Por ejemplo, podría instalar una herramienta para usarla solo durante la depuración.