01
Qué es y qué problema resuelve
Una imagen empaqueta una aplicación con su entorno de ejecución. Un build multietapa utiliza el SDK para compilar y deja el runtime en la imagen final.
Esto reduce componentes de ejecución, pero no sustituye la actualización de imágenes, el control de permisos ni el diseño de configuración.
02
Ejemplo paso a paso
Punto de partida Dockerfile didáctico para la consola Laboratorio.csproj del ZIP. Requiere Docker y el contexto correcto; una API necesita la imagen aspnet y configuración de puertos. La imagen no fue ejecutada como parte de este material.
Antes de ejecutar
Requiere Docker y los archivos extraídos del laboratorio en el contexto de construcción, incluido Laboratorio.csproj. Esta imagen ejecuta una consola y termina; una API necesita una imagen ASP.NET, su entrada y configuración HTTP. La construcción debe verificarse en tu entorno.
FROM mcr.microsoft.com/dotnet/sdk:10.0 AS build
WORKDIR /src
COPY *.csproj ./
RUN dotnet restore
COPY . ./
RUN dotnet publish -c Release -o /out
FROM mcr.microsoft.com/dotnet/runtime:10.0
WORKDIR /app
COPY --from=build /out ./
USER $APP_UID
ENTRYPOINT ["dotnet", "Laboratorio.dll"]Cómo funciona
- La primera etapa usa el SDK para restaurar y publicar.
- La segunda copia el artefacto a una imagen de runtime.
- USER establece el usuario de ejecución y ENTRYPOINT inicia la consola.
Resultado esperado: Al construir y ejecutar correctamente, la consola muestra sus comprobaciones y termina. Fija digests para un proceso de entrega reproducible.
03
Cuándo usarlo y qué debes evitar
Construye un artefacto reproducible y ejecútalo con un usuario sin privilegios cuando sea compatible. Mantén secretos fuera de Dockerfile y capas.
Excluye bin, obj y archivos sensibles del contexto con .dockerignore. Comprueba arranque, señales de terminación y persistencia externa según la aplicación; una consola del laboratorio termina al acabar sus comprobaciones.
Ampliación opcional · contexto y variantes del tema
Entregable y criterios de cierre
Entrega un repositorio con instrucciones desde cero, modelo de dominio, contratos HTTP, decisión de arquitectura, estrategia de solapamientos y matriz de permisos. Añade evidencia de pruebas de lectura/escritura, aislamiento entre grupos y conflictos concurrentes. Registra versiones y cómo actualizar paquetes; explica qué fragmentos adaptaste y con qué proveedor los verificaste.
La definición de terminado exige que otra persona pueda ejecutar el proyecto, que una entrada inválida no persista, que una identidad ajena no produzca efectos y que un fallo interno no filtre detalles. En producción exige alertas accionables, migraciones ensayadas y recuperación practicada. Este material enseña a construir esa evidencia; completar una lectura no certifica que una implementación futura ya cumpla todos los criterios.
04 · Práctica guiada · opcional
Practica lo aprendido
Crea .dockerignore y construye la consola del laboratorio en tu entorno.
- 01Prepara el ejemplo con las dependencias indicadas en «Antes de ejecutar».
- 02Crea .dockerignore y construye la consola del laboratorio en tu entorno.
- 03Comprueba y registra el resultado: Al construir y ejecutar correctamente, la consola muestra sus comprobaciones y termina. Fija digests para un proceso de entrega reproducible.
Ver solución orientativa
Comprueba nombre de DLL, usuario, salida y código de retorno. Explica qué cambiaría para servir HTTP con una API.
05
Comprueba lo aprendido
Responde antes de abrir la explicación. Esta comprobación es opcional y no guarda una puntuación.
01¿La imagen runtime puede alojar cualquier API ASP.NET Core sin cambios?
No. Para ASP.NET Core utiliza la imagen y configuración adecuadas.
02¿Por qué la imagen de esta consola no prepara por sí sola una API HTTP?
La consola usa runtime y termina al acabar sus comprobaciones. Una API requiere el runtime ASP.NET, su propio punto de entrada y configuración HTTP, además de verificaciones operativas.
Cómo demostrar el objetivo
Compara tu práctica con estos resultados. Si solo diseñaste una prueba, registra su resultado como esperado, no como observado.
- El Dockerfile compila con SDK y copia la publicación a una imagen runtime.
- La ejecución de la consola termina con código de éxito y sin SDK en la etapa final; requiere Docker disponible.
Qué debes recordar
- Un build multietapa separa herramientas y runtime.
- El contexto de construcción debe excluir secretos y resultados previos.
Tu cuaderno · notas personales
Cuaderno local
Tus notas del contenido
Se guardan únicamente en este dispositivo. Puedes exportarlas cuando quieras.
Material de apoyo · descarga, glosario y referencias
Explicaciones, ejemplos y prácticas propios de Academia de Software. Los fragmentos de integración requieren las dependencias indicadas; el ZIP contiene el núcleo de consola. Las lecturas externas se consultan en su sitio original y conservan sus condiciones. Procedencia y condiciones de uso.