Adrian RomoAdrian Romo
Activo

Operaciones de Homelab

14 hosts, ~110 contenedores y la disciplina documental para mantenerlos legibles

Resumen

Contexto, enfoque y resultado.

Problema

Un homelab deja de ser un hobby en el momento en que tu casa depende de él. El mío cruzó esa línea: DNS, automatización del hogar, medios, almacenamiento de documentos y SSO relacionado con contraseñas, todo corre ahí. En ese punto, el modo de falla ya no es "un servicio está caído". Es "ya no recuerdo por qué esto está configurado así, y la persona que lo sabía era yo hace seis semanas".

Mi rol

Arquitecto y operador único. Cada host, cada archivo compose, cada registro de decisiones.

Restricciones

  • Operador único, solo en las noches y fines de semana. Cualquier cosa que requiera mi atención en un horario fijo eventualmente no la recibirá.
  • Dependientes reales. Las fallas de DNS y automatización del hogar son visibles en la casa en cuestión de minutos.
  • Sin escape a la nube para lo que realmente importa: el punto es que todo corra aquí.

Arquitectura

Un nodo Proxmox hospeda VMs Docker separadas por propósito: infraestructura compartida (reverse proxy, SSO, métricas, logs, uptime, notificaciones push), un backend operacional (Git autohospedado, runners de CI, un ledger de eventos append-only), aplicaciones de conocimiento y documentos para humanos, y un sandbox para experimentos y demos públicas. Un NAS almacena la persistencia y los respaldos, y también funciona como el segundo nodo DNS. Una estación de trabajo con GPU separada corre el stack local de modelos.

El ingreso es a través de un solo reverse proxy con forward-auth al frente de todo lo interno. DNS corre en alta disponibilidad en dos nodos con sincronización de políticas unidireccional desde una fuente de verdad designada, así que el réplica nunca puede desviarse y convertirse en una segunda opinión.

Todo está respaldado y priorizado en Git: inventario, archivos compose, runbooks y registros de decisiones viven en un solo repo, y la flota en ejecución se compara contra ese repo por colectores de solo lectura que no cambian nada y registran sus propios errores en vez de caerse.

Resultado

14 hosts y alrededor de 110 contenedores, documentados en 368 páginas markdown: 21 registros de decisiones de arquitectura, 131 runbooks — incluyendo un procedimiento de restauración para cada servicio con estado — y postmortems lo suficientemente honestos como para incluir los fixes que no funcionaron.

Qué haría diferente

Escribir los registros de decisiones desde el primer día en vez de reconstruirlos después. La parte costosa nunca fue la configuración; fue recuperar el razonamiento detrás de una configuración que ya había olvidado. Y comprar el UPS antes de que una pérdida de energía sucia te enseñe por las malas.

Aprendizajes

Lo que me llevo.

El homelab es donde pruebo patrones de operaciones antes de llevarlos al trabajo: bajo riesgo y alto ritmo de aprendizaje. El patrón que mejor se transfirió fue el de solo lectura primero: recolectores que observan y reportan, ganando confianza mucho antes de que se permita cambiar cualquier estado.

Stack

Herramientas y plataformas.

ProxmoxDockerTraefikAuthentikPrometheusGrafanaLokiPi-holeGiteaDebian

Textos relacionados

Notas de este proyecto.

Conversemos

¿Quieres platicar de este tipo de trabajo?

Si estás contratando para trabajo backend, AWS, voz o integraciones similares —o simplemente quieres comparar notas de arquitectura— escríbeme directo.