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.
En este artículo exploraremos un proyecto de hacking automotriz en el que controlamos el ventilador de alta velocidad (HFC) de un Ford en función de la temperatura del refrigerante. Para ello, utilizamos Python, un adaptador OBD-II ELM327 y el análisis de paquetes con Wireshark. Este proyecto me permitió aprender sobre comunicación CAN, protocolos automotrices y cómo combinar herramientas de red y programación para resolver problemas prácticos. El objetivo inicial era entender el mecanismo de activación y desactivación del ventilador de alta velocidad.
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.
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.