Guía completa de Docker en 2026: contenedores, Dockerfile y Compose

Docker es la plataforma de contenedores que empaqueta tu aplicación con todas sus dependencias en una unidad portable que corre igual en tu laptop, en un VPS o en la nube. En 2026 ya no es una opción “moderna”: es el estándar. Según la encuesta de Stack Overflow 2025, el 71,1 % de los desarrolladores usa Docker —un salto de 17 puntos en un solo año, la mayor subida de cualquier tecnología encuestada— y Docker Hub sirve más de 20 000 millones de descargas de imágenes al mes.

Pero el Docker de 2026 no es el de los tutoriales de hace tres años: docker-compose (con guion) está muerto, Compose saltó a la v5, el Engine 29 cambió su motor de almacenamiento de imágenes, las Docker Hardened Images se volvieron gratuitas y ahora puedes ejecutar modelos de IA en local con docker model run. Esta guía cubre desde cero hasta ese estado del arte: qué es Docker, cómo escribir un buen Dockerfile, cómo usar Compose hoy y qué novedades te conviene adoptar.

¿Qué es Docker y para qué sirve?

Docker resuelve el problema más viejo del desarrollo: “en mi máquina funciona”. Un contenedor es un proceso aislado que lleva dentro todo lo que tu aplicación necesita —runtime, librerías, configuración— y comparte el kernel del sistema operativo anfitrión. El resultado: entornos idénticos en desarrollo, pruebas y producción.

Tres conceptos que debes distinguir desde el día uno:

• Imagen: la plantilla inmutable (el “instalador”): capas de archivos + metadatos. Se construye una vez y se distribuye por un registry como Docker Hub.
• Contenedor: una instancia en ejecución de esa imagen (el “proceso”). Puedes lanzar diez contenedores de la misma imagen.
• Dockerfile: el archivo de texto con la receta para construir la imagen.

Docker vs máquina virtual

La confusión clásica. Un contenedor no es una máquina virtual ligera; es un proceso aislado:

	Contenedor (Docker)	Máquina virtual
Kernel	Comparte el del anfitrión	Uno propio por VM
Arranque	Milisegundos–segundos	Minutos
Tamaño	MBs (una imagen alpine ronda 5 MB)	GBs
Aislamiento	A nivel de proceso (namespaces, cgroups)	Hardware virtualizado completo
Uso típico	Empaquetar y desplegar aplicaciones	Aislar sistemas operativos completos

No compiten: en Windows y macOS, Docker Desktop ejecuta los contenedores dentro de una VM Linux utilitaria. Y en muchos servidores, los contenedores corren sobre VMs en la nube.

Instalar Docker en 2026 (y cuándo hay que pagar)

Aquí hay un matiz que mucha gente descubre tarde:

• Docker Engine (Linux) es open source (Apache 2.0) y gratuito siempre, también para empresas. En un servidor Ubuntu/Debian se instala con el repositorio oficial en dos minutos.
• Docker Desktop (Windows, macOS, Linux con GUI) es gratuito para uso personal, educación, open source y empresas pequeñas, pero requiere suscripción de pago para uso comercial en organizaciones con más de 250 empleados o más de 10 millones de USD de ingresos anuales. Los planes de pago van de 9 a 24 USD por usuario/mes (precios oficiales).

En Windows, Docker Desktop funciona sobre WSL2 y es la vía recomendada. Si tu organización supera el umbral de licencia y no quiere pagar, las alternativas maduras en 2026 son:

Alternativa	Plataforma	Nota
Podman + Podman Desktop	Linux, Windows, macOS	Gratuito, sin daemon, rootless por diseño; CLI compatible con Docker
Rancher Desktop	Windows, macOS, Linux	Gratuito (SUSE), trae Kubernetes integrado
OrbStack	Solo macOS	Rapidísimo; de pago para uso empresarial
Colima	macOS, Linux	Gratuito, minimalista, vía CLI

Verifica la instalación con:

docker version        # Engine 29.x en 2026
docker compose version  # v5.x — ojo: SIN guion
docker run hello-world

Los comandos esenciales

El 90 % del día a día con Docker cabe en esta tabla:

