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.
Los dispositivos SDM845 se denominan así por el procesador que utilizan Snapdragon 845, dispositivos de 8 núcleos con GPU Adreno 630, un procesador de 10 nanómetros de finales de 2017. Algunos de los dispositivos que integran este procesador son el Pocophone F1, Oneplus 6/6T, Shift 6mq, Google Pixel 3/3XL,… entre otros. ¿Por que estamos hoy aquí hablando de estos dispositivos? Porque gracias a la comunidad se ha ido integrando este procesador en el Kernel de GNU/Linux lo que permite portar distribuciones a estos dispositivos, al igual que ocurre con dispositivo con un soporte nativo se puede instalar un SO GNU/Linux en estos dispositivos.