6.2Problemas recurrentes (playbook)
Lo esencial en 30 segundos
- Diagnosticar : un síntoma = unas causas probables = una secuencia de acciones — no se corrige al azar.
- Raíces : variables, puertos, volúmenes, rebuild olvidado, healthcheck, permisos, caché, login — 90 % de los bloqueos.
- Verificar : ps, logs, config y prueba en volumen real, no solo en un run aislado.
Hilo Idir — la tabla pegada junto a la pantalla
Idir guarda esta tabla junto a su pantalla en Argel. Veredicto tras un trimestre : tres líneas le sirvieron más — el contenedor en Restarting, el puerto ya asignado, y los datos perdidos tras rm. Para cada una, terminó aplicando la secuencia (síntoma, causas, acciones) en lugar de relanzar al azar.
Síntoma observado, causas verificadas, acciones en orden : el reflejo cabe en tres tiempos.
Un reflejo por síntoma
La mayoría de los bloqueos Docker son grandes clásicos. Relacionar cada síntoma con sus causas probables y una secuencia de acciones ahorra un tiempo precioso.
| Síntoma | Causas probables | Acciones |
|---|---|---|
| Contenedor en Restarting | variable -e faltante, volumen en ruta incorrecta, puerto ocupado | compose ps, logs del servicio, corregir el archivo, up -d |
| port already allocated | okupa (run viejo), dos stacks con mismo puerto de host | docker ps global, cambiar el puerto de host (izquierda) |
| Datos perdidos tras rm | ningún volumen, montaje en ruta incorrecta | añadir un volumen nombrado, probar con rm + relanzamiento |
| up ignora el código nuevo | imagen no reconstruida | up -d --build (o bind en dev) |
| Base «no lista» al arrancar | depends_on sin condición, sin retry | healthcheck + condición healthy + retry en la aplicación |
| Permission denied en volumen | montaje root, USER non-root sin chown | chown en el build / alinear UID, no volver a root |
| Imagen enorme / build lento | COPY . . primero, sin .dockerignore | dependencias primero + .dockerignore + multi-stage |
| Push denied | sin login, nombre sin namespace, sin permisos | login, nombre cuenta/imagen, permisos |
| down lo borró todo | down -v sobre datos deseados | down sin -v por defecto ; copias + restauración probada |
Guion listo para decir — diagnosticar sin relanzar al azar (30 s)
«Mi síntoma : [Restarting / puerto asignado / datos perdidos / base no lista]. Verifico la causa probable de la tabla (ps, logs, config, rutas), aplico la acción dirigida y pruebo (relanzamiento, down/up, restauración).»
Modelo copiar-pegar — diagnóstico Docker
docker compose ps
docker compose logs -f api
docker ps -a
docker compose config
docker compose up -d --buildTPE / presupuesto ajustado
Sin tabla formal : un síntoma, la causa probable, la acción y quién prueba, anotados.
PYME Argel
Integrar las realidades locales al diagnóstico : máquina real, puertos ya ocupados, referente conocido.
Remoto / híbrido
Añadir trazas escritas a las acciones : a distancia, un log y una prueba down/up consignados evitan duplicados.
Intercultural
Explicitar las constataciones por escrito : lo que parece evidente (qué servicio, qué puerto) no lo es para todos.
Reto 48h — aplica mañana
Detecta 1 síntoma actual (Restarting, puerto, datos, base no lista), aplica la línea de la tabla (síntoma nombrado + causa verificada + acción dirigida) y prueba.
- Sé relacionar un síntoma con sus causas probables.
- Verifico ps, logs y config antes de corregir.
- Pruebo cada corrección (relanzamiento, down/up, restauración).
El contenedor de Idir entra en bucle en Restarting. ¿Qué reflejo aplica la tabla?
Reflejo : diagnosticar el síntoma, identificar la causa, aplicar la acción dirigida — no relanzar al azar.