Fa dues setmanes vaig presentar la nova versió de Sora Project. Fa diversos mesos que està en desenvolupament, però el seu roadmap no estava acabat. Així que continuem amb més canvis: registrar les tasques programades que estan actives a la xarxa, saber si algun servidor de Proxmox està sobrecarregat, conèixer què està fent servir el DHCP (ja que possiblement caldria donar-li una IP fixa) i facilitar enormement la part d'observabilitat, que com més la fas servir, més t'adones del que li falta.

Fa molts anys vivia amb un magnífic Excel que evolucionava per gestionar les meves despeses. L'Excel es tornava cada vegada més complicat i difícil de gestionar, i no hi havia cap app que m'agradés, així que vaig fer servir la idea de qualsevol desenvolupador: si no existeix, el crees. Així va néixer la primera versió de Kirin.

I el pobre Kirin es va convertir en un camp de proves: les noves arquitectures que volia provar anaven a parar a Kirin, juntament amb noves funcionalitats. Ha canviat de llenguatge de programació, de framework, ha estat un monòlit, un microservei, una app Kubernetes native, ...

Després d'uns anys sense tocar-lo, tocava tornar-hi i reconstruir-lo, aquesta vegada completament en la seva versió 3.

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.

En 2022 empecé el proyecto final para abandonar Docker Swarm y cambiar a Kubernetes. Aunque tenía conocimientos en Kubernetes, cuando te pones a construir toda la base, decidir el tipo de engine para los contenedores, el tipo de red, solucionar las piezas que no tienes "de serie" ya que usas bare-metal, ... Por suerte internet está lleno de gente loca que se dedica a documentar y responder a todos estos temas. Por desgracia, según la posición del sol la siguiente 💣 es diferente. Tienes que prepararte para cualquier improvisto, ¡incluso ese que aún no has visto/deducido!

Aun así, terminé el 2023 con el sistema funcionando y documentado. Un éxito. Bueno, menos por el mantenimiento enorme que NO te explican. Y es que Kubernetes puede ser muy bonito, pero es absurdamente complejo, y muchos de los servicios también lo son.

Tocaba buscar una solución. Simplificar mantenimiento, simplificar creación. Así nació Sora Project.

Tras cambiar a Proxmox y jugar con Terraform para automatizar la creación de una plataforma Kubernetes (sí, la documentaré cuando la considere totalmente estable 😋), faltaba añadir las métricas.

En mi caso, las máquinas virtuales se utilizan casi en exclusiva para construir clústers de Kubernetes, y estos a su vez tienen métricas de cada nodo, mientras el Linux es monitorizado por Nagios.

Y aun así, el tiempo me ha mostrado que no es suficiente, necesitas monitorizar también el host físico que gestiona a Proxmox.

Teniendo esto en cuenta, he creado una serie de modificaciones para exportar métricas hacia un Prometheus existente, desplegado en el Kubernetes en mi caso, pero se puede ajustar hacia cualquier otro.

Tras muchos y muchos años batallando con VMWare ESXi, es hora de cambiar.

Empecé con la versión que se instalaba sobre un Linux, donde temblabas de medio tras cada actualización de Kernel sabiendo que iba a dejar de funcionar, y tendrías que pasar noches en vela para encontrar una solución (donde quizás, ni existía), para saltar a ESXi Hypervisor. Esta versión utilizaba su propio sistema operativo y tenía versión gratuita con grandes limitaciones (sin API, las copias de seguridad iban a ser un infierno, pero todo se puede solucionar).

Y no, no era un camino de rosas. El hardware era descartado rápidamente, lo que obligaba a modificar las ISO para añadir la compatibilidad, o simplemente aceptar que ya no podrías actualizar más.

Todo para finalmente darnos una bonita patada, eliminar la versión gratuita y aumentar el precio de todo tras la compra de Broadcom. Si ya era caro, pues ahora te apuñalo 2 veces, no sea que te plantees pagar.

Así que toca abrir la puerta y largarse.

Hace mucho tiempo inicié un proyecto de gestión de contenedores con la tecnología Docker Swarm, pero los tiempos modernos utilizan Kubernetes, así que hacer crecer este proyecto no parece buena idea.

Para ello empieza una nueva trayectoria, esta vez con Kubernetes, replicando los mismos servicios, mejorando algunas secciones gracias a la experiencia y añadiendo nuevos servicios.

Y así es como se estrena el K8s Project.

Después de mucho tiempo, inauguro una nueva sección de IT.

Esta sección está dedicada a servicios que no estén en contenedores (ya que para eso están los proyectos específicos), ni aquellos que sean servicios básicos, que se despliegan dentro del Rasp Project.

Podría mentir descaradamente diciendo que fue hace 4 días cuando empecé un nuevo proyecto, uno más grande que ningún otro de los que he llevado a cabo: renovar mi infraestructura para utilizar contenedores.

Claro que, cuando empiezas a poner una piedra, te das cuenta de que quizás deberías poner más piedras, y construir un muro, y mover ese río de ahí, construir un puente, el pueblo, el castillo, ¡una ciudad!

Y así es como se han llevado a cabo varios proyectos en paralelo: la renovación de la web, el Rasp Project, y el Swarm Project.

Desde hace años, todas las webs deben estar en HTTPS, si no es así, es muy posible que navegadores o servicios se nieguen a utilizarlas.

Cuando nuestra web está publicada a internet, es buena idea contratar un certificado o utilizar sistemas gratuitos como Let's Encrypt, pero cuando tu web no está publicada a Internet, si no que forma parte de tu intranet, la cosa se complica.

En estos casos, se utilizan certificados autofirmados, estos son completamente funcionales, pero tienen la pega de que todos los sistemas muestran un mensaje para avisar de que ellos no confían en el certificado, aun así, si están bien hechos, es posible minimizar o eliminar este problema.