docker exec y docker logs

docker logs: ver el output de un contenedor

docker logs mi-web
docker logs -f mi-web       # -f = follow, sigue mostrando en vivo (como tail -f)
docker logs --tail 50 mi-web
docker logs --since 10m mi-web

Muestra lo que el proceso principal del contenedor escribió a stdout/stderr — es la primera herramienta para debuggear “¿por qué mi contenedor no arranca / se cae?”.

docker exec: correr un comando dentro de un contenedor ya corriendo

docker exec -it mi-web bash

Abre una sesión interactiva de bash dentro de un contenedor que ya está corriendo — a diferencia de docker run -it (que crea uno nuevo), exec entra al que ya existe.

docker exec mi-web ls /app          # correr un comando puntual, sin sesión interactiva
docker exec -it mi-db psql -U postgres  # entrar directo al cliente de Postgres dentro del contenedor

docker exec -it vs docker run -it

docker run -it <imagen> bash    →  crea un contenedor NUEVO y entra
docker exec -it <contenedor> bash →  entra a un contenedor que YA está corriendo

Confundir los dos es común al empezar: si el contenedor de la base de datos ya está corriendo (por ejemplo, vía Compose) y se quiere entrar a inspeccionarlo, es exec, no run — run crearía un contenedor Postgres nuevo y vacío, separado del que ya tiene los datos.

Cuando bash no está disponible

Algunas imágenes minimalistas (Alpine) no traen bash, solo sh:

docker exec -it mi-contenedor sh

Combinación típica de debug

docker ps                    # ver qué está corriendo y su nombre/id
docker logs -f mi-app        # ver si tira errores
docker exec -it mi-app sh    # entrar a inspeccionar archivos, variables de entorno, etc.

Consideraciones

• docker exec no funciona en un contenedor detenido — hace falta que esté Running (ver Ciclo de vida).
• Cualquier cambio hecho a mano dentro de una sesión exec (instalar algo o editar un archivo) se pierde si el contenedor se elimina y no se refleja en la imagen. Los cambios permanentes deben declararse en el Dockerfile.