Hay una frase que ha causado más pérdidas millonarias y horas extra no pagadas que cualquier virus informático en la historia: «Pero si en mi máquina funcionaba…».
Estamos a finales de 2025. El desarrollo web ha madurado. Ya no subimos archivos por FTP modificando código en vivo, ni perdemos tres días configurando XAMPP en un portátil nuevo para que coincida con la versión de PHP del servidor. El estándar de la industria es la inmutabilidad y la portabilidad.
Necesitas un entorno donde tu código, tus librerías, tu configuración de sistema y tus dependencias viajen juntos en un paquete hermético. Necesitas que, si mañana entra un desarrollador Junior al equipo, pueda clonar el repositorio, ejecutar un solo comando y tener todo el sistema (Frontend, Backend, Base de Datos, Caché) funcionando en 5 minutos.
Docker no es una opción; es el sistema operativo de la nube moderna.
Sin embargo, Docker ha cambiado mucho en los últimos años. Si sigues escribiendo tus Dockerfiles como en 2020, o si sigues luchando con el rendimiento en Windows y macOS sin conocer las herramientas de 2026 (como OrbStack o los nuevos mounts de WSL2), estás trabajando con una mano atada a la espalda.
En esta guía exhaustiva, vamos a deconstruir Docker desde la perspectiva del desarrollador web moderno. Aprenderemos a contenerizar los dos stacks más legendarios: el clásico LAMP (para los amantes de WordPress y Laravel) y el omnipresente MERN (para los arquitectos de JavaScript), aplicando las mejores prácticas vigentes hoy.
Capítulo 1: ¿Por qué Docker sigue siendo el Rey en 2026?
A pesar del auge de las plataformas Serverless y el Edge Computing, el contenedor sigue siendo la unidad atómica de despliegue de software. ¿Por qué?
1.1 El Fin de la «Matriz de Dependencias del Infierno»
Imagina que trabajas en dos proyectos. El Proyecto A es un legacy en PHP 7.4. El Proyecto B es una app moderna en PHP 8.5. Si intentas instalar ambas versiones de PHP en tu sistema operativo local (macOS/Windows), entrarás en un conflicto de librerías y rutas que te hará perder días.
Con Docker, cada aplicación vive en su propia burbuja aislada. El Proyecto A tiene su contenedor con PHP 7.4 y sus librerías antiguas. El Proyecto B tiene su contenedor con PHP 8.5 último modelo. Ambos corren simultáneamente, en la misma máquina, sin saber que el otro existe. Docker elimina el «conflicto de versiones» para siempre.
1.2 Máquinas Virtuales vs. Contenedores: La Batalla Final
Para entender la potencia de Docker, debemos diferenciarlo de lo que usábamos antes: las Máquinas Virtuales (VMs, como VirtualBox o VMWare).
-
La Máquina Virtual (El enfoque pesado): Una VM emula hardware completo (tarjeta de red, disco, CPU) y carga un Sistema Operativo completo (Guest OS) encima del tuyo. Si quieres correr una app de 50MB, necesitas arrancar un Windows o Linux entero que pesa gigabytes y tarda minutos en iniciar.
-
El Contenedor (El enfoque quirúrgico): Un contenedor no emula hardware ni carga un SO completo. Comparte el Kernel (el núcleo) del sistema operativo anfitrión (Linux), pero aísla los procesos. Solo carga los binarios y librerías estrictamente necesarios para tu app. Resultado: Arranca en milisegundos y pesa megabytes.
1.3 El Nuevo Ecosistema 2025/2026
El panorama ha evolucionado. Docker Inc. ya no es el único jugador en la ciudad.
-
Alternativas a Docker Desktop: En macOS, herramientas como OrbStack han revolucionado el desarrollo. OrbStack es una alternativa nativa, escrita en Swift y Rust, que consume una fracción de la memoria de Docker Desktop y arranca instantáneamente. En entornos corporativos Linux, Podman gana tracción por su arquitectura sin demonios (daemonless), más segura.
-
Integración con IA: Docker en 2026 permite ejecutar modelos de lenguaje (LLMs) locales, como Llama 3 u Ollama, con acceso directo a la GPU (GPU Passthrough) de forma mucho más sencilla, facilitando la creación de apps con IA generativa privada.
Capítulo 2: Conceptos Nucleares (Repaso Rápido)
Antes de teclear, definamos el vocabulario. Si dominas estos 5 conceptos, dominas Docker.
-
Dockerfile (La Receta): Es un archivo de texto con instrucciones. Dice: «Toma un Linux Alpine, instálale Node.js, copia mis archivos y abre el puerto 3000». Es el plano de construcción.
-
Imagen (La Comida Congelada): Es el resultado de ejecutar el Dockerfile. Es un paquete inmutable y de solo lectura. Una vez creada, la imagen es idéntica en tu PC, en el de tu compañero y en el servidor de producción.
-
Contenedor (La Comida Caliente): Es una instancia viva de una imagen. Puedes tener 10 contenedores corriendo basados en la misma imagen. Si apagas un contenedor, todo lo que no guardaste en un volumen desaparece.
-
Volumen (El Disco Externo): Como los contenedores son efímeros, si guardas datos dentro de ellos (ej. base de datos), los perderás al reiniciar. Los volúmenes son carpetas en tu máquina física que se «conectan» al contenedor para persistir datos.
-
Red / Network (El Cableado): Es la red virtual que permite que tus contenedores se hablen entre sí (ej. que tu WordPress vea a tu MySQL) mediante nombres DNS internos, sin exponer puertos al exterior innecesariamente.
Capítulo 3: El Setup Inicial - Instalando el Motor (Edición 2026)
Antes de tocar código, preparemos el terreno. La instalación depende críticamente de tu sistema operativo.
3.1 Para Usuarios de macOS (Apple Silicon M3/M4)
Si usas un Mac moderno, tienes dos caminos dorados:
-
La Ruta Estándar (Docker Desktop): Sigue siendo sólida, con una excelente interfaz gráfica (GUI) y extensiones de marketplace. Descárgalo de la web oficial de Docker.
-
La Ruta del Rendimiento (OrbStack): Recomendación del Experto. En 2025/2026, OrbStack es el favorito de los desarrolladores senior en Mac. Es una alternativa «drop-in replacement» (funciona igual) para Docker Desktop.
-
Ventajas: Arranca en 2 segundos, consume mínima batería/CPU y ofrece integración de red nativa (puedes acceder a contenedores por dominio
.localsin mapear puertos). -
Instalación:
brew install orbstack
-
3.2 Para Usuarios de Windows (WSL 2 es Obligatorio)
Olvídate de las máquinas virtuales antiguas. Docker en Windows corre sobre WSL 2 (Windows Subsystem for Linux).
-
Abre PowerShell como Administrador e instala WSL:
wsl --install. Esto instalará Ubuntu. Reinicia. -
Instala Docker Desktop para Windows.
-
En la configuración de Docker (Settings > Resources > WSL Integration), asegúrate de marcar la integración con tu distro (Ubuntu).
-
⚠️ REGLA DE ORO DE RENDIMIENTO: Jamás guardes tu código en la carpeta de Windows (
C:\Users\...). Docker en Windows es lento accediendo a archivos de Windows. Debes guardar tu proyecto dentro del sistema de archivos de Linux (\\wsl$\Ubuntu\home\tu-usuario\proyecto). El rendimiento de disco será nativo y volará.
-
3.3 Para Usuarios de Linux (Nativo)
Juegas en casa. Aquí no hay virtualización; es rendimiento puro.
-
Evita el paquete antiguo
docker.iode los repositorios por defecto. -
Sigue la guía oficial para añadir el repositorio de Docker e instala
docker-ce(Community Edition) y el plugindocker-compose-plugin.
3.4 Verificación del Sistema
Abre tu terminal y ejecuta estos comandos para confirmar que tu astillero está operativo y usas la versión moderna de Compose (V2):
# Verificar versión del motor (debe ser 27.x o superior en 2026)
docker –version
# Verificar Compose (Nota: ya no usamos «docker-compose» con guion, eso es V1)
docker compose version
# La prueba de fuego: Hola Mundo
docker run hello-world
Si ves el mensaje «Hello from Docker!», estás listo para construir.
Capítulo 4: Manos a la Obra - El Entorno LAMP Moderno
El stack LAMP (Linux, Apache, MySQL, PHP) sigue moviendo el 40% de la web (gracias a WordPress) y gran parte de las aplicaciones empresariales (Laravel, Symfony). Vamos a crear un entorno LAMP moderno, desacoplado y listo para desarrollar.
4.1 El Dockerfile para PHP-Apache
En lugar de usar un instalador gigante tipo XAMPP, crearemos una imagen personalizada de PHP.
Crea un archivo llamado Dockerfile en la raíz de tu proyecto:
# Usamos PHP 8.4 con Apache (versión oficial prevista para finales de 2025)
FROM php:8.4-apache
# Instalamos extensiones del sistema y de PHP necesarias
# Nota: En 2026 usamos mlocati/docker-php-extension-installer.
# Es un script mágico que simplifica la instalación de dependencias complejas (GD, Zip, Intl).
ADD https://github.com/mlocati/docker-php-extension-installer/releases/latest/download/install-php-extensions /usr/local/bin/
RUN chmod +x /usr/local/bin/install-php-extensions && \
install-php-extensions mysqli pdo_mysql gd zip intl opcache bcmath exif
# Activamos mod_rewrite de Apache para URLs amigables (WordPress/Laravel lo necesitan)
RUN a2enmod rewrite
# Configuramos el directorio de trabajo
WORKDIR /var/www/html
# Copiamos el código
# NOTA: En producción usamos COPY. En desarrollo, esto será sobreescrito por un Volumen.
COPY . .
# Exponemos el puerto estándar web
EXPOSE 80
4.2 El Orquestador: compose.yaml (LAMP)
Ahora, uniremos PHP con MySQL y phpMyAdmin usando Docker Compose. Crea un archivo compose.yaml:
name: mi-proyecto-lamp
services:
# Servicio 1: Nuestro servidor Web (PHP + Apache)
web:
build: . # Construye la imagen usando el Dockerfile del directorio actual
ports:
– «8080:80» # Mapea puerto 8080 de tu PC al 80 del contenedor
volumes:
# BIND MOUNT: La magia del desarrollo.
# Conecta tu carpeta local ‘src’ con ‘/var/www/html’ dentro del contenedor.
# Cualquier cambio que hagas en VS Code se refleja INSTANTÁNEAMENTE.
– ./src:/var/www/html
depends_on:
– db # Espera a que la base de datos inicie
networks:
– lamp-network
environment:
# Configuramos PHP para conectar con la BD usando el nombre del servicio ‘db’
DB_HOST: db
# Servicio 2: Base de Datos
db:
image: mysql:9.0 # Usamos MySQL 9 (versión estable 2025/26)
command: –default-authentication-plugin=mysql_native_password
environment:
MYSQL_ROOT_PASSWORD: rootpassword
MYSQL_DATABASE: mi_app_db
MYSQL_USER: user
MYSQL_PASSWORD: password
volumes:
# VOLUMEN NOMBRADO: Persistencia de datos.
# Si borras el contenedor, los datos se guardan en este volumen gestionado por Docker.
– db_data:/var/lib/mysql
networks:
– lamp-network
# Servicio 3: Gestión Visual de BD
phpmyadmin:
image: phpmyadmin/phpmyadmin
environment:
PMA_HOST: db # Le decimos dónde está la base de datos
ports:
– «8888:80» # Accede en localhost:8888
networks:
– lamp-network
# Definición de volúmenes persistentes
volumes:
db_data:
# Definición de redes
networks:
lamp-network:
driver: bridge
4.3 Levantando el Entorno
-
Crea una carpeta
src/y dentro pon un archivoindex.phpcon. -
Ejecuta en tu terminal:
docker compose up -d –build
up: Levanta los servicios.-
-d: Detached mode (en segundo plano, te devuelve la terminal). -
--build: Fuerza la reconstrucción de la imagen PHP si cambiaste el Dockerfile.
Ahora, abre tu navegador en http://localhost:8080. Verás la info de PHP 8.4. Abre http://localhost:8888 y tendrás phpMyAdmin.
¡Felicidades! Tienes un entorno LAMP profesional, aislado y replicable, sin ensuciar tu sistema operativo.
Capítulo 5: Manos a la Obra - El Stack MERN (Full Stack JS)
Si el stack LAMP es la arquitectura clásica, el stack MERN (MongoDB, Express, React, Node) es el rascacielos moderno. Contenerizar JavaScript tiene un desafío extra: el proceso de compilación (Build step). React (con Vite o Next.js) necesita pre-procesamiento, y Node.js necesita optimización de node_modules.
En 2026, ya no copiamos la carpeta node_modules dentro del contenedor. Usamos Multi-Stage Builds y Docker Compose Watch.
5.1 Optimizando el Backend (Node.js) con Multi-Stage Builds
El error de novato es subir una imagen de 1GB llena de código fuente a producción. Vamos a crear un Dockerfile para nuestra API (Express/NestJS) que compile el código en una etapa y genere una imagen final minúscula y segura.
Archivo: backend/Dockerfile
# ETAPA 1: Builder (Compilación)
# Usamos una imagen completa para instalar dependencias y compilar (si usamos TypeScript)
FROM node:22-alpine AS builder
WORKDIR /app
# Copiamos solo los archivos de dependencias primero (para aprovechar la caché de capas de Docker)
COPY package*.json ./
# Instalamos TODAS las dependencias (incluyendo devDependencies)
RUN npm ci
# Copiamos el código fuente
COPY . .
# Compilamos (ej. TypeScript a JS)
RUN npm run build
# ETAPA 2: Runner (Producción)
# Usamos una imagen limpia. «Alpine» es ligera, pero «Distroless» es más segura (ver Cap. 7).
FROM node:22-alpine AS runner
WORKDIR /app
# Copiamos desde la etapa ‘builder’ solo lo necesario: la carpeta dist y node_modules
COPY –from=builder /app/dist ./dist
COPY –from=builder /app/package*.json ./
# Instalamos solo dependencias de producción (ahorrando espacio)
RUN npm ci –only=production
# Usamos un usuario no-root por seguridad
USER node
EXPOSE 3000
CMD [«node», «dist/main.js»]
5.2 Docker Compose Watch: La Revolución del Desarrollo 2025
Hasta hace poco, desarrollar con Docker y React era doloroso porque el «Hot Reload» fallaba o era lento. Tenías que configurar volumes complejos o usar CHOKIDAR_USEPOLLING.
En 2025/2026, Docker introdujo Docker Compose Watch. Esta característica permite que Docker «observe» tus archivos locales y los sincronice o reconstruya el contenedor automáticamente de forma nativa.
Archivo: compose.yaml (Raíz del proyecto)
name: mern-stack-2026
services:
# BACKEND (API)
api:
build: ./backend
ports:
– «5000:5000»
environment:
MONGO_URI: mongodb://mongo:27017/mern_db
NODE_ENV: development
develop:
# AQUÍ ESTÁ LA MAGIA: Watch
watch:
– action: sync+restart # Si cambia el package.json, reinicia el contenedor
path: ./backend/package.json
target: /app/package.json
– action: sync+restart # Si cambia el código fuente, reinicia
path: ./backend/src
target: /app/src
depends_on:
– mongo
# FRONTEND (React + Vite)
client:
build: ./frontend
ports:
– «3000:3000»
develop:
watch:
– action: sync # Sincroniza archivos en tiempo real para que Vite haga HMR
path: ./frontend/src
target: /app/src
– action: sync
path: ./frontend/public
target: /app/public
# BASE DE DATOS
mongo:
image: mongo:8.0
ports:
– «27017:27017»
volumes:
– mongo_data:/data/db
volumes:
mongo_data:
Para activar este modo superpoderoso, ejecutas:
docker compose watch
Ahora, cualquier cambio en tu React se reflejará instantáneamente en el navegador, y cualquier cambio en tu Node reiniciará el servidor backend automáticamente. Es la experiencia nativa, pero dentro de contenedores.
Capítulo 6: Dev Containers - El Futuro del Entorno de Desarrollo
¿Y si te dijera que no necesitas instalar Node, ni PHP, ni Python en tu ordenador? ¿Ni siquiera Git?
Los Dev Containers (Contenedores de Desarrollo) son la especificación que permite configurar VS Code para que use un contenedor Docker como si fuera tu ordenador completo.
6.1 Cómo funciona
Creas una carpeta .devcontainer en tu proyecto con un archivo devcontainer.json. Cuando abres el proyecto con VS Code, el editor detecta esta carpeta y te pregunta: «¿Deseas reabrir en contenedor?».
Al decir «Sí»:
-
VS Code levanta el contenedor definido.
-
Instala un «VS Code Server» dentro del contenedor.
-
Instala las extensiones que definiste (ESLint, Prettier, PHP Intelephense) dentro del contenedor.
6.2 Ventajas Brutales
-
Onboarding en 5 minutos: Un desarrollador nuevo clona el repo, abre VS Code, espera a que se construya el contenedor y ya tiene el linter, el debugger y las herramientas listas. Cero configuración manual.
-
Entornos Mixtos: Puedes trabajar en un proyecto con Node 14 (legacy) y otro con Node 22 (moderno) en dos ventanas de VS Code distintas sin conflictos de versión.
Ejemplo básico de devcontainer.json:
{
«name»: «MERN Dev Container»,
«image»: «mcr.microsoft.com/devcontainers/javascript-node:22»,
«customizations»: {
«vscode»: {
«extensions»: [
«dbaeumer.vscode-eslint»,
«esbenp.prettier-vscode»,
«mongodb.mongodb-vscode»
]
}
},
«forwardPorts»: [3000, 5000]
}
Capítulo 7: Seguridad y Optimización en 2026
Contenerizar es fácil; contenerizar de forma segura es un arte. En 2026, la seguridad de la cadena de suministro de software es crítica.
7.1 La Regla del «No Root»
Por defecto, los procesos dentro de un contenedor corren como root. Si un hacker logra escapar del contenedor (container breakout), podría tener acceso root a tu servidor anfitrión. Solución: Usa siempre la instrucción USER en tu Dockerfile.
-
Imágenes de Node:
USER node -
Imágenes genéricas: Crea un usuario con
RUN addgroup -S app && adduser -S app -G app.
7.2 Imágenes «Distroless» (Google)
¿Necesitas un editor de texto (Vim/Nano) o una shell (Bash) en tu contenedor de producción? No. Si un atacante entra en tu contenedor, lo primero que buscará es una shell para ejecutar comandos. Las imágenes Distroless de Google contienen solo tu aplicación y sus dependencias de runtime. No hay bash, no hay ls, no hay gestores de paquetes. Son blindadas.
-
Base:
gcr.io/distroless/nodejs22-debian12
7.3 Docker Scout: Tu Auditor de Seguridad
Docker Desktop y CLI ahora integran Docker Scout. Antes de subir tu imagen a producción, ejecuta:
docker scout quickview mi-imagen:latest
Te mostrará un reporte de CVEs (Vulnerabilidades y Exposiciones Comunes) en tu imagen base y tus dependencias. Si usas una imagen node:14, Scout te gritará en rojo que tiene cientos de vulnerabilidades críticas. Actualiza a node:22-alpine y verás cómo bajan a cero.
Capítulo 8: El Futuro - WebAssembly (Wasm) y Docker
Estamos presenciando un cambio de paradigma. Docker ya no es solo «contenedores Linux». Ahora es una plataforma de ejecución agnóstica.
8.1 ¿Qué es Wasm en el contexto de Docker?
WebAssembly (Wasm) permite compilar código (Rust, C++, Go, y pronto más) a un formato binario que corre en cualquier lugar a velocidad casi nativa y con un aislamiento de seguridad superior (Sandbox) al de los contenedores tradicionales. Un contenedor Wasm arranca en microsegundos (vs los milisegundos/segundos de Linux) y pesa una fracción.
8.2 Arquitecturas Híbridas
En 2026, Docker permite correr contenedores Wasm junto a contenedores normales en el mismo compose.yaml.
-
Tu Base de Datos (MySQL) sigue siendo un contenedor Linux pesado.
-
Tus 50 microservicios de lógica de negocio son módulos Wasm ligeros gestionados por Docker.
Esto reduce drásticamente la factura de la nube (menos RAM, menos CPU) y mejora la seguridad.
Conclusión: Del "Pet" al "Cattle"
La filosofía DevOps tiene un mantra: «Trata a tus servidores como ganado (Cattle), no como mascotas (Pets)».
-
Una mascota (tu servidor local antiguo) tiene nombre, si se enferma lo cuidas, y si muere lloras.
-
El ganado (contenedores Docker) tiene números, si uno enferma lo reemplazas por otro nuevo idéntico en segundos.
Docker te da el poder de tratar tu infraestructura como código desechable y reproducible. Con las herramientas de 2026 como OrbStack, Compose Watch y Dev Containers, la fricción de desarrollo ha desaparecido. Ya no hay excusa.
Deja de depurar problemas de configuración ambiental. Empieza a desarrollar valor.
💬 Preguntas y Respuestas (FAQ)
1. ¿Qué diferencia hay entre una imagen Docker "Alpine" y una normal?
1. ¿Qué diferencia hay entre una imagen Docker "Alpine" y una normal?
Una imagen estándar (ej. node:22) suele basarse en Debian o Ubuntu, incluyendo muchas herramientas del sistema que quizás no uses. Pesan 800MB+. Una imagen Alpine (node:22-alpine) se basa en Alpine Linux, una distro minimalista enfocada en seguridad. Pesa solo ~50MB. En 2026, Alpine es el estándar para producción, aunque a veces requiere instalar librerías libc manualmente.
2. ¿Cómo gestiono secretos (contraseñas) en Docker Compose de forma segura?
2. ¿Cómo gestiono secretos (contraseñas) en Docker Compose de forma segura?
Nunca pongas contraseñas en texto plano en el compose.yaml. Usa variables de entorno (${DB_PASSWORD}) cargadas desde un archivo .env que NO subas al repositorio (añádelo al .gitignore). Para mayor seguridad en producción (Docker Swarm/K8s), usa Docker Secrets, que monta los secretos como archivos en memoria solo legibles por el contenedor.
3. ¿Por qué mi contenedor de Node.js se cierra inmediatamente con "Exited with code 0"?
3. ¿Por qué mi contenedor de Node.js se cierra inmediatamente con "Exited with code 0"?
Un contenedor Docker solo vive mientras el proceso principal (PID 1) esté vivo. Si tu script de Node termina (o si usas una herramienta que corre en segundo plano y devuelve el control), Docker piensa que el trabajo terminó y apaga el contenedor. Asegúrate de que tu aplicación corra en primer plano (foreground).
4. ¿Es OrbStack seguro para uso corporativo?
4. ¿Es OrbStack seguro para uso corporativo?
Sí. OrbStack ha ganado tracción masiva en 2025 por ser una implementación optimizada de la virtualización nativa de Apple. Respeta los mismos estándares de aislamiento que Docker Desktop. Sin embargo, en entornos corporativos estrictos, consulta con tu departamento de TI sobre las licencias, ya que OrbStack también tiene planes comerciales para uso profesional.
5. ¿Qué es .dockerignore y por qué es vital?
5. ¿Qué es .dockerignore y por qué es vital?
Funciona igual que .gitignore. Le dice a Docker qué archivos NO copiar dentro de la imagen. Es vital añadir node_modules, .git, .env, y archivos de logs. Si no usas .dockerignore, tu tiempo de build será eterno porque Docker intentará copiar gigabytes de dependencias locales innecesarias al contexto de construcción.
6. ¿Cómo limpio mi disco duro de imágenes y contenedores viejos?
6. ¿Cómo limpio mi disco duro de imágenes y contenedores viejos?
Docker puede comerse tu disco duro rápido. El comando mágico es docker system prune.
-
docker system prune: Borra contenedores parados, redes no usadas e imágenes «dangling» (sin nombre). -
docker system prune -a --volumes: La opción nuclear. Borra TODO lo que no esté en uso, incluyendo imágenes base y volúmenes. Úsalo con cuidado.
7. ¿Puedo usar Docker para aplicaciones de escritorio (GUI)?
7. ¿Puedo usar Docker para aplicaciones de escritorio (GUI)?
Aunque Docker está pensado para servidores y CLI, es posible ejecutar aplicaciones gráficas (como navegadores o IDEs) usando «X11 forwarding» en Linux o utilidades como WSLg en Windows. Sin embargo, no es el uso estándar y el rendimiento gráfico no será nativo.
8. ¿Qué es el "Layer Caching" y cómo acelera mis builds?
8. ¿Qué es el "Layer Caching" y cómo acelera mis builds?
Docker construye las imágenes por capas. Si no cambias una línea del Dockerfile, Docker reutiliza la capa cacheada. Por eso copiamos el package.json antes que el código fuente. Así, si cambias tu código pero no tus dependencias, Docker salta la instalación (npm install) y reutiliza la caché, haciendo el build instantáneo.
9. ¿Debo usar docker-compose o docker compose?
9. ¿Debo usar docker-compose o docker compose?
En 2026, debes usar docker compose (con espacio). Esta es la versión V2, reescrita en Go e integrada en el CLI de Docker. La versión con guion (docker-compose) era la V1 (Python) y está obsoleta y retirada en la mayoría de sistemas modernos.
10. ¿Cómo debuggeo un contenedor que falla al arrancar?
10. ¿Cómo debuggeo un contenedor que falla al arrancar?
Si el contenedor se reinicia en bucle (Restart Loop), no puedes entrar con exec.
-
Usa
docker logs <nombre_contenedor>para ver la salida de error (stdout/stderr). -
Si eso no basta, sobreescribe el comando de entrada en el
compose.yamlconcommand: sleep infinity. Esto mantendrá el contenedor «vivo» sin hacer nada, permitiéndote entrar condocker exec -it <id> shy depurar manualmente desde dentro.
