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 va a configurar una compilación de línea de comandos, debe conocer la forma en que Visual Studio usa el archivo 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 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 Inclusión de una aplicación .NET en un contenedor mediante dotnet publish y use las propiedades descritas en Personalización del contenedor para configurar el proceso de compilación del contenedor.
Compilación de varias fases
Cuando Visual Studio compila un proyecto que no usa contenedores de Docker, invoca a MSBuild en el equipo local y genera los archivos de salida en una carpeta (normalmente bin) dentro de la carpeta de local de la solución. Sin embargo, en un proyecto en contenedores el proceso de compilación tiene en cuenta las instrucciones del archivo Dockerfile para compilar la aplicación en contenedores. El archivo 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 hace más eficaz el proceso de compilación de contenedores y hace que los contenedores sean más pequeños, lo que les permite contener solo los bits que la aplicación necesita en tiempo de ejecución. La compilación de varias fases se usa para los proyectos de .NET Core, no para los proyectos de .NET Framework.
La compilación de varias fases permite crear imágenes de contenedor en fases que producen imágenes intermedias. A modo de ejemplo, plantéese usar un Dockerfile típico. Se llama a base la primera fase en el Dockerfile que genera Visual Studio, 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 en el Dockerfile comienzan con la imagen 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 se muestra 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 build se inicia a partir de una imagen original diferente del registro (sdk, en vez de aspnet), en lugar de continuar desde la base. La imagen sdk tiene todas las herramientas de compilación y, por esa razón, es mucho más grande que la imagen ASPNET, que solo contiene componentes en tiempo de ejecución. El motivo por el que se usa una imagen independiente queda claro cuando se examina el resto del archivo 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 tiene que incluir todas las herramientas de compilación que se encontraban en la imagen sdk.
En la tabla siguiente se resumen las fases por las que se pasan en el Dockerfile típico creado por Visual Studio:
| Fase | Descripción |
|---|---|
| base | Crea la imagen en tiempo de ejecución base donde se publica la aplicación compilada. La configuración que debe estar disponible en tiempo de ejecución, por ejemplo, los puertos y las variables de entorno. Esta fase se usa cuando se ejecuta a través de VS en modo rápido (valor predeterminado de la configuración de depuración). |
| build | El proyecto viene integrado 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 fase de producción o cuando se ejecuta en VS en modo normal (valor predeterminado cuando no se usa la configuración de depuración). |
| aotdebug | Esta fase se usa como punto de partida para la fase final al iniciarse en VS para incluir la depuración en modo normal (valor predeterminado cuando no se usa la configuración de depuración). |
Nota:
La fase aotdebug solo se admite en contenedores de Linux. Se usa en Visual Studio 2022 17.11 y versiones posteriores si está habilitada la implementación de Ahead Of Time (AOT) nativo en el proyecto.
Preparación del proyecto
La preparación del proyecto se refiere a una serie de pasos que se producen cuando se selecciona el perfil de Docker de un proyecto (es decir, cuando se carga un proyecto o se agrega compatibilidad con Docker) con el fin de 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:
- Comprobar que Docker Desktop está instalado y en ejecución.
- Asegurarse 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). - Compilar el Dockerfile e iniciar 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 cualquier cambio en la aplicación no debe invalidar el contenedor. Este comportamiento mejora considerablemente el rendimiento de depuración y reduce el tiempo de espera de las tareas de larga duración, como la extracción de imágenes de gran tamaño.
Habilitación de registros detallados de herramientas de contenedor
Para fines de diagnóstico, puede habilitar determinados registros de herramientas de contenedor. Para habilitar estos registros, puede establecer 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 el registro está habilitado y usa un proxy de token para la autenticación de Azure, las credenciales de autenticación se podrían registrar como texto sin formato. Consulte Configurar 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 la depuración.