Comando	Qué hace
docker run -d -p 8080:80 nginx	Descarga (si hace falta) y arranca un contenedor en segundo plano, mapeando el puerto 8080 → 80
docker ps / docker ps -a	Lista contenedores activos / todos
docker logs -f <nombre>	Sigue los logs de un contenedor
docker exec -it <nombre> sh	Abre una shell dentro del contenedor
docker build -t miapp:1.0 .	Construye una imagen desde el Dockerfile del directorio
docker images	Lista imágenes locales
docker stop / docker rm	Detiene / elimina un contenedor
docker system prune	Limpia contenedores parados, redes e imágenes colgantes (recupera GBs)
docker init	Genera Dockerfile, compose.yaml y .dockerignore adaptados a tu proyecto
docker debug <nombre>	Shell de depuración con herramientas propias, incluso en contenedores sin shell (ahora gratis para todos)

Dos incorporaciones recientes que merecen mención: docker init detecta tu stack (Node, Python, Go, PHP, Rust…) y te genera los archivos de arranque con buenas prácticas incluidas — la mejor forma de empezar un proyecto hoy —, y docker debug te da una shell con toolbox completo hasta en imágenes distroless que no traen ni ls.

Dockerfile a fondo: la receta de tu imagen

Un Dockerfile moderno para una app Node se ve así (el mismo patrón aplica a PHP, Python o Go):

# --- Etapa 1: build ---
FROM node:24-alpine AS build
WORKDIR /app

# 1) Solo los manifiestos primero: la capa de dependencias se cachea
COPY package*.json ./
RUN --mount=type=cache,target=/root/.npm npm ci

# 2) Después el código (cambia más a menudo, invalida menos caché)
COPY . .
RUN npm run build

# --- Etapa 2: runtime ---
FROM node:24-alpine
WORKDIR /app
ENV NODE_ENV=production

COPY --from=build /app/dist ./dist
COPY --from=build /app/node_modules ./node_modules

# Usuario no-root: si comprometen la app, no comprometen el contenedor
USER node

HEALTHCHECK --interval=30s --timeout=3s \
  CMD wget -qO- http://localhost:3000/health || exit 1

EXPOSE 3000
CMD ["node", "dist/server.js"]

Las decisiones que hacen bueno (o malo) un Dockerfile en 2026:

1. Multi-stage builds, siempre que compiles

La etapa build lleva compiladores y dependencias de desarrollo; la etapa final solo el artefacto. Es la técnica número uno para pasar de imágenes de 1 GB a imágenes de 100 MB. Documentación oficial.

2. Ordena las capas para explotar la caché

Docker cachea cada instrucción como una capa. Regla de oro: lo que menos cambia, arriba. Por eso se copian package*.json e instalan dependencias antes de copiar el código. Añade cache mounts (RUN --mount=type=cache) para que ni siquiera un cambio de dependencias descargue todo de cero.

3. Elige bien la imagen base

• alpine — mínima (~5 MB). Ojo: usa musl en vez de glibc y algún paquete nativo puede dar guerra.
• slim (Debian) — el equilibrio seguro para la mayoría.
• Distroless — sin shell ni gestor de paquetes: superficie de ataque mínima.
• Docker Hardened Images — la novedad grande: imágenes endurecidas, con CVEs mitigados y mantenidas por Docker, que eran de pago y desde diciembre de 2025 son gratuitas y open source (más de 1000 imágenes en el catálogo). En 2026 son mi primera opción como base de producción.

Fija siempre versión (node:24-alpine, no node:latest) y, en producción, considera fijar el digest (@sha256:...).

4. Nunca metas secretos en la imagen

Nada de tokens en ARG o ENV: quedan grabados en las capas para siempre. Usa build secrets:

docker build --secret id=npmrc,src=$HOME/.npmrc .

RUN --mount=type=secret,id=npmrc,target=/root/.npmrc npm ci

5. .dockerignore, usuario no-root y HEALTHCHECK

Un .dockerignore (mínimo: node_modules, .git, .env) acelera el build y evita filtrar archivos sensibles. USER no-root limita el daño de un compromiso. HEALTHCHECK permite que Docker (y Compose) sepan si tu app funciona, no solo si el proceso existe.

6. SBOM y provenance: la cadena de suministro importa

BuildKit puede generar y adjuntar atestaciones (inventario de software SBOM + procedencia SLSA) a tus imágenes:

docker buildx build --sbom=true --provenance=true -t miapp:1.0 .

Desde Engine 29.6 incluso puedes consultarlas vía API. Si vendes software a empresas, esto ya te lo están pidiendo. Complementa con Docker Scout para el análisis continuo de vulnerabilidades.

