Debuguear aplicaciones contenerizadas implica inspeccionar logs, obtener una shell dentro de contenedores, examinar configuración y estado, y diagnosticar problemas comunes (crashes, networking, recursos). Saber cómo resolver problemas es una habilidad práctica esencial.
docker ps -a
docker logs <container>
docker logs -f -- 100 <container>
docker inspect <container>
docker events
docker logs es usualmente el primer paso — muestra la salida y errores de la aplicación. docker ps -a revela si un contenedor salió (y su código de salida).
# run an interactive shell inside a RUNNING container to investigate
docker exec -it <container> bash # or sh (alpine)
# → inspect files, run commands, check the environment, test connectivity from inside
# if the container won't STAY running, override the entrypoint to get a shell
docker run -it --entrypoint sh myimage
docker exec -it ... bash proporciona una shell dentro de un contenedor en ejecución — invaluable para inspeccionar archivos, revisar el entorno y probar conectividad desde la perspectiva del contenedor.
Container EXITS immediately → check `docker logs`; the main process crashed or finished
(a container stops when its main process exits) — check CMD/ENTRYPOINT, errors
CAN'T CONNECT between containers → check they're on the same network; use service NAMES
(not localhost); verify ports; `docker network inspect`
PORT not accessible → check -p mapping; the app must listen on 0.0.0.0 (not 127.0.0.1)
OUT OF MEMORY / killed → check `docker stats`, resource limits (OOMKilled in inspect)
PERMISSION errors → file ownership/user (non-root user vs mounted volume permissions)
IMAGE issues → rebuild without cache (--no-cache); check the build context/.dockerignore
Saber cómo debuguear y resolver problemas en contenedores Docker es una habilidad práctica esencial, porque las aplicaciones contenerizadas inevitablemente tienen problemas (crashes, problemas de conectividad, errores de configuración) que deben ser diagnosticados, y el entorno contenerizado añade una capa que requiere técnicas de debugging específicas.
Las habilidades fundamentales — inspeccionar logs (docker logs, usualmente el primer paso, mostrando la salida y errores de la aplicación), verificar estado (docker ps -a revelando si y por qué un contenedor salió, incluyendo códigos de salida), y examinar configuración/estado (docker inspect) — son cómo comienzas a diagnosticar la mayoría de problemas.
Obtener una shell dentro de un contenedor (docker exec -it ... bash) es una técnica invaluable para investigar desde la perspectiva del contenedor — inspeccionar archivos, revisar el entorno y probar conectividad — y saber cómo obtener una shell incluso cuando un contenedor no se mantiene en ejecución (anulando el entrypoint) maneja casos complicados.
Entender problemas comunes y su diagnóstico es particularmente valioso: contenedores que salen inmediatamente (el proceso principal crasheó o terminó — verificar logs y CMD/ENTRYPOINT), problemas de conectividad entre contenedores (membresía de red, usando nombres de servicio no localhost), puertos no accesibles (mapeo, y el error común de que la aplicación debe escuchar en 0.0.0.0 no en 127.0.0.1), kills por falta de memoria, y errores de permisos — estos son los problemas reales y recurrentes que saber cómo reconocer y solucionar ahorra tiempo significativo.
Como las aplicaciones contenerizadas tienen problemas que deben ser debugueados, y como la resolución de problemas efectiva (logs, exec dentro de contenedores, inspect, y reconocer patrones de fallo comunes) es necesaria para diagnosticar y resolverlos, saber cómo debuguear contenedores Docker es una habilidad práctica esencial, aplicada frecuentemente para cualquiera que ejecute aplicaciones contenerizadas, una competencia operativa fundamental que convierte problemas frustrantes de contenedores en problemas solucionables.