1.5Observar y depurar: logs, exec, inspect
Lo esencial en 30 segundos
- logs: escuchar al enfermo : docker logs bdd lee el registro, -f lo sigue en directo, --tail 50 solo toma el final — un contenedor en bucle siempre cuenta su causa.
- exec: entrar para verificar : docker exec -it web sh abre un shell en lo vivo (archivo, ping, env) — diagnóstico, nunca instalación durable.
- ps → logs → exec/inspect : docker ps -a da el estado y el código de salida, inspect revela todo (variables, montajes, redes) — sin adivinar.
Minicaso conductor — Idir hace la autopsia de una web muda
El día de la demo, la web de Idir deja de responder. En lugar de recrearlo todo a ciegas, aplica el método: docker ps -a muestra un Exited (1), docker logs web acusa un puerto ya usado, docker inspect web confirma el conflicto de publicación. Libera el puerto, relanza — la página vuelve. Cinco minutos, cero adivinanza: su responsable retiene sobre todo que Idir nombró la causa antes de corregir.
Fin del caso 1.1-1.4 — Idir cierra el nivel: diagnosticar antes de corregir.
1. logs: escuchar al enfermo
docker logs bdd lee el registro, -f lo sigue en directo, --tail 50 solo toma el final. Un contenedor que reinicia en bucle siempre cuenta su causa en sus logs (contraseña ausente, puerto ocupado, volumen en ruta equivocada).
En los servicios charlatanes, se limita con --tail: leer el final, no kilómetros. Si logs está vacío, la app quizá registre en otro lado (archivo interno: entrar con exec) o muere antes de escribir (inspect + config).
2. exec: entrar para verificar
docker exec -it web sh abre un shell en lo vivo: verificar un archivo, probar una conexión (ping bdd), leer una variable (env). Para un one-shot sin shell: docker exec web ls /usr/share/nginx/html. No se instala nada durable así: es diagnóstico.
Modificar a mano en el contenedor se pierde en el siguiente run: exec constata, no repara duraderamente.
3. inspect y ps: el estado civil
docker ps -a da el estado (Up, Exited, Restarting) y el código de salida. docker inspect revela todo: comando, variables, montajes, redes, puertos. Método: ps → logs → exec/inspect, en este orden, sin adivinar.
Y se anota la causa real, no el síntoma: « puerto ya usado » en lugar de « no funciona ».
El recreador en bucle (no haga nunca esto)
Moraleja: recrear sin leer es perder siete veces contra la misma línea de log.
🔎 Ejemplo concreto — 🔎 Ejemplo concreto — Una web que no responde
La autopsia de la web muda de Idir, paso a paso.
docker ps -a # Exited (1) ? Restarting ?
docker logs web # ex. : port déjà utilisé
docker inspect web # vérifier ports et réseaux
docker exec -it web sh # fouiller de l'intérieurLectura: el estado orienta, los logs acusan, la inspección confirma.
Lección: el 90 % de las averías se resuelve sin recrear a ciegas.
Vocabulario de la sección
- logs
- El registro captado por el daemon; se lee con -f (directo) y --tail (final).
Ejemplo sencillo: docker logs web --tail 30 revela el puerto ocupado en casa de Idir.
Lo que no es: un archivo modificable a mano.
Reflejo: leer siempre antes de recrear.
- exec
- Ejecutar un comando en un contenedor vivo (shell -it o one-shot).
Ejemplo sencillo: docker exec -it web sh para registrar la web viva.
Lo que no es: la creación de un nuevo contenedor (run).
Reflejo: exec = vivo; detenido = inspect o run --rm.
- inspect
- El expediente completo JSON de un contenedor, imagen o red (variables, montajes, puertos).
Ejemplo sencillo: docker inspect web confirma el conflicto de puertos.
Lo que no es: una adivinanza sobre la configuración.
Reflejo: la config real, no la que se cree.
- Código de salida
- El 0 (OK) o no cero (error) dejado por el proceso, visible en ps -a.
Ejemplo sencillo: Exited (1) orienta a Idir hacia los logs.
Lo que no es: un número de puerto.
Reflejo: no cero = leer los logs enseguida.
En la práctica — En práctica — Autopsia guiada
- Lance voluntariamente un contenedor mal configurado (mala -e).
- Anote su estado exacto con ps -a.
- Lea sus 30 últimas líneas de logs y nombre la causa.
- Confirme con inspect (variables, montajes), luego corrija.
Script listo para decir — hacer autopsia en 5 minutos (30 s)
« Mi contenedor está en Exited (1): leo sus treinta últimas líneas de logs, nombro la causa — puerto ya usado. Confirmo con inspect: puertos y redes. Corrijo la causa, no el síntoma, y la anoto. »
Para decir encadenando ps, logs --tail e inspect; mostrar la causa nombrada antes de la corrección.
Modelo copiar-pegar — lista de autopsia
docker ps -a # 1. ÉTAT : Up ? Exited (code) ? Restarting ?
docker logs NOM --tail 50 # 2. CAUSE : lire la fin, nommer (port, -e, volume)
docker inspect NOM # 3. PREUVE : variables, montages, réseaux, ports
docker exec -it NOM sh # 4. si VIVANT : fouiller (fichier, ping, env)
# 5. CORRIGER la cause, NOTER (pas le symptôme). Jamais recréer à l'aveugle.Web muda de Idir
Como arriba: Exited (1) → logs → puerto ocupado → inspect → liberación → relanzamiento. Cinco minutos, cero adivinanza.
Base en Restarting
Bucle de reinicio: los logs contienen la causa (a menudo -e ausente o ruta de volumen equivocada) — se lee antes de actuar.
Logs vacíos
App que registra en un archivo interno: entrar con exec para leerlo, o inspect + config si el contenedor muere antes de escribir.
One-shot sin shell
docker exec web ls /usr/share/nginx/html: verificar un contenido sin abrir shell — rápido y sin riesgo.
✓ Buenas prácticas
- Leer siempre los logs antes de recrear.
- Limitar con --tail en los servicios charlatanes.
- Anotar la causa real (no el síntoma).
✗ Errores frecuentes
- Recrear en bucle sin leer (mismo error).
- Modificar a mano en el contenedor (perdido en el siguiente run).
- Confundir exec (vivo) y run (nuevo).
Puntos clave
- ps da el estado, logs la causa.
- exec entra, inspect lo revela todo.
- El orden ps → logs → exec/inspect no cambia.
- Se corrige la causa, no el síntoma.
Desafío 48h — aplique mañana
Sabotee voluntariamente un contenedor (mala -e), anote su estado ps -a, lea 30 líneas de logs, nombre la causa, confirme con inspect — luego corrija y anote.
- Anoto el estado exacto (ps -a) antes de toda hipótesis.
- Leo los logs para nombrar la causa.
- Confirmo con inspect/exec y corrijo la causa.
Preguntas frecuentes
¿logs está vacío, qué hacer?
O la app registra en otro lado (archivo interno: entre con exec), o el contenedor muere antes de escribir (inspect + config). Verifique también el controlador de logs.
¿exec rechaza: « container not running »?
Normal: exec exige un contenedor vivo. Arránquelo, o use run --rm para una inspección desechable de la imagen.
Un contenedor está en « Restarting ». ¿Primer reflejo?