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.