Cuando escuché por primera vez el nombre n8n, pensé que se trataba de una herramienta de automatización de ciencia‑ficción, algo tan complejo que tendría una curva de aprendizaje digna de un máster. Resultó ser algo mucho más cercano: una herramienta de automatización visual, de código abierto, que promete que cualquier persona, desde un estudiante técnico hasta el CEO que se empeña en “optimizar” todo, puede arrastrar y soltar bloques para conectar Google Sheets, Slack, GitHub y mil servicios más.
El aire de mi Homelab vibraba con una energía latente, marcado por el susurro incesante de los ventiladores que libraban una batalla contra el calor de las máquinas. Para mí, ese murmullo era más que ruido, ese era el sonido de la promesa, la sinfonía de la automatización e inteligencia artificial que estaba construyendo. No se trataba solo de desplegar herramientas, sino de orquestar un ecosistema completo, una danza compleja de datos y procesos.
La gente cree que construir un homelab se trata de gastar dinero en hardware caro. Pero eso es solo la mitad de la historia. El verdadero poder de un homelab no reside en sus máquinas, sino en la forma en que las conectas. Y a veces, esa conexión va más allá de las paredes de tu casa.
En mi caso, la “forma” en que conecto mi homelab ha evolucionado hasta el punto de que se extiende a través de múltiples datacenters. Sí, has leído bien. No me limito a un solo servidor en mi habitación; tengo recursos distribuidos en varios centros de datos, todos funcionando como una sola red interna. La razón detrás de esto va más allá de la redundancia o la experimentación; es la búsqueda de la máxima flexibilidad y eficiencia.
En este post explicaremos cómo usar el toolkit de Elemental, un producto de código abierto para desplegar un clúster productivo de K3S. Primero, revisaremos las definiciones básicas del software que vamos a utilizar.
Por un lado, tenemos K3S, un software de orquestación de contenedores muy similar a Kubernetes (K8S) y OpenShift, pero con la particularidad de ser mucho más ligero. Para lograr esta eficiencia, los desarrolladores han eliminado componentes opcionales de un clúster Kubernetes, dejándolo con lo esencial para funcionar. Esto hace que los requisitos mínimos para un despliegue de K3S sean entre 2 y 3 veces menores que los de K8S, y hasta 7 u 8 veces menores que los de OpenShift.
En este artículo vamos a explicar el proceso para el despliegue de un cluster productivo de OKD sobre un virtualizador de KVM en el cual no disponemos de cloud-init por lo que el proceso de despliegue se hace siguiendo la documentación como si lo desplegasemos sobre un entorno de baremetal, de hecho este mismo artículo serviría si queremos hacer el despliegue sobre un entorno baremetal.
Denominamos este cluster como productivo, ya que vamos a hacer un despliegue de un total de 5 nodos de Fedora CoreOS, de los cuales 3 servidores van a corresponderse con nodos master y 2 de ellos serán los denominados nodos worker, para entender mejor este despliegue, os dejo una imagen con un esquema de los componentes con sus IPs de tal forma que si a lo largo del artículo no se entiende alguno de los elementos se pueda revisar la imagen para entenderlo mejor.
Actualmente el proceso de creación y mantenimiento de un proyecto web puede ser una tarea tediosa, sin embargo, si pensamos como vamos a mantener un proyecto sin necesidad de grandes esfuerzos nos viene a la menta la automatización de las partes que no requieran de supervisión, es decir, todo lo relativo a la creación y publicación de la web del proyecto de Github.
En primer lugar tener claro como queremos publicar nuestra web, el proyecto que vamos a utilizar para este ejemplo es https://github.com/alefnode/jenkins-themes como veis he separado la web al directorio webpage que es donde tendremos toda la web a excepción de aquellas que se generan en el job de Jenkins.