Introducción
Antes de empezar
Para embarcarse en un proyecto, primero hay que entenderlo, así que ¡sofá, palomitas, y acción!
Podría decir que cada proyecto ha sido tras entender la evolución de los sistemas y querer probarlo en real. No en un modo "doméstico", quería replicar (siempre que fuera posible) una versión empresarial.
Bajo esa idea, empecé el Swarm Project con intención de hacerlo evolucionar hacia el K8s Project. Y evolucionó antes de lo esperado debido a la explosión de Docker Swarm. El destino iba a ser el mismo.
Estos proyectos se basan en tener suficiente tiempo para probar y entender, hasta cierto nivel, pero la cruda realidad es que esto no siempre es posible. Las explosiones del día a día y los mantenimientos manuales acaban siendo un dolor de cabeza.
Así que podríamos separar en dos tipos de evoluciones:
- Aquellas que quieres hacer.
- Aquellas que necesitas hacer.
La diferencia es sencilla y compleja a la vez. Quieres evolucionar un sistema, y por tanto lo llevas a cabo. Si no se logra, puedes evolucionarlo hacia otro lado o simplemente abandonarlo. Por otro lado, están aquellas que necesitas para reducir las explosiones, o para tener algo de descanso. Abandonarlas es posible, pero seguirás teniendo los problemas actuales.
Mientras que los dos proyectos mencionados anteriormente eran algo que quería hacer para mejorar mi red y aprender, otros (como Proxmox) se volvieron una necesidad tras explosiones continuas y la dificultad de uso.
¿Sabes lo que es tirar 20 minutos de tu vida cada vez que quieres preparar una VM desde 0 con toda la base de la red? Pues ahora multiplica por un clúster.
Y de aquí empieza el ideal hacia este proyecto. Algo que aprendí tras desplegar y mantener el K8s Project, es que no era viable actualizar manualmente el sistema. Algunos servicios simplemente explotan tras su actualización, otros actualizan tanto que no tienes tiempo de mantenerte al día.
Por supuesto, puedes no actualizar, igual que hacen la mayoría de las empresas. Pero aquí la idea es acercarse a un sistema lo más "ideal" posible. Para mierda, el mundo está lleno. Por favor, no incluyamos más 😃.
Entonces, ¿qué es necesario? Varios puntos:
- Simplificar la creación de máquinas virtuales. Esto sirve tanto para desplegar nuevos entornos como para actualizar nodos existentes (asociar uno nuevo y destruir el anterior, nada de actualizar el preexistente).
- Desplegar aplicaciones completas (base de datos, monitorización, Kubernetes, ...) desde un catálogo, y poder regenerarlas fácilmente si explotan.
- Mantener cierto nivel de actualizaciones. Automáticas, por favor.
- Tener toda la red bajo control: IPs, DNS, servidores, carpetas compartidas, monitorización, identidades, ...
Así, sin dolor.
El nombre de este proyecto viene de la palabra japonesa sora, la cual significa cielo. Tras mucho tiempo caminando alrededor de edificios en llamas, este proyecto intenta poder despegar hacia el cielo. Eso no significa que los incendios se apaguen, ¡pero te da cierto descanso de ellos!
Las piezas
La primera versión de Sora se basaba en plantillas de Terraform que se ejecutaban a mano y en un FluxCD que lo desplegaba todo dentro de Kubernetes, bases de datos y volúmenes incluidos. Funcionaba, pero cada pieza requería su propio ritual.
La versión actual reemplaza totalmente la anterior y se divide en cuatro proyectos, cada uno con una única responsabilidad:
| Proyecto | Qué es | Repositorio |
|---|---|---|
| Sora Conductor | Asistente de terminal que prepara el servidor orquestador, la primera máquina de la red: DNS, NTP, base de datos, Nagios, certificados, ... y despliega Sora Horizon | sora-conductor |
| Sora Horizon | Web de gestión de toda la red. Despliega aplicaciones en Proxmox a partir de plantillas y mantiene red, inventario, monitorización y Keycloak en un único sitio | sora-horizon |
| Infraestructura | Las plantillas que Horizon importa, con sus Terraform y scripts: imagen Linux, PostgreSQL, monitorización, Kubernetes, GitLab Runner | sora-project-infrastructure |
| FluxCD | Todo lo que se ejecuta dentro del clúster de Kubernetes: red, ingress, certificados, observabilidad, Keycloak y las aplicaciones | fluxcd-thor-network |
El orden de despliegue completo, desde un Proxmox vacío hasta las aplicaciones, está en la guía de despliegue.
Arquitectura
Las ideas base que siguen todas las piezas:
- Infraestructura como código. Los Terraform, los scripts y las plantillas de Horizon que los combinan están versionados en Git. Horizon importa esas plantillas y las usa para desplegar los stacks, y es quien guarda todos los datos de la red (direcciones, nombres, servidores, credenciales, stacks, ...), centralizándolo todo en un único sitio.
- Actualizar o sustituir. Depende de la pieza: algunas se actualizan en el sitio (editar un stack vuelve a ejecutar solo lo que ha cambiado), mientras que otras, como los nodos de Kubernetes, nunca se actualizan: se crea una máquina nueva, se une al grupo y se destruye la anterior. Horizon convierte ambos casos en un simple formulario.
- Kubernetes sin estado. El clúster no tiene volúmenes: las bases de datos viven en un PostgreSQL externo, y todo lo demás está en Git. Si el clúster muere, se despliega uno nuevo y FluxCD lo rellena.
- Monitorización fuera del clúster. Una máquina dedicada recibe métricas, logs y trazas de todas las VMs y clústeres, así que sigue informando cuando Kubernetes no lo hace.
- Un único punto de control. Horizon conoce las redes, IPs, nombres DNS, servidores, carpetas compartidas y credenciales, y publica en Pi-hole, Nagios, Prometheus y Grafana lo que despliega.
Tecnología empleada
| Área | Tecnología |
|---|---|
| Virtualización | Proxmox VE |
| Sistema operativo | Ubuntu (cloud image con cloud-init) |
| Creación de máquinas | Terraform, ejecutado por Sora Horizon |
| DNS y DHCP | Pi-hole |
| Base de datos | PostgreSQL + PgBouncer |
| Monitorización | Nagios, Prometheus, Loki, Tempo, Grafana |
| Orquestación | Kubernetes (kubeadm), CRI-O, Calico |
| Mantenimiento del clúster | FluxCD (Flux Operator) |
| Identidad | Keycloak |
| Certificados | Let's Encrypt mediante DNS de Cloudflare |
Aviso
Como he indicado al principio, Sora Project NO plantea un sistema doméstico, se enfoca en una ideología empresarial. Esto significa que no es útil para montar un sistema en casa con pocos recursos. Puedes plantear sistemas mucho más simplistas (incluso con una base similar a esta) y con menos hardware.
Este proyecto tiene tantas piezas que no es viable explicar el funcionamiento de cada una, así que conocer las tecnologías básicas utilizadas es necesario para entenderlo. Cada repositorio dispone de su propia documentación técnica, enlazada en cada sección.
Olvídate de usar HDD. SSD o no funcionará.