Sora Project, enlairant-se de debò

A finals del 2024 vaig presentar Sora Project: Terraform per crear màquines, FluxCD per desplegar-ho tot dins de Kubernetes i una llista de 💣 pendents per a l'any següent. Funcionava, sí. Però cada peça requeria el seu propi ritual: llançar un Terraform a mà, apuntar-se la IP, crear-la a Pi-hole, afegir la màquina a Nagios, resar perquè Longhorn no es despertés de mal humor ...

El que tenia era un munt d'eines automatitzades unides per un humà. I l'humà va acabar fins al capdamunt.

Llavors van arribar els temps de la IA, i després d'experimentar fins a la sacietat, vaig pensar "potser és moment de crear el meu propi datacenter". I així va néixer la nova versió de Sora Project.

Les peces

Aquesta vegada el projecte es divideix en quatre, cadascun amb una única responsabilitat:

• Sora Conductor: un assistent de terminal que prepara el servidor orquestrador, la màquina de la qual depèn tota la resta.
• Sora Horizon: una web que gestiona tota la xarxa i desplega aplicacions a Proxmox a partir de plantilles.
• Infraestructura: les plantilles, Terraform i scripts que importa Horizon.
• FluxCD: tot el que s'executa dins de Kubernetes.

Sora Conductor

Tot comença per un servidor físic que s'encarrega del bàsic: DNS, DHCP, NTP, base de dades, Nagios, certificats ... El mateix que en el seu moment vaig documentar al Rasp Project, guia a guia, ordre a ordre.

Ara és un assistent. Respons un formulari, observes el log i passa al pas següent. Si alguna cosa explota (i explotarà), el tornes a llançar i continua on ho havia deixat. I si vols un altre servidor igual, li dones el fitxer de respostes i s'instal·la sol.

tip

Nagios es compila des del codi font. Conductor t'avisa abans de començar que pot trigar i fallar. És l'avís més sincer que he escrit mai 😃.

Sora Horizon

I aquí hi ha la peça que faltava. Horizon és el lloc on viu tot: les xarxes, les IPs, els noms DNS, els servidors, les carpetes compartides, els dispositius, les credencials i, sobretot, els stacks.

Un stack és una aplicació desplegada a partir d'una plantilla: tries la plantilla, omples el formulari i despleges. Horizon crea les màquines, executa els scripts per fases, publica els noms a Pi-hole, els checks a Nagios i els targets a Prometheus. I quan l'elimines, ho desfà tot.

Recordeu que Pi-hole no tenia API i que vaig perdre un any intentant piratejar-lo? Doncs la versió nova sí que en té, i Horizon la fa servir. Crear un nom a Horizon és el que fa que una VM rebi la seva IP per DHCP i resolgui per DNS. Sense tocar Pi-hole. Mai. 🥹

info

Un any després, l'espera va donar els seus fruits. A vegades la millor decisió és no fer res i seguir endavant.

Les plantilles

Abans, cada màquina era un únic Terraform que ho feia tot amb cloud-init. El problema: canviar alguna cosa de la seva configuració no arribava mai a la màquina, ja que cloud-init només s'executa en crear-la. L'única manera d'aplicar un canvi era destruir-la i tornar-la a crear. 🔥

Ara les aplicacions es despleguen per fases: la màquina primer (sempre el mateix servidor Ubuntu base), i després els scripts que la converteixen en el que ha de ser. Canviar un ajust és editar l'stack, i només es torna a executar la part afectada.

Les plantilles actuals despleguen PostgreSQL, la monitorització, Kubernetes i GitLab Runner.

Kubernetes sense estat

Després de la guerra amb Longhorn i CNPG, he pres una decisió radical: el clúster no té volums. Cap. Es rebutja qualsevol intent de crear-ne un.

• Les bases de dades viuen en un PostgreSQL extern, amb PgBouncer al davant i còpies de seguretat cada nit.
• La monitorització viu a la seva pròpia màquina: Prometheus, Loki, Tempo i Grafana. El clúster li envia les seves mètriques, logs i traces.
• Tota la resta és a Git.

Si el clúster mor, se'n desplega un de nou i FluxCD el torna a omplir. Sense restaurar res. Sense plorar. Bé, sense plorar gaire.

warning

Loki continua sent Loki. Però ara, quan s'enfada, s'enfada a la seva pròpia màquina i no s'emporta el clúster per davant 😌.

Els nodes tampoc no s'actualitzen: se substitueixen. Afegir un worker és afegir una línia al formulari d'Horizon; substituir el control plane és treure'n un i afegir-ne un altre al mateix desament. El nou s'uneix primer, l'antic se'n va després, i l'endpoint de l'API ni se n'assabenta.

FluxCD

FluxCD també ha passat pel quiròfan. Ara l'instal·la el Flux Operator, sense token i sense escriure al repositori: el clúster llegeix Git i Git ni sap que el clúster existeix.

L'organització per nivells es manté, però més neta: xarxa, ingress, observabilitat, identitat i aplicacions. I amb regles que aplica el mateix Kubernetes: sense volums, tot ingress amb la seva classe, pods sense privilegis i rollback automàtic si una actualització falla.

I allò de les actualitzacions que explotaven? Cada component s'actualitza sol dins d'un rang: els pegats arriben sols, les versions menors del que pot fer caure el clúster requereixen un commit. Slack avisa de tot.

I ara?

Ara toca fer-lo servir. La documentació completa és a Sora Project, amb una guia de desplegament des d'un Proxmox buit fins a les aplicacions.

La xarxa queda totalment funcional amb l'arquitectura bàsica. Prou bàsica com per ser el somni humit de moltes empreses o, pitjor, el que ni tan sols saben que existeix.

Per fi, a enlairar-se. ☁️