Mi primer Dockerfile ocupaba 2.1 GB. No exagero. Usaba una imagen base de Ubuntu completa, instalaba todo lo que se me ocurr\u00eda por las dudas, y copiaba el c\u00f3digo sin pensar en las capas. Hoy mis im\u00e1genes de producci\u00f3n pesan entre 60 y 120 MB. Este art\u00edculo es ese camino condensado.<\/p>\n\n\n\n
Un Dockerfile es un archivo de texto con instrucciones que Docker ejecuta en orden para construir una imagen. Cada instrucci\u00f3n crea una nueva capa. Las capas se cachean, lo que hace que los builds sucesivos sean r\u00e1pidos \u2014 si sab\u00e9s ordenarlas bien<\/em>.<\/p>\n\n\n\n Cuando tuve que dockerizar mi primera API .NET en el trabajo, empec\u00e9 con algo que funcionaba pero era terrible. Luego aprend\u00ed a hacerlo bien.<\/p>\n\n\n\n Problemas de esta versi\u00f3n: imagen base enorme, herramientas de desarrollo en producci\u00f3n, SDK completo en runtime, La magia del multi-stage: la imagen final solo contiene el runtime de ASP.NET y el binario publicado. Todo el SDK, las herramientas de build y el c\u00f3digo fuente quedan afuera. El resultado: de 2.1 GB a 82 MB.<\/p>\n\n\n\n Cada instrucci\u00f3n Con el multi-stage build, una imagen base correcta, el orden de capas optimizado y el .dockerignore configurado, pas\u00e9 de im\u00e1genes que tardaban 8 minutos en buildearse y ocupaban gigabytes, a im\u00e1genes que buildean en 90 segundos (o 20 segundos con cache) y pesan menos de 100 MB. En producci\u00f3n, eso se traduce en deploys m\u00e1s r\u00e1pidos, menos espacio en el registry y menor superficie de ataque.<\/p>\n\n\n\n \u2190 Art\u00edculo anterior: Arquitectura interna de Docker<\/a> | Serie Docker Completo<\/strong> | Pr\u00f3ximo: Ciclo de vida de contenedores \u2192<\/em><\/p>\n\n\n \u2190 Art\u00edculo anterior: Por dentro del motor: entendiendo la arquitectura de Docker<\/a> | Serie Docker Completo<\/strong> | Pr\u00f3ximo: docker run y todo lo que nadie te explica del ciclo de vida de un contenedor \u2192<\/a><\/em><\/p>","protected":false},"excerpt":{"rendered":" De un Dockerfile de 2GB a im\u00e1genes de 80MB: multi-stage builds, capas optimizadas, .dockerignore y buenas pr\u00e1cticas reales para .NET y m\u00e1s.<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":true,"jetpack_social_options":{"image_generator_settings":{"template":"highway","default_image_id":0,"font":"","enabled":false},"version":2}},"categories":[233],"tags":[242,240,248,249,215,250],"class_list":["post-1170","post","type-post","status-publish","format-standard","hentry","category-kubernetes","tag-devops","tag-docker","tag-dockerfile","tag-layers","tag-linux","tag-multistage"],"yoast_head":"\nLas instrucciones esenciales<\/h3>\n\n\n\n
# Instrucciones que uso en casi todos mis Dockerfiles:\n\nFROM # imagen base (siempre es la primera instrucci\u00f3n)\nWORKDIR # directorio de trabajo dentro del contenedor\nCOPY # copia archivos del host al contenedor\nRUN # ejecuta un comando durante el build\nENV # variables de entorno\nEXPOSE # documenta el puerto que usa el contenedor\nENTRYPOINT # comando principal del contenedor\nCMD # argumentos por defecto del entrypoint<\/code><\/pre>\n\n\n\nMi primer Dockerfile real: una API .NET 8<\/h2>\n\n\n\n
La versi\u00f3n ingenua (no hagas esto)<\/h3>\n\n\n\n
# ❌ Dockerfile ingenuo - imagen de 2GB+\nFROM ubuntu:22.04\n\nRUN apt-get update && apt-get install -y wget curl git vim dotnet-sdk-8.0\n\nWORKDIR \/app\nCOPY . .\nRUN dotnet build -c Release\n\nEXPOSE 80\nCMD [\"dotnet\", \"run\", \"--project\", \"MiApi\"]<\/code><\/pre>\n\n\n\ndotnet run<\/code> en lugar de un ejecutable publicado, y sin usuario no-root.<\/p>\n\n\n\nLa versi\u00f3n con multi-stage build (la forma correcta)<\/h3>\n\n\n\n
# ✅ Dockerfile con multi-stage build - imagen de ~80MB\n# STAGE 1: Build\nFROM mcr.microsoft.com\/dotnet\/sdk:8.0 AS build\nWORKDIR \/src\n\n# Copiar solo el .csproj primero (aprovecha cache de capas)\nCOPY [\"src\/MiApi\/MiApi.csproj\", \"src\/MiApi\/\"]\nRUN dotnet restore \"src\/MiApi\/MiApi.csproj\"\n\n# Ahora copiar el resto del c\u00f3digo\nCOPY . .\nWORKDIR \"\/src\/src\/MiApi\"\nRUN dotnet build \"MiApi.csproj\" -c Release -o \/app\/build\n\n# STAGE 2: Publish\nFROM build AS publish\nRUN dotnet publish \"MiApi.csproj\" -c Release -o \/app\/publish \/p:UseAppHost=false\n\n# STAGE 3: Runtime (imagen final - solo lo necesario)\nFROM mcr.microsoft.com\/dotnet\/aspnet:8.0 AS final\nWORKDIR \/app\n\n# Usuario no-root\nRUN adduser --disabled-password --gecos \"\" appuser\nUSER appuser\n\nCOPY --from=publish \/app\/publish .\nEXPOSE 80\nENTRYPOINT [\"dotnet\", \"MiApi.dll\"]<\/code><\/pre>\n\n\n\nC\u00f3mo funcionan las capas (y por qu\u00e9 importa el orden)<\/h2>\n\n\n\n
RUN<\/code>, COPY<\/code> o ADD<\/code> crea una capa nueva. Docker cachea cada capa y solo reconstruye las que cambiaron y todas las que vienen despu\u00e9s<\/em>. Esta regla cambia completamente c\u00f3mo orden\u00e1s las instrucciones.<\/p>\n\n\n\n# ❌ Orden incorrecto: cualquier cambio en el c\u00f3digo invalida el restore\nCOPY . . # capa 1 - se invalida con cada cambio\nRUN dotnet restore # capa 2 - se repite innecesariamente\n\n# ✅ Orden correcto: restore se cachea hasta que cambie el .csproj\nCOPY [\"MiApi.csproj\", \".\"] # capa 1 - solo cambia si el proyecto cambia\nRUN dotnet restore # capa 2 - se cachea\nCOPY . . # capa 3 - cambia con el c\u00f3digo\nRUN dotnet build -c Release # capa 4 - solo se repite si hay cambios<\/code><\/pre>\n\n\n\nBuenas pr\u00e1cticas que aplico en todos mis Dockerfiles<\/h2>\n\n\n\n
1. Siempre usar im\u00e1genes base espec\u00edficas, nunca :latest<\/h3>\n\n\n\n
# ❌ Impredecible en producci\u00f3n\nFROM node:latest\nFROM python:latest\n\n# ✅ Reproducible y auditable\nFROM node:20.11.0-alpine3.19\nFROM python:3.12.2-slim-bookworm<\/code><\/pre>\n\n\n\n2. Preferir im\u00e1genes Alpine o Slim<\/h3>\n\n\n\n
# node:20-alpine: ~55 MB\n# node:20-slim: ~180 MB\n# node:20: ~1.1 GB\nFROM node:20-alpine<\/code><\/pre>\n\n\n\n3. Combinar comandos RUN para reducir capas<\/h3>\n\n\n\n
# ❌ Tres capas separadas\nRUN apt-get update\nRUN apt-get install -y curl\nRUN rm -rf \/var\/lib\/apt\/lists\/*\n\n# ✅ Una sola capa, sin cache de apt\nRUN apt-get update && apt-get install -y curl && rm -rf \/var\/lib\/apt\/lists\/*<\/code><\/pre>\n\n\n\n4. El .dockerignore es tan importante como el .gitignore<\/h3>\n\n\n\n
# .dockerignore\n**\/bin\/\n**\/obj\/\n**\/.git\/\n**\/node_modules\/\n**\/*.log\n.env\n.env.local\ndocker-compose*.yml\nREADME.md<\/code><\/pre>\n\n\n\n5. Nunca hardcodear secretos en el Dockerfile<\/h3>\n\n\n\n
# ❌ NUNCA - queda grabado en la capa para siempre\nENV DB_PASSWORD=mipassword123\nRUN curl -H \"Authorization: Bearer TOKEN_SECRETO\" https:\/\/api.ejemplo.com\n\n# ✅ Pasar en runtime como variables de entorno\ndocker run -e DB_PASSWORD=$DB_PASSWORD mi-imagen<\/code><\/pre>\n\n\n\nComandos esenciales para construir y gestionar im\u00e1genes<\/h2>\n\n\n\n
# Construir imagen\ndocker build -t mi-api:1.0.0 .\ndocker build -t mi-api:1.0.0 -f Dockerfile.prod . # Dockerfile espec\u00edfico\ndocker build --no-cache -t mi-api:latest . # Forzar rebuild completo\n\n# Etiquetar\ndocker tag mi-api:1.0.0 mi-api:latest\ndocker tag mi-api:1.0.0 miregistry.local\/mi-api:1.0.0\n\n# Ver capas y tama\u00f1o\ndocker history mi-api:1.0.0\ndocker images mi-api\n\n# Limpiar im\u00e1genes no usadas\ndocker image prune -a # elimina todas las im\u00e1genes sin contenedor activo<\/code><\/pre>\n\n\n\nEl resultado: de 2.1 GB a 82 MB<\/h2>\n\n\n\n
\n\n\n\n
\n