Personalización de contenedores de Docker en Visual Studio
Puede personalizar las imágenes de contenedor editando el Dockerfile que Visual Studio genera al agregar compatibilidad con Docker al proyecto. Tanto si va a compilar un contenedor personalizado desde el IDE de Visual Studio como si configura una compilación de línea de comandos, debe saber cómo Visual Studio usa el Dockerfile para compilar los proyectos. Debe conocer estos detalles porque, por motivos de rendimiento, Visual Studio sigue un proceso especial para compilar y ejecutar aplicaciones en contenedor que no son obvias del Dockerfile.
Supongamos que desea realizar un cambio en el Dockerfile y ver los resultados en la depuración y en los contenedores de producción. En ese caso, puede agregar comandos en el Dockerfile para modificar la primera fase (normalmente base). Consulte Modificación de la imagen de contenedor para la depuración y producción. Sin embargo, si desea realizar un cambio solo al depurar, pero no en producción, debe crear otra fase y usar la configuración de compilación de DockerfileFastModeStage para indicar a Visual Studio que use esa fase para las compilaciones de depuración. Consulte Modificación de la imagen de contenedor solo para la depuración.
En este artículo se explica el proceso de compilación de Visual Studio para aplicaciones en contenedores con cierta detalle y, a continuación, contiene información sobre cómo modificar el Dockerfile para afectar a las compilaciones de depuración y producción, o solo a depuración.
Compilaciones de Dockerfile en Visual Studio
Nota
En esta sección se describe el proceso de compilación del contenedor que Usa Visual Studio 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 información de esta sección no es aplicable. En su lugar, consulte Containerizar una aplicación .NET con dotnet publish y use las propiedades descritas en Personalizar tu contenedor para configurar el proceso de compilación del contenedor.
Construcción multifase
Cuando Visual Studio compila un proyecto que no usa contenedores de Docker, invoca MSBuild en el equipo local y genera los archivos de salida en una carpeta (normalmente bin) en la carpeta de la solución local. Sin embargo, para un proyecto en contenedor, el proceso de compilación tiene en cuenta las instrucciones de Dockerfile para compilar la aplicación en contenedor. El Dockerfile que usa Visual Studio se divide en varias fases. Este proceso se basa en la característica de compilación de varias fases de Docker.
La característica de compilación de varias fases ayuda a que el proceso de creación de contenedores sea más eficaz y hace que los contenedores sean más pequeños al permitirles contener solo los bits que la aplicación necesita en tiempo de ejecución. La compilación de varias fases se usa para proyectos de .NET Core, no para proyectos de .NET Framework.
La construcción en múltiples etapas permite crear imágenes de contenedor en fases que generan imágenes intermedias. Por ejemplo, considere un Dockerfile típico. La primera fase se denomina base en el Dockerfile que Visual Studio genera, aunque las herramientas no requieren ese nombre.
# 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
Las líneas del Dockerfile comienzan con la imagen de ASP.NET de Microsoft Container Registry (mcr.microsoft.com) y crean una imagen intermedia base que expone los puertos 80 y 443, y establece el directorio de trabajo en /app.
La siguiente fase es build, que aparece de la siguiente manera:
# 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
Puede ver que la fase de build comienza desde una imagen original diferente del registro (sdk en lugar de aspnet), en vez de continuar desde la base. La imagen de sdk tiene todas las herramientas de compilación y, por ese motivo, es mucho más grande que la imagen de aspnet, que solo contiene componentes en tiempo de ejecución. El motivo del uso de una imagen independiente queda claro cuando se examina el 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 final se inicia de nuevo desde base e incluye COPY --from=publish para copiar la salida publicada en la imagen final. Este proceso permite que la imagen final sea mucho más pequeña, ya que no es necesario incluir todas las herramientas de compilación que estaban en la imagen de sdk.
En la tabla siguiente se resumen las fases usadas en el dockerfile típico creado por Visual Studio:
| Etapa | Descripción |
|---|---|
| base | Crea la imagen base de tiempo de ejecución donde se publica la aplicación compilada. Las configuraciones que deben estar disponibles en tiempo de ejecución, como los puertos y las variables de entorno. Esta fase se usa cuando se ejecuta desde VS en modo rápido (valor predeterminado para la configuración de depuración). |
| compilación | El proyecto se construye en esta fase. Se usa la imagen base del SDK de .NET, que tiene los componentes necesarios para compilar el proyecto. |
| publicar | Esta fase deriva de la fase de compilación y publica el proyecto, que se copiará en la fase final. |
| final | Esta fase configura cómo iniciar la aplicación y se usa en producción o cuando se ejecuta desde VS en modo normal (valor predeterminado cuando no se usa la configuración de depuración). |
| aotdebug | Esta fase se usa como base para la fase final al iniciar desde VS para admitir la depuración en modo normal (valor predeterminado cuando no se usa la configuración de depuración). |
Nota
La etapa aotdebug solo es compatible con contenedores de Linux. Se usa en Visual Studio 2022 17.11 y versiones posteriores si la implementación nativa por adelantado (AOT) está habilitada en el proyecto.
Preparación del proyecto
Preparación del proyecto hace referencia a una serie de pasos que tienen lugar cuando se selecciona el perfil de Docker para un proyecto (es decir, cuando se carga un proyecto o se agrega compatibilidad con Docker) para mejorar el rendimiento de las ejecuciones posteriores (F5 o Ctrl+F5). Este comportamiento se puede configurar en Herramientas>Opciones>Herramientas de contenedor. Estas son las tareas que se ejecutan en segundo plano:
- Compruebe que Docker Desktop está instalado y en ejecución.
- Asegúrese de que Docker Desktop esté establecido en el mismo sistema operativo que el proyecto.
- Extraer las imágenes de la primera fase del Dockerfile (la fase
baseen la mayoría de Dockerfiles). - Compile el Dockerfile e inicie el contenedor.
La preparación solo se produce en el modo Rápido, por lo que el contenedor en ejecución tiene el volumen de la carpeta app montado. Esto significa que los cambios en la aplicación no invalidan el contenedor. Este comportamiento mejora significativamente el rendimiento de la depuración de software y reduce el tiempo de espera para tareas de larga duración, como descargar imágenes grandes.
Habilitación de registros detallados de herramientas de contenedor
Para fines de diagnóstico, puede habilitar determinados registros de herramientas de contenedor. Puede habilitar estos registros estableciendo determinadas variables de entorno. Para proyectos de contenedor únicos, la variable de entorno es MS_VS_CONTAINERS_TOOLS_LOGGING_ENABLED, que, a continuación, registra en %tmp%\Microsoft.VisualStudio.Containers.Tools. En el caso de proyectos de Docker Compose, es MS_VS_DOCKER_TOOLS_LOGGING_ENABLED, que después se registra en %tmp%\Microsoft.VisualStudio.DockerCompose.Tools.
Advertencia
Cuando se habilita el registro y se utiliza un proxy de token para la autenticación de Azure, las credenciales de autenticación podrían registrarse como texto plano. Consulte Configuración de la autenticación de Azure.
Pasos siguientes
Obtenga información sobre cómo usar las fases de Dockerfile para personalizar las imágenes usadas para la depuración y producción, por ejemplo, cómo instalar una herramienta en la imagen solo al depurar. Consulte Configuración de imágenes de contenedor para depurar.