Introducció

Abans de començar

Per embarcar-se en un projecte, primer cal entendre'l, així que sofà, crispetes i acció!

Podria dir que cada projecte ha nascut després d'entendre l'evolució dels sistemes i voler provar-ho de debò. No en mode "domèstic", volia replicar (sempre que fos possible) una versió empresarial.

Sota aquesta idea, vaig començar el Swarm Project amb la intenció de fer-lo evolucionar cap al K8s Project. I va evolucionar abans del previst a causa de l'explosió de Docker Swarm. El destí havia de ser el mateix.

Aquests projectes es basen en tenir prou temps per provar i entendre, fins a cert punt, però la crua realitat és que això no sempre és possible. Les explosions del dia a dia i els manteniments manuals acaben sent un mal de cap.

Així que podríem separar-ho en dos tipus d'evolucions:

• Aquelles que vols fer.
• Aquelles que necessites fer.

La diferència és senzilla i complexa alhora. Vols evolucionar un sistema, i per tant ho tires endavant. Si no s'aconsegueix, el pots fer evolucionar cap a una altra banda o simplement abandonar-lo. D'altra banda, hi ha aquelles que necessites per reduir les explosions, o per tenir una mica de descans. Abandonar-les és possible, però continuaràs tenint els problemes actuals.

Mentre que els dos projectes esmentats abans eren una cosa que volia fer per millorar la meva xarxa i aprendre, d'altres (com Proxmox) es van convertir en una necessitat després d'explosions contínues i de la dificultat d'ús.

tip

Saps què és llençar 20 minuts de la teva vida cada cop que vols preparar una VM des de zero amb tota la base de la xarxa? Doncs ara multiplica-ho per un clúster.

I d'aquí comença l'ideal d'aquest projecte. Una cosa que vaig aprendre després de desplegar i mantenir el K8s Project és que no era viable actualitzar manualment el sistema. Alguns serveis simplement exploten després d'actualitzar-se, d'altres s'actualitzen tant que no tens temps de posar-te al dia.

warning

Per descomptat, pots no actualitzar, igual que fan la majoria de les empreses. Però aquí la idea és apropar-se a un sistema tan "ideal" com sigui possible. De merda, el món n'està ple. Si us plau, no n'afegim més 😃.

Aleshores, què cal? Diversos punts:

• Simplificar la creació de màquines virtuals. Això serveix tant per desplegar entorns nous com per actualitzar nodes existents (associar-ne un de nou i destruir l'anterior, res d'actualitzar el preexistent).
• Desplegar aplicacions completes (base de dades, monitorització, Kubernetes, ...) des d'un catàleg, i poder-les regenerar fàcilment si exploten.
• Mantenir cert nivell d'actualitzacions. Automàtiques, si us plau.
• Tenir tota la xarxa sota control: IPs, DNS, servidors, carpetes compartides, monitorització, identitats, ...

Així, sense dolor.

Sora Project

El nom d'aquest projecte ve de la paraula japonesa sora, que significa cel. Després de molt de temps caminant al voltant d'edificis en flames, aquest projecte intenta enlairar-se cap al cel. Això no vol dir que els incendis s'apaguin, però et dona cert descans!

Les peces

La primera versió de Sora es basava en plantilles de Terraform que s'executaven a mà i en un FluxCD que ho desplegava tot dins de Kubernetes, bases de dades i volums inclosos. Funcionava, però cada peça requeria el seu propi ritual.

La versió actual substitueix totalment l'anterior i es divideix en quatre projectes, cadascun amb una única responsabilitat:

Projecte	Què és	Repositori
Sora Conductor	Assistent de terminal que prepara el servidor orquestrador, la primera màquina de la xarxa: DNS, NTP, base de dades, Nagios, certificats, ... i desplega Sora Horizon	sora-conductor
Sora Horizon	Web de gestió de tota la xarxa. Desplega aplicacions a Proxmox a partir de plantilles i manté la xarxa, l'inventari, la monitorització i Keycloak en un únic lloc	sora-horizon
Infraestructura	Les plantilles que importa Horizon, amb els seus Terraform i scripts: imatge Linux, PostgreSQL, monitorització, Kubernetes, GitLab Runner	sora-project-infrastructure
FluxCD	Tot el que s'executa dins del clúster de Kubernetes: xarxa, ingress, certificats, observabilitat, Keycloak i les aplicacions	fluxcd-thor-network

L'ordre de desplegament complet, des d'un Proxmox buit fins a les aplicacions, és a la guia de desplegament.

Arquitectura

Les idees base que segueixen totes les peces:

• Infraestructura com a codi. Els Terraform, els scripts i les plantilles d'Horizon que els combinen estan versionats a Git. Horizon importa aquestes plantilles i les fa servir per desplegar els stacks, i és qui guarda totes les dades de la xarxa (adreces, noms, servidors, credencials, stacks, ...), centralitzant-ho tot en un únic lloc.
• Actualitzar o substituir. Depèn de la peça: algunes s'actualitzen al mateix lloc (editar un stack torna a executar només el que ha canviat), mentre que d'altres, com els nodes de Kubernetes, no s'actualitzen mai: es crea una màquina nova, s'uneix al grup i es destrueix l'anterior. Horizon converteix tots dos casos en un simple formulari.
• Kubernetes sense estat. El clúster no té volums: les bases de dades viuen en un PostgreSQL extern, i tota la resta és a Git. Si el clúster mor, se'n desplega un de nou i FluxCD l'omple.
• Monitorització fora del clúster. Una màquina dedicada rep mètriques, logs i traces de totes les VMs i clústers, així que continua informant quan Kubernetes no ho fa.
• Un únic punt de control. Horizon coneix les xarxes, IPs, noms DNS, servidors, carpetes compartides i credencials, i publica a Pi-hole, Nagios, Prometheus i Grafana el que desplega.

Tecnologia utilitzada

Àrea	Tecnologia
Virtualització	Proxmox VE
Sistema operatiu	Ubuntu (cloud image amb cloud-init)
Creació de màquines	Terraform, executat per Sora Horizon
DNS i DHCP	Pi-hole
Base de dades	PostgreSQL + PgBouncer
Monitorització	Nagios, Prometheus, Loki, Tempo, Grafana
Orquestració	Kubernetes (kubeadm), CRI-O, Calico
Manteniment del clúster	FluxCD (Flux Operator)
Identitat	Keycloak
Certificats	Let's Encrypt mitjançant el DNS de Cloudflare

Avís

Com he indicat al principi, Sora Project NO planteja un sistema domèstic, s'enfoca en una ideologia empresarial. Això vol dir que no és útil per muntar un sistema a casa amb pocs recursos. Pots plantejar sistemes molt més simples (fins i tot amb una base similar a aquesta) i amb menys maquinari.

Aquest projecte té tantes peces que no és viable explicar el funcionament de cadascuna, així que cal conèixer les tecnologies bàsiques utilitzades per entendre'l. Cada repositori disposa de la seva pròpia documentació tècnica, enllaçada a cada secció.

SSD

Oblida't de fer servir HDD. SSD o no funcionarà.