Docker: diagnostica un contenedor que no responde

1. Comprueba el motor antes de investigar la aplicación

docker --version comprueba el cliente, pero no demuestra que el motor esté disponible. docker version debe mostrar también Server. Si no puede conectar, inicia Docker y resuelve ese problema primero. No cambies permisos de archivos ni uses privilegios extra por ensayo.

docker --version
docker version
docker ps -a

Comprueba: La información incluye Client y Server. Si aparece un error del daemon, todavía no tiene sentido investigar el puerto de una aplicación que no puede arrancar.

2. Levanta una web local y comprueba el puerto correcto

Usa un nombre nuevo. Si ya existe labs-web-gratis, no lo borres: elige otro y sustituye el nombre en todas las órdenes. El enlace 127.0.0.1 limita el puerto publicado a tu propio equipo. La imagen se descarga de un registro externo. Su versión stable puede cambiar; esta práctica no es una configuración para producción.

docker run -d --name labs-web-gratis -p 127.0.0.1:18080:80 nginx:stable-alpine
docker ps --filter name=labs-web-gratis
docker port labs-web-gratis

Comprueba: El contenedor figura como activo y el puerto 80/tcp se publica en 127.0.0.1:18080. Abre http://127.0.0.1:18080 en el navegador: debe aparecer la bienvenida de nginx. El 80 es el puerto interno; el 18080 es el que usas desde el equipo.

3. Reproduce una caída y reúne evidencias

Detén únicamente el contenedor de esta práctica. Una página que ya estaba cargada puede seguir visible: recarga y comprueba el estado con Docker. ps sin -a no muestra contenedores parados. Los logs históricos no prueban que el proceso siga ejecutándose.

docker stop labs-web-gratis
docker ps --filter name=labs-web-gratis
docker ps -a --filter name=labs-web-gratis
docker logs --tail 20 labs-web-gratis
docker inspect --format '{{.State.Status}}' labs-web-gratis

Comprueba: ps no lo lista como activo; ps -a muestra Exited y inspect devuelve exited. Los logs pueden seguir incluyendo peticiones anteriores.

4. Recupera y verifica el servicio

start vuelve a ejecutar el mismo contenedor. Los datos de esta práctica no necesitan volúmenes, pero una base de datos real sí exigiría revisar persistencia y copias antes de reemplazar contenedores.

docker start labs-web-gratis
docker port labs-web-gratis
docker logs --tail 10 labs-web-gratis

Comprueba: Tras el arranque, recarga http://127.0.0.1:18080. Volver a ver la página y confirmar el estado activo son evidencias distintas que conviene reunir juntas.

5. Usa una checklist, no comandos al azar

Primero motor; después estado del contenedor; luego logs, publicación del puerto y respuesta de la aplicación. Si está activo pero no responde, confirma la URL y el mapeo antes de recrearlo. Un conflicto de puerto exige elegir otro puerto libre en un contenedor nuevo: start no cambia la publicación de uno existente.

docker inspect --format '{{.State.Status}}' labs-web-gratis
docker port labs-web-gratis
docker logs --tail 20 labs-web-gratis

Comprueba: Puedes explicar qué comprobación demuestra cada comando y por qué «está activo» no garantiza por sí solo una respuesta HTTP correcta.

Tu turno

Predice el estado de un contenedor que ejecuta una sola orden y termina. Usa un nombre que no exista. ¿Tiene sentido publicar un puerto para ese proceso?

docker run --name labs-proceso-gratis nginx:stable-alpine nginx -v
docker ps -a --filter name=labs-proceso-gratis
docker logs labs-proceso-gratis

Explícalo con tus palabras

• ¿Qué prueba Client y qué prueba Server en docker version?
• ¿Por qué los logs pueden existir con el contenedor parado?
• ¿Cuál de los dos puertos escribirías en el navegador?

Repite con datos distintos antes de marcarlo como practicado. Esta es una autoevaluación, no una certificación.

Si quieres continuar

En De Cero a Docker practicarás imágenes, redes, Compose, persistencia y recuperación de PostgreSQL. Este laboratorio no incluye bases de datos ni requiere comprar el curso.