Docker Compose en 2026: v5 y sin guion

Si un tutorial te dice docker-compose up, es viejo. Compose v1 (Python, con guion) alcanzó su fin de vida en julio de 2023; el comando actual es docker compose, un plugin del CLI escrito en Go. Y en diciembre de 2025 llegó Compose v5 “Mont Blanc” — se saltaron la v3 y la v4 a propósito, para que nadie confunda la versión del programa con los formatos de archivo 2.x/3.x heredados, que también están obsoletos.

Lo que define a Compose hoy:

• El archivo se llama compose.yaml (preferido sobre docker-compose.yml) y ya no lleva version: — esa clave se ignora.
• docker compose build delega en Docker Bake, el mismo motor que docker build: mismas capacidades, misma caché.
• Puedes publicar y consumir proyectos Compose como artefactos OCI o repos Git (docker compose publish).

Un compose.yaml realista para desarrollo:

services:
  app:
    build: .
    ports:
      - "3000:3000"
    environment:
      DATABASE_URL: postgres://app:secret@db:5432/app
    depends_on:
      db:
        condition: service_healthy
    develop:
      watch:
        - action: sync
          path: ./src
          target: /app/src
        - action: rebuild
          path: package.json

  db:
    image: postgres:17-alpine
    environment:
      POSTGRES_USER: app
      POSTGRES_PASSWORD: secret
    volumes:
      - db-data:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U app"]
      interval: 5s
      retries: 10

  adminer:
    image: adminer
    ports:
      - "8081:8080"
    profiles: [debug]

volumes:
  db-data:

Tres funcionalidades que cambian el día a día y que poca gente usa:

1. Watch mode — docker compose watch sincroniza tu código dentro del contenedor al guardar (o reconstruye si cambia package.json). Hot reload sin bind mounts frágiles. Docs.
2. Profiles — servicios opcionales (como el adminer de arriba) que solo arrancan con docker compose --profile debug up. Docs.
3. include — compón tu stack a partir de archivos Compose de otros equipos o repos. Docs.

¿Trabajas con estos YAML a diario? Mi conversor JSON ⇄ YAML te ahorra más de un dolor de cabeza al depurar la sintaxis.

Qué cambió bajo el capó: Docker Engine 29

La versión mayor Engine 29 (noviembre de 2025) trajo los cambios estructurales más grandes en años. Los que te afectan:

• containerd image store por defecto en instalaciones nuevas: los graph drivers clásicos (overlay2) quedan deprecados. Beneficio directo: soporte nativo de imágenes multi-plataforma (amd64 + arm64 en el mismo tag) y de atestaciones, sin trucos.
• API mínima 1.44: clientes anteriores a Docker 25 dejan de funcionar contra un Engine 29 (hay override en daemon.json si lo necesitas temporalmente).
• nftables experimental como backend de firewall (--firewall-backend=nftables), rumbo a sustituir iptables. Aún no es compatible con Swarm.

A mediados de 2026 el Engine va por la serie 29.6.x y Docker Desktop por la 4.8x, con Kubernetes 1.36 integrado. Si construyes para ARM (Graviton, Apple Silicon, Raspberry Pi), los builds multi-plataforma con --platform linux/amd64,linux/arm64 son ya un flujo de primera clase.

Docker + IA: contenedores para modelos y agentes

La apuesta más visible de Docker en 2025-2026 es la IA generativa, y va mucho más allá del marketing:

• Docker Model Runner (GA desde septiembre de 2025, open source): ejecuta LLMs en local con docker model pull ai/llama3.2 y docker model run, expone una API compatible con OpenAI y distribuye los modelos como artefactos OCI en Docker Hub. Soporta GPUs NVIDIA (CUDA), Apple Silicon y, desde octubre de 2025, AMD/Intel vía Vulkan. Si quieres probar un modelo local sin pelearte con Python, hoy es el camino más corto.
• MCP Catalog y Toolkit: un catálogo curado de servidores MCP (el protocolo que conecta agentes de IA con herramientas) empaquetados como imágenes verificadas — superó el millón de descargas en su primer año. Si no te suena MCP, en el blog explico cómo construir un agente de IA con Laravel y MCP.
• Docker Agent (antes cagent): define agentes y equipos multi-agente en YAML, con modelos locales (Model Runner) o remotos y herramientas MCP. Compose también admite ya un elemento top-level models para declarar stacks agénticos.
• Docker Offload (GA en abril de 2026): mueve el Engine a la nube de Docker cuando tu máquina no da más de sí, incluido en el plan Business.

