El panel del servidor de casa: de Homepage a Homarr 2

Todo lo que corre en casa (el hub, Vault, las copias de seguridad, el DNS) vive en una Raspberry Pi 5 con Kubernetes. Para saber de un vistazo si está bien hace falta un panel: cuánta CPU y memoria usa, cómo de caliente está, cuánto tráfico entra y sale, qué apps responden. Hasta hoy ese panel era Homepage. Lo hemos cambiado por Homarr 2, que salió hace dos días, y este artículo cuenta cómo está hecho y qué aprendimos por el camino.

Por qué cambiar

Homepage funcionaba, pero tenía un límite: se configura con ficheros de texto y cada tarjeta muestra unos pocos números en una fila. Homarr 2 trae tres cosas que encajaban justo con lo que queríamos:

Widgets propios. Se describe qué datos pedir a una API y cómo pintarlos, en un formato JSX restringido. Homarr hace las peticiones desde el servidor, con las credenciales guardadas cifradas, y el navegador nunca las ve.
Barras laterales fijas. Una columna que se queda quieta mientras el resto se desplaza. La queríamos para la música.
CSS propio para toda la instancia y para cada tablero.

Las métricas salen de Prometheus

El clúster ya tenía Prometheus recogiendo datos del sistema y de Kubernetes. El panel no instala nada nuevo para medir: le pregunta a Prometheus. Cada widget hace una sola consulta por refresco aunque muestre diez números. El truco está en unir las expresiones en una consulta y etiquetar cada resultado con un nombre (cpu, ram, temp…). El widget recibe una lista y la convierte en un objeto del que lee cada valor.

Importa porque Homarr limita las peticiones de cada widget a sesenta por minuto, y porque la Raspberry Pi no necesita que su panel la cargue. Con un refresco cada quince segundos, el widget del nodo hace cuatro peticiones por minuto.

Lo que muestra el tablero:

El nodo: CPU, memoria y temperatura en anillos, la carga, los días que lleva encendido y el estado del SAI.
La red: velocidad de entrada y salida, la gráfica de la última hora y el total del día.
Los discos: ocupación de la tarjeta y de los dos discos externos, y la velocidad de lectura y escritura.
El clúster: pods en marcha, despliegues caídos, reinicios, cuánta CPU y memoria está reservada, los namespaces con más pods y las alertas activas.
El DNS y el proxy de entrada: qué parte de las consultas se bloquea y si alguna ruta tiene errores.
Las apps, agrupadas por tema, cada una con un punto que dice si responde.

Ese punto de estado tiene su detalle. Si el panel comprobara cada app por su dirección pública, la petición saldría al router y volvería a entrar, y algunas apps solo aceptan visitas de la red de casa. Por eso el panel pregunta directamente al servicio interno de cada app. Las que tienen el tráfico interno cerrado a propósito se comprueban por fuera: no íbamos a abrir un agujero solo para pintar un punto verde.

La música, en la barra lateral

La columna de la derecha muestra lo que suena en YouTube Music en el ordenador de casa: carátula, canción, progreso, controles, la cola y un buscador para poner otra canción.

YouTube Music no ofrece una API para controlar la reproducción. Lo que sí existe es Pear Desktop, una aplicación de escritorio de código abierto para YouTube Music con un complemento que abre una API local. Entre esa API y el panel hay un servicio pequeño, unas trescientas líneas sin dependencias, que hace tres cosas:

Simplifica las respuestas. La búsqueda devuelve el JSON interno de YouTube, muy anidado. El servicio extrae título, artista, álbum, duración y carátula, y el widget recibe una lista limpia.
Junta pasos. «Reproducir ahora» son dos órdenes: poner la canción detrás de la actual y saltar a ella.
Falla bien. Si el ordenador está apagado o la aplicación cerrada, responde al instante con un mensaje claro en lugar de dejar el widget esperando.

La primera vez que el panel conecta, la aplicación del ordenador pregunta si se le da permiso. Los botones solo funcionan con la sesión iniciada en el panel, y el panel solo es accesible desde la red de casa o la VPN.

Una lección: probamos todo contra un simulador de la API y funcionaba. Al repasar el código de la aplicación real vimos que la cola devuelve un formato distinto del que el simulador imitaba. Con el ordenador de verdad, la sección «A continuación» habría salido vacía. Un simulador solo vale si copia el formato real, no el que uno supone.

El aspecto: el color solo mide

Queríamos un panel con aire futurista sin caer en el negro con neón. El planteamiento: tratarlo como una cámara térmica que mira el servidor. El fondo es berenjena oscuro y el color aparece únicamente para medir, con la escala de colores inferno de la visualización de datos: orquídea cuando algo va frío, ascua, ámbar y casi blanco cuando se acerca al límite. Una barra de CPU reservada en amarillo pálido dice «esto está lleno» sin necesidad de leer el número.

Solo hay un elemento llamativo: la carátula del disco, convertida a dos tonos (sombras violeta, luces ámbar) como si la viera la cámara. Al pasar el ratón recupera sus colores. Las cifras van en Tektur, una tipografía angular, y el texto en Instrument Sans.

Homarr 2 escala el tablero entero según el ancho de la pantalla, pero el texto no encoge en la misma proporción. En un portátil, los widgets pensados para un monitor grande se desbordaban. La solución fue definir tres distribuciones: una para pantallas anchas, otra con menos columnas para portátiles y otra para el móvil.

Lo que destapó la revisión

Antes de cambiar de panel revisamos el antiguo, y dos de sus problemas resultaron ser problemas del servidor:

El SAI llevaba once días sin vigilancia. El controlador USB que habla con el SAI se había colgado y arrastró al servicio que reparte sus datos. El contenedor seguía «en marcha», así que nada se quejaba salvo una métrica que no llegaba. Lo grave: si se hubiera ido la luz, la Raspberry Pi no se habría apagado sola al agotarse la batería. Ahora hay una comprobación que pregunta al SAI cada minuto y reinicia el servicio si no contesta.
El panel bloqueaba su propio acceso a Grafana. Al panel antiguo le faltaba el secreto con la contraseña, así que en cada refresco enviaba en su lugar el texto de relleno de la plantilla. Grafana, tras tantos fallos seguidos, bloqueaba temporalmente al usuario. La contraseña guardada era la buena; simplemente nunca llegaba a enviarse.

Ninguno de los dos se veía mirando el panel. Ese es el argumento para revisar de vez en cuando lo que se da por hecho, sobre todo lo que vigila a lo demás.