Hay algo emocionante en resolver misterios técnicos; para muchos de nosotros, resolver estos enigmas digitales es igual de frustrante que gratificante. Recientemente, me encontré con uno de estos desafíos: un servidor de CapRover que dejó de mostrar su dashboard, lanzando un misterioso error ERR_HTTP2_PROTOCOL_ERROR. Lo que siguió fue una inmersión profunda en los servicios de Docker, registros de logs, y una eventual confrontación con un culpable que suele pasarse por alto: el espacio en disco.
Aquí te comparto la historia de cómo diagnosticamos, probamos y finalmente solucionamos el problema. Si eres usuario de CapRover o simplemente te gustan las buenas historias de solución de problemas, sigue leyendo para conocer toda la historia.
Los Primeros Síntomas
Nuestra historia comienza cuando el dashboard de CapRover dejó de responder repentinamente. En lugar de la interfaz familiar, solo se mostraba una pantalla en blanco. En los registros de la consola aparecía el mensaje ERR_HTTP2_PROTOCOL_ERROR, lo cual parecía inusual. En los registros de Docker de CapRover, el servicio captain-certbot parecía tener problemas, atrapado en un bucle de intentos para obtener el ID del contenedor.
Certbot, la parte de CapRover encargada de los certificados SSL, no podía ejecutarse correctamente. Aunque los problemas de Certbot no son desconocidos, este caso era extraño porque el problema no solo era de SSL; el dashboard entero se negaba a cargar. Este indicio nos llevó a pensar que podría haber un problema subyacente más amplio.
Los Primeros Pasos: Una Serie de Experimentos
Cuando se trata de solucionar problemas en CapRover, reiniciar los servicios suele ser un buen primer paso. Reiniciar los servicios captain-captain y captain-certbot podría ayudar a eliminar errores temporales. Esto es lo que probamos primero:
-
Reinicio de Servicios: Utilizamos comandos para actualizar y reiniciar los contenedores
captain-captainycaptain-certbot, con la esperanza de que regresaran a su funcionamiento normal. -
Intentos Directos de Renovación de SSL: Cuando los servicios de CapRover no respondieron, intentamos acceder a
captain-certbotdirectamente para renovar el certificado SSL concertbot renew --force-renewal. Desafortunadamente, este comando devolvió un error inesperado, lo que indicaba problemas con el propio Certbot. -
Eliminar y Recrear Contenedores: Incluso eliminamos instancias adicionales del contenedor
captain-certbot, sospechando que los contenedores redundantes podrían estar generando conflictos.
Pero cada intento nos llevaba de nuevo al punto de partida y nada parecía restaurar el dashboard de CapRover. En este punto, recurrimos a un último posible problema: el espacio en disco.
El Momento Eureka: Problemas de Espacio en Disco
Finalmente, decidimos verificar el uso del disco del servidor utilizando df -h. La salida reveló el verdadero problema en números alarmantes:
Filesystem Size Used Avail Use% Mounted on
/dev/vda2 23G 23G 0 100% /
¡El sistema de archivos raíz de nuestro servidor estaba completamente lleno! Esto explicaba por qué Certbot y NGINX fallaban: simplemente no había espacio disponible para que operaran.
La Solución: Liberando Espacio en Disco
Con la causa raíz identificada, ahora nos enfocamos en liberar suficiente espacio para que CapRover volviera a funcionar. Esto fue lo que hicimos:
- Limpiar el Sistema de Docker: Primero, eliminamos los recursos no utilizados de Docker:
docker system prune -a --volumes
Esto eliminó imágenes, contenedores, redes y volúmenes no utilizados, lo que liberó espacio, pero no lo suficiente como para resolver el problema completamente.
- Limpieza de Logs: Los logs pueden consumir mucho espacio, así que recurrimos a los logs del sistema:
sudo journalctl --vacuum-size=100M
sudo find /var/log -type f -name "*.log" -exec truncate -s 0 {} \;
También truncamos los registros de contenedores de Docker, estableciéndolos en 0 bytes sin eliminarlos, liberando valiosos megabytes.
- Limpieza de Caché de Paquetes: Luego, limpiamos las cachés de paquetes del sistema, que pueden crecer mucho con el tiempo:
sudo apt-get clean
- Eliminación de Archivos Temporales Antiguos: Finalmente, eliminamos archivos temporales y paquetes no utilizados:
sudo rm -rf /tmp/*
sudo rm -rf /var/tmp/*
sudo apt-get autoremove -y
Después de esta meticulosa limpieza, liberamos más de 14 GB en el servidor, reduciendo el uso al 39%.
El Resultado: Un Servidor CapRover Saludable
Con el problema de espacio en disco resuelto, reiniciamos el servicio captain-captain para asegurar que CapRover pudiera utilizar el espacio recién liberado. Esta vez, el dashboard cargó sin problemas. Certbot renovó los certificados SSL sin inconvenientes, y NGINX manejó las solicitudes como se esperaba.
Al final, el misterio estaba resuelto: el disco lleno había causado toda la serie de errores, desde los fallos en la renovación de SSL hasta los errores de protocolo HTTP. Al investigar cada posible causa y no pasar por alto el factor de espacio en disco, logramos restaurar el servidor por completo.
Lecciones de la Experiencia
- El Espacio en Disco es Importante: El espacio en disco es una causa de problemas que suele pasarse por alto, especialmente en servidores que ejecutan aplicaciones en contenedores. Un monitoreo regular puede evitar estos problemas antes de que comiencen.
- Solución de Problemas Paso a Paso: En lugar de hacer suposiciones, un enfoque sistemático ayuda a reducir rápidamente el problema.
- Los Logs son tus Aliados: Aunque los logs pueden parecer poco útiles a veces, pueden llevarte a la causa raíz mostrando lo que no está sucediendo (como la imposibilidad de Certbot de avanzar).
- Limpieza Regular de Docker: Los entornos de Docker se benefician de limpiezas periódicas, ya que los recursos no utilizados pueden acumularse con el tiempo.
Al final, lo que comenzó como un error misterioso se convirtió en una solución sencilla, aunque algo tediosa. Y aunque tomó tiempo llegar a la raíz del problema, la experiencia reforzó una de las lecciones más valiosas de la solución de problemas: nunca pases por alto lo básico.
Top comments (0)