El patrón de fondo: los contenedores se están convirtiendo en la unidad de distribución también para modelos, servidores MCP y agentes — la misma tesis que desarrollo en la guía de IA agéntica 2026. Y si dejas que un agente escriba código, ejecútalo en un contenedor aislado: te lo cuento en vibe coding seguro.

¿Y en producción? Compose vs Swarm vs Kubernetes

La pregunta del millón, con respuesta corta en 2026:

1. Docker Compose — desarrollo y despliegues en un solo servidor (VPS, side projects, la mayoría de las PyMEs). Con restart: always, healthchecks y un proxy inverso delante cubre más casos de los que se admite en público. Es como sirvo varios de mis proyectos.
2. Docker Swarm — incluido en el Engine, pero en la práctica en modo mantenimiento: sin novedades relevantes y fuera del nuevo backend nftables. Válido si ya lo operas; no lo elegiría para un proyecto nuevo.
3. Kubernetes — el estándar de facto para orquestar a escala (multi-nodo, autoescalado, self-healing). El propio Engine 29 justificó su cambio de almacén de imágenes por “alineación con el ecosistema… plataformas como Kubernetes”. Empieza por un gestionado (EKS, GKE, AKS) o k3s, no por un cluster a mano.

Y no: Kubernetes no “reemplaza” a Docker. Kubernetes orquesta contenedores; las imágenes que despliega se siguen construyendo con Docker/BuildKit. La confusión viene del retiro de dockershim en 2022, que solo afectó a cómo Kubernetes ejecuta contenedores internamente (containerd), no a tus imágenes ni a tus Dockerfiles.

Checklist Docker 2026

• docker compose (sin guion) y compose.yaml sin version:
• docker init para arrancar proyectos nuevos con buenas prácticas
• Multi-stage build + capas ordenadas por frecuencia de cambio + cache mounts
• Base slim/alpine/distroless o una Docker Hardened Image, con versión fijada
• USER no-root, HEALTHCHECK y .dockerignore en todo servicio
• Secretos con --mount=type=secret, jamás en ENV/ARG
• --sbom=true --provenance=true en imágenes que distribuyes
• Builds multi-plataforma si despliegas en ARM
• Escalera de producción: Compose (single-host) → Kubernetes gestionado (multi-nodo)

Preguntas frecuentes

¿Qué es Docker y para qué sirve? Es la plataforma que empaqueta tu app y sus dependencias en contenedores portables que corren igual en cualquier máquina. Elimina el “en mi máquina funciona” y simplifica los despliegues.

¿Qué diferencia hay entre una imagen y un contenedor? La imagen es la plantilla inmutable; el contenedor, una instancia en ejecución de esa plantilla. Una imagen, N contenedores.

¿Docker es gratis? Engine en Linux, siempre. Desktop es gratis salvo uso comercial en organizaciones de más de 250 empleados o 10 M USD de ingresos, donde requiere plan de pago (desde 9 USD/usuario/mes).

¿Dockerfile o Compose? Ambos: el Dockerfile construye la imagen de un servicio; compose.yaml orquesta varios servicios juntos.

¿docker-compose o docker compose? Sin guion. La v1 murió en 2023 y el Compose actual va por la v5.

¿Kubernetes reemplaza a Docker? No: Kubernetes orquesta los contenedores cuyas imágenes construyes con Docker.

Conclusión

Docker en 2026 es dos cosas a la vez: una base que ya deberías dominar —imágenes pequeñas y seguras, Compose v5, buenas prácticas de Dockerfile— y una plataforma que se está reinventando alrededor de la IA, con modelos, servidores MCP y agentes distribuidos como contenedores. La buena noticia es que la inversión rinde doble: lo que aprendes para desplegar tu app es exactamente lo que necesitas para ejecutar IA en local o en tu servidor.

Si tu negocio necesita contenerizar un sistema, montar un despliegue sólido en un VPS o dar el salto a una infraestructura moderna, es justo lo que hago en mi servicio de sistemas a medida. Y si estás empezando: instala Docker, lanza docker init en tu proyecto y cuéntame qué tal.