Así está construido Albgott de verdad.
No es un diagrama de arquitectura pulido — es el hardware, la red y los servicios reales, con tres años de crecimiento ad-hoc incluidos. Donde es desigual, aquí se queda desigual.
Conectarse a internet
Internet entra a través de hardware que no controlo del todo. El propio router del ISP termina el handoff de WAN y, por contrato, no se puede quitar de la cadena — así que hay, un poco absurdamente, dos routers apilados uno encima del otro antes de que el tráfico llegue a nada que gestione yo de verdad: primero la caja del ISP, luego la mía.
La mía es un MikroTik hEX S — un router/firewall sin radio Wi-Fi en absoluto, elegido deliberadamente como appliance de enrutado y nada más. Hay una pequeña historia honesta detrás de por qué no tiene Wi-Fi: no fue del todo un plan. Lo pedí sin comprobar que venía sin Wi-Fi, se me pasó el plazo de devolución, y solo después me di cuenta de que el accidente en realidad había reforzado algo que merecía la pena mantener de todos modos — enrutar y hacer de firewall no debería ser también un punto de acceso Wi-Fi. Así que el Wi-Fi de casa lo sirve un router más viejo y separado de un ISP anterior, que se mantiene solo para ser el puente Wi-Fi hacia la red. Tres cajas haciendo el trabajo que en un datacenter sería una sola pieza de hardware, cada una ahí por un motivo ligeramente distinto — contractual, deliberado y accidental.
Desde el MikroTik, un switch gestionado se abre en abanico por puertos trunk hacia cada máquina de la red — cinco en total, cada una llevando las VLANs que necesita. Qué son esas máquinas, y por qué su hardware no se parece nada entre sí, es la siguiente sección.
Las máquinas
Nada de esto se especificó de antemano, y nada se compró para el papel que acabó jugando. El cluster creció por completo a partir de hardware que ya andaba por ahí — un portátil reconvertido, un desktop de oficina dado de baja, una torre con más margen que las otras dos juntas — y los roles se asignaron a lo que ya existía, no al revés. Ese historial se ve en las specs de abajo, y prefiero mostrarlo antes que maquillarlo.
Tres nodos de Proxmox llevan casi todo:
| Nodo | Hardware | RAM / Disco | Qué lleva |
|---|---|---|---|
| pve01 | Portátil reconvertido (Asus GL502VS) | 32 GB · 500 GB SSD + 1 TB HDD | Ingress y herramientas de desarrollo del día a día |
| pve02 | Desktop de oficina dado de baja (Dell OptiPlex 7050) | 16 GB · 256 GB | Stack de observability |
| pve03 | Torre Dell T160 | 64 GB · 8 TB disco único | Data y los servicios críticos de cara al público |
El dimensionamiento no es simétrico, y eso es a propósito aunque el propio hardware no se eligiera a propósito: pve02 corre métricas y dashboards, que consume mucho I/O pero poca RAM, así que se llevó la máquina más pequeña. pve03 guarda el estado real — bases de datos, object storage, tráfico público — así que se llevó, con diferencia, la mayor RAM y el mayor disco de los tres. El portátil sigue la misma lógica desde el otro extremo: nada que necesite rendimiento real o guarde algo que importe corre en pve01, precisamente porque el T160 existe para eso — y porque un portátil no es hardware en el que nadie debería confiar nada importante: sin memoria ECC, sin alimentación redundante, una batería y unas bisagras que nunca se construyeron para correr 24/7, y una refrigeración pensada para un escritorio, no para un rack.
Los nombres de las máquinas siguen discretamente la mitología nórdica (odin, brokkr, eitri, thor) — un poco de personalidad que no cuesta nada mantener — pero los nombres que se usan de verdad en el día a día, en configs, monitoring y conversación, son los aburridos y operativos (pve01, pve02, pve03, dns01). Eso es deliberado: un nombre tiene que decirse rápido y entenderse al instante por cualquiera de dentro, y «pve03» consigue eso de una forma que «thor» nunca conseguirá.
La gestión out-of-band también es desigual: solo pve03 tiene una consola de hardware real accesible independientemente de su sistema operativo. Las otras dos no — si alguna se queda colgada lo bastante mal, la solución implica acercarse y pulsar un botón, no entrar en remoto. El comportamiento de encendido entre las tres es igual de inconsistente, por el mismo motivo por el que todo lo demás aquí es inconsistente: tres máquinas con tres historiales distintos, no una sola decisión de compra.
La más pequeña de estas tres ni siquiera es un nodo de Proxmox — una Raspberry Pi 3B+ está junto al cluster ejecutando el DNS primario de toda la red, un buen encaje para algo que necesita estar encendido todo el tiempo y apenas consume energía mientras lo hace. Eso es lo siguiente.
Cómo resuelven los nombres
DNS corre como un par primario/secundario — el primario es esa Raspberry Pi de la sección anterior, el secundario vive como VM en el nodo más grande. Cada registro de los dominios que realmente poseo es autoritativo aquí primero; todo lo demás se recursa externamente en lugar de confiarse a cualquier resolver público que esté configurado — una separación pequeña y deliberada: responder localmente lo que es mío, preguntarle a internet solo por lo que no lo es.
Los dos servidores DNS se mantienen sincronizados de la forma estándar en que debería hacerlo un par primario/secundario — notificaciones de transferencia de zona, autenticadas para que una transferencia maliciosa no pueda inyectar registros, sobre el mismo protocolo que usan los clientes para consultar. Las ediciones solo pasan nunca en el primario; el secundario existe únicamente para que la resolución siga funcionando si la Pi llega a caerse, no como un segundo sitio donde hacer cambios. Es una pieza de infraestructura pequeña y de libro de texto, y merece la pena incluirla exactamente por eso — no todo aquí necesita ser exótico para merecer la pena explicarlo bien.
Cómo se reparte la red
La red está dividida en ocho segmentos, cada uno un límite de confianza aplicado en el router de borde y no solo una convención de nombres — a qué puede llegar una máquina depende por completo de en qué segmento está.
Direccionamiento ilustrativo a continuación — no son los rangos reales.
| Segmento | Propósito |
|---|---|
| Home | Dispositivos personales — fuera del espacio de direcciones propio de la infraestructura |
| Internal | El plano de aplicación de confianza — la mayoría de servicios viven aquí |
| Data | Storage y servicios stateful, deliberadamente difíciles de alcanzar directamente |
| Corp | Dispositivos de trabajo |
| CI | Workers de build y automatización, solo acceso de salida |
| Public | De cara a internet — alcanzable solo a través de un gateway |
| Backup | Reservado para un sistema de backup que todavía no existe |
| Mgmt | DNS, consolas de hipervisor, el control plane solo para admins |
Lo interesante no es la lista, es el razonamiento detrás de ella:
- Data está aislado a propósito. Nada llega directamente a una base de datos o al object store — solo a través de rutas explícitas y nombradas para los servicios que las necesitan.
- Public se comporta como una DMZ clásica, no como una puerta abierta. Es alcanzable desde internet, pero solo puede reenviar a una lista corta y explícita de backends — nunca es un camino general hacia la red interna de confianza, ni siquiera para cosas que corren en la misma máquina física.
- CI puede salir, pero nada confía en que pueda entrar. Los build workers necesitan acceso de salida para descargar dependencias y subir imágenes; ese es un permiso completamente distinto a que se confíe en ellos para administrar nada.
Dos redes VPN separadas conviven junto a estos segmentos para el acceso remoto — una para administración, otra para acceso de desarrollo — pero son overlays enrutados, no VLANs a las que un peer se una nunca directamente, y el modelo de acceso detrás de ellas pertenece a /security, no aquí.
Cómo entra el tráfico
Tres reverse proxies separados gestionan el ingress, cada uno acotado a un nivel de confianza distinto en lugar de un solo proxy haciéndolo todo. Esta es probablemente la única decisión de esta página con más «por qué» detrás, así que merece la pena explicarla bien en lugar de simplemente listar los tres.
| Nivel | Alcanzable desde | Qué vive ahí |
|---|---|---|
| Public | The open internet (allow-listed backends only) | El único entrypoint alcanzable desde la internet abierta. Reenvía a una allow-list corta y explícita de backends y nada más. |
| Internal | Trusted networks only | Para herramientas pensadas para alcanzarse solo desde redes de confianza: dashboards, UIs de monitoring, utilidades de desarrollo del día a día. Este es, con diferencia, el más transitado de los tres — la mayoría de cosas que la gente usa a diario de verdad viven detrás de él. |
| Management | The administration VPN only | El control plane de la infraestructura. Consolas de hipervisor, administración de DNS, equipos de red, acceso a nivel de hardware. Alcanzable solo a través de la VPN de administración, nunca desde ningún otro sitio. |
El razonamiento, dicho tan claro como puedo:
Comprometer una app detrás del proxy interno nunca debería darle a nadie un camino hasta una consola de hipervisor o el panel de admin de un switch.
Esa es toda la justificación de que el proxy de management sea su propia instancia, en su propio segmento de red, cerrado detrás de su propia VPN — no es una comodidad, es un límite de contención. La regla general que uso de verdad al añadir algo nuevo: si puede reiniciar una máquina, tocar la configuración de red, o llegar directamente al hardware, va detrás de management. Todo lo demás es una cuestión de audiencia — equipo interno, o la internet pública. La misma lógica de contención aparece otra vez en /security, aplicada a personas en lugar de a proxies: es todo el motivo por el que el acceso remoto está dividido en dos VPNs separadas en lugar de una sola con niveles de permisos.
Dos casos límite que merece la pena señalar, porque son el tipo de detalle que de verdad explica el razonamiento en lugar de solo repetir la regla:
- Un par de herramientas internas son alcanzables intencionadamente a través de dos de estos proxies a la vez — el mismo backend, alcanzado de forma distinta según si quien llama es una integración externa (un webhook, por ejemplo) o alguien del equipo en la red de confianza. Esa duplicación es deliberada, no una inconsistencia que se quedó por ahí.
- El servicio de object storage técnicamente vive en el segmento data aislado, pero se alcanza desde fuera de ese segmento a través del proxy interno en lugar de una excepción de firewall directa tallada solo para él. La ruta del proxy es la única forma de entrada autorizada — no es un atajo alrededor del aislamiento, es el aislamiento funcionando como se pretendía.
Dónde vive el estado
Todo lo que tiene estado real — bases de datos, object storage — está confinado al segmento data descrito antes, y el acceso hacia él es deliberadamente estrecho: solo los hosts, proxies y comprobaciones de monitoring específicos que necesitan una ruta de entrada la tienen, nada más amplio.
Ahí viven dos piezas: RustFS, un object store compatible con S3, y dos instancias de PostgreSQL separadas — producción y desarrollo mantenidos totalmente aparte en lugar de compartir un servidor con bases de datos distintas encima. RustFS sustituyó a MinIO tras un cambio de licencia y una UI de la edición community que empeoró notablemente; de las alternativas que miré, RustFS tenía la mejor UI y es compatible con S3 de la misma forma que lo era MinIO, así que nada de lo construido encima tuvo que cambiar. El acceso directo a la base de datos es la excepción, no la norma; la mayoría de cosas que necesitan datos pasan por una capa de aplicación delante, y el puñado de cosas que se conectan directamente (monitoring, un par de hosts de confianza) son excepciones nombradas, no una puerta abierta.
Qué corre de verdad
Más de treinta servicios corren encima de todo esto, y el número en sí no es lo interesante — lo interesante es por qué está ahí cada uno. El par de DNS, el router de borde y el switch, y los tres reverse proxies ya se han cubierto arriba; lo de abajo es todo lo demás, agrupado por para qué sirve en lugar de volcado en una única tabla larga de referencia.
El proveedor de identidad — el SSO se va desplegando servicio a servicio, todavía no en todas partes.
Un segundo servicio de identidad con soporte OIDC que mantengo para los proyectos a los que encaja mejor.
Donde viven de verdad los secrets ahora, en lugar de estar en archivos de config en texto plano.
Almacenamiento de métricas y las reglas de alerta que deciden cuándo algo va mal de verdad.
Almacenamiento de logs, consultado de la misma forma que las métricas de al lado.
Enruta cada alerta directa a un teléfono, para enterarme antes que un cliente.
Los dashboards que de verdad miro cada día.
Comprobaciones activas sobre todo lo que da la cara al público, independientes del pipeline de métricas.
Automatización de workflows para esos pequeños trabajos de pegamento que no merecen su propio servicio.
Una caja de herramientas de pequeñas utilidades de desarrollo que si no tendría que buscar online, una por uso.
Se encarga de fusionar/dividir/convertir PDFs, para lo que antes recurría a alguna web random.
Una UI sobre los hosts Docker, para cuando no quiero entrar por SSH solo para mirar un container.
Mi propia nube de archivos — sustituyó la dependencia de Google Drive de la que partió toda esta plataforma.
La librería de fotos que uso de verdad día a día, no una alquilada.
Un proyecto personal mío de seguimiento de libros — pequeño, pero es mío de principio a fin.
Un detalle más que merece mención: internamente, todo esto también está unido a través de un único dashboard — una landing page al estilo «homepage», self-hosted, que agrupa cada enlace interno en un solo sitio. No es algo que la página pública necesite exponer directamente, pero es un buen aparte sobre cómo funciona de verdad la experiencia del día a día de llevar esto.
Desde aquí: /security cubre cómo se controla de verdad el acceso a todo esto, y /operations cubre cómo se mantiene funcionando día a día. Nada de esto está terminado — /roadmap es el backlog, en orden, de lo que sigue abierto. Y en cuanto algo aquí cambia, /log es donde deja de ser estado actual y se convierte en historia.