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.

Novedades de Docker — actualización de agosto 2026

Esta guía la mantengo viva mes a mes. Esto es lo que cambió en el mundo Docker desde la última revisión:

• Parchea “Copy Fail” ya, si no lo has hecho (CVE-2026-31431). La historia de seguridad más seria del año en contenedores: un fallo del kernel de Linux en la interfaz criptográfica AF_ALG (CVSS 7.8, presente en kernels 4.14 a 6.19.12) permite a un proceso sin privilegios escribir en la caché de páginas y escalar a root — y funciona como escape de contenedor, porque el perfil seccomp por defecto de Docker permitía sockets AF_ALG. Se está explotando activamente (CISA lo añadió a su catálogo KEV en mayo). Estás a salvo si corres Docker Engine 29.4.3+ (su perfil seccomp por defecto ya bloquea AF_ALG) o un kernel parcheado (6.18.22+, 6.19.12+ o 7.0+). Docker Desktop retroportó el parche del kernel a su VM en la versión del 2 de julio.
• Compose v5.3 añadió init containers nativos: servicios que corren y terminan antes de que arranque tu aplicación (migraciones, seeds, permisos) declarados directamente en el compose.yaml, sin más trucos de depends_on + servicio de un solo uso.
• La versión de julio de Docker Desktop corrigió el Dashboard que no cargaba volúmenes/imágenes/contenedores, contenedores que ignoraban el timeout de parada configurado y fallos de arranque en kernels ARM de WSL2.

Una moraleja si administras tus propios servidores (un VPS con Coolify, por ejemplo): docker --version y la versión de tu kernel ya son un punto de la checklist de seguridad, no trivia.

¿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.

La relación entre los tres es lo que más cuesta al principio, así que aquí está en diagrama:

flowchart TB
    subgraph local["💻 Tu máquina"]
      D["📄 Dockerfile"] -->|docker build| I["📦 Imagen"]
      I -->|docker run| C["⚙️ Tantos contenedores<br/>como quieras"]
    end
    I -->|docker push| R[("🌐 Registry")]
    R -->|docker pull| I2["📦 La misma imagen"]
    subgraph remote["☁️ Cualquier otra máquina"]
      I2 -->|docker run| C3["⚙️ Comportamiento idéntico"]
    end

Léelo de arriba abajo: escribes un Dockerfile, construyes una imagen a partir de él, y de esa única imagen lanzas tantos contenedores como quieras — en local o, tras pasar por el registry, en cualquier otra máquina con el mismo resultado. Esa última parte es justamente el sentido de Docker.

Docker vs máquina virtual

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

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:

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:

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.