Un Sandbox para Demos que Desechas

Cada demo que necesito mostrarle a alguien vive en una sola máquina, y nada de eso está permitido cerca de los hosts que importan. Esa caja corre una pequeña plataforma como servicio junto con un proxy inverso, y cada demo es un proyecto compose con su propio hostname, su propia base de datos cuando la necesita, y su propio ciclo de vida.

El diseño es deliberadamente aburrido: el código fuente de la aplicación en un árbol, los archivos compose en otro. Un demo es un directorio. Borrar un demo es borrar un directorio. Esa reversibilidad es todo el punto de tener un sandbox en lugar de "una carpeta de repuesto en el buen servidor."

Tres cosas que vale la pena robar

Un canario corriendo permanentemente. Hay un servicio trivial de hello-world en el mismo proxy y la misma red que cada demo. Cuando un demo deja de responder, la primera pregunta es si el demo se rompió o si la ruta se rompió, y el canario responde eso en una sola petición. No cuesta nada y me ha salvado de depurar una aplicación que estaba bien al menos dos veces.

Observabilidad adjunta por defecto, no por proyecto. Métricas de contenedores, un log shipper y un agente ligero corren en la caja misma, así que un demo hereda monitoreo por existencia. Cualquier cosa que tengas que recordar agregar a cada proyecto nuevo eventualmente faltará en el proyecto que más la necesitabas.

Los demos son lo suficientemente stateful para ser honestos. Cada uno tiene una base de datos real y una cola real donde el diseño lo pide, en lugar de un backend simulado. Un demo que no puede fallar como falla la cosa real es una diapositiva, no un demo.

El bug: cuatro servicios corriendo reportados como faltantes

Mi homelab mantiene un grafo de relaciones, construido por colectores que observan lo que realmente está corriendo. Reportó cuatro de estos demos como documentados pero no observados — la bandera que levanta para un servicio que existe en papel y ha desaparecido en la realidad.

Los cuatro estaban corriendo. Verifiqué.

La causa es un problema de nombres con tres ejes:

• mi inventario nombra el servicio lógico
• el colector observa el nombre del contenedor
• el monitoreo de uptime usa un nombre para mostrar

Nada reconciliaba los tres, así que un servicio cuyo nombre de contenedor difería del nombre en el inventario parecía, para el grafo, un servicio que nadie había visto jamás. La solución fue un mapa de alias, más una decisión deliberada de no fusionar sidecars — los contenedores de base de datos y worker se mantienen distintos en lugar de ser absorbidos por el servicio que soportan, porque colapsarlos ocultaría un worker muerto detrás de un contenedor web saludable.

La parte que no arreglé

El mapa de alias es plano: nombre de servicio a nombres de contenedor, sin noción de qué host. Y dos de mis máquinas corren contenedores con nombres idénticos — el demo sandbox y el stack real de GPU detrás de él.

Hoy eso está inerte, porque solo uno de esos hosts tiene un colector de contenedores. Si el otro alguna vez gana uno, el alias absorbería silenciosamente el stack de producción dentro de la identidad del demo.

Lo anoté en el commit en lugar de arreglarlo. No porque fuera muy difícil — los alias con alcance por host son la respuesta obvia — sino porque un problema latente que está registrado es un riesgo conocido con un disparador declarado, mientras que un problema latente que se arregla bajo presión sin prueba es solo un bug diferente que aún no conoces. El disparador está anotado. Cuando ese host tenga un colector, la nota estará esperando.

"No observado" es una afirmación sobre el observador. Me tomó cuatro servicios saludables reportados como faltantes para internalizar eso.