Rem Homelab es un repositorio de github donde tengo guardadas todas mis configuraciones para múltiples servicios que utilizo en mi homelab. Con simples comandos puedes conectar servicios entre ellos separados por stacks por si no necesitas todo lo que uso.
Como ya acabo de comentar, Rem Homelab se divide en diferentes stacks, haciéndolo modular y mucho más sencillo de mantener. Todo se coloca bajo Docker Compose pero no sé si en un futuro probaré K8s... (pero puede ser complicarme demasiado la vida)
En el momento de este blog tenemos los siguientes
Despliega una interfaz web con modelos LLM de IA local importables desde la web de ollama o desde hugging face. Perfecto para reemplazar soluciones cloud como ChatGPT o Claude para generación de código, chat y/o uso en apps propias.
Despliega servicios para crear dashboards de monitoreo. De momento simplemente usa Homarr, pero tengo pensado añadir servicios como Grafana y Loki para monitorear usos por servicio y otros datos.
Despliega servicios para gestión documental. De manera opcional podemos desplegar un servicio que nos ayudará a clasificar los documentos y analizar el contenido con los metadatos usando IA. Para este servicio podemos usar lo desplegado en el stack de rem-ai.
Despliega servicios para crear un servidor media (Ver películas u otros contenidos en dispositivos locales o remotos). Con este stack de servicios podemos automatizar mayormente la descarga, clasificación, obtención de metadatos y visualización del contenido. De manera opcional podemos desplegar un servicio que hará bypass en túneles de captcha (úsalo bajo tu riesgo).
Despliega servicios para crear un reverse proxy y permitir la conexión a los servicios del homelab de manera externa. Puedes usar cualquier provider pero como es cómodo y gratis uso DuckDNS por eso tengo su servicio para que el DNS siempre apunte a la IP de nuestro router cuando cambie.
Para instalar Rem Homelab en tu máquina, primero asegura que tienes Docker instalado y el daemon esté arrancado.
Clonamos el proyecto desde su enlace.
git clone https://www.github.com/katarem/rem-homelab
cd rem-homelab
Creamos la network para todos los servicios. Para tener los diferentes módulos conectados entre sí necesitamos que usen una network ya creada.
docker network create rem-network
Para desplegar un stack, debemos crear un .env en su respectiva carpeta y añadimos los valores si es que son necesarios.
cp [stack]/.env.example [stack]/.env
Una vez establecidas las variables de entorno del stack, debemos ejecutarlo con el comando
docker compose --env-file=[stack]/.env -f [stack]-compose.yaml up -d
Tan sólo se necesita ir a la carpeta donde tengas instalado Rem Homelab y traer nuevos cambios del repositorio.
Nota: Si has hecho cambios en local, puede que tengas conflictos al hacer git pull. Está bajo tu responsabilidad saber resolver los conflictos.
cd rem-homelab
git pull
Ahora, una vez teniendo el repositorio en la última versión, ejecutamos los stacks que hayan recibido actualización y tengamos desplegados
docker compose --env-file=[stack]/.env -f [stack]-compose.yaml up -d
Al ejecutar este comando sólo se reiniciarán los contenedores que hayan recibido cambios en el yaml.
Con esta herramienta que hemos explorado hoy, el homelab puede ser una opción más sencilla para gente que no quiere indagar tanto en devops y tan sólo quiere ver sus servicios arrancar.
]]>No hace falta esperar a que el servidor se desplome en producción para darse cuenta de que no soporta la demanda. Por eso es vital hacer pruebas de carga desde temprano, para saber hasta dónde podemos llegar y planificar un escalado eficiente.
En este artículo te presento K6, una herramienta sencilla y poderosa para simular múltiples usuarios y medir el rendimiento real de tu API de forma automatizada.
K6 es una librería de testing de javascript para poder hacer pruebas de performance en nuestras APIs de forma automatizada. Podremos simular cargas masivas, requestest en cadena, todo lo que se te pueda ocurrir que conlleve muchas request, se puede hacer con K6.
Debemos instalar K6 desde su página oficial. Una vez instalado el CLI de K6, podemos comprobar que está funcionando con:
[rem@arch ~]$ k6 --version
k6 v1.0.0 (commit/41b4984b75, go1.24.2, linux/amd64)
Podemos hacer una prueba inicial con 1 usuario, primero escribiremos un script:
import http from 'k6/http';
export default function(){
const url = 'https://httpbin.test.k6.io/post';
const response = http.post(url,'hola mundo');
}
Ahora arrancamos K6 con lo siguiente:
k6 run script.js
Y saldrá algo como esto:
[rem@arch k6-test]$ k6 run script.js
/\ Grafana /‾‾/
/\ / \ |\ __ / /
/ \/ \ | |/ / / ‾‾\
/ \ | ( | (‾) |
/ __________ \ |_|\_\ \_____/
execution: local
script: script.js
output: -
scenarios: (100.00%) 1 scenario, 1 max VUs, 10m30s max duration (incl. graceful stop):
* default: 1 iterations for each of 1 VUs (maxDuration: 10m0s, gracefulStop: 30s)
█ TOTAL RESULTS
HTTP
http_req_duration......................: avg=33.4ms min=33.4ms med=33.4ms max=33.4ms p(90)=33.4ms p(95)=33.4ms
http_req_failed........................: 100.00% 1 out of 1
http_reqs..............................: 1 0.765221/s
EXECUTION
iteration_duration.....................: avg=1.3s min=1.3s med=1.3s max=1.3s p(90)=1.3s p(95)=1.3s
iterations.............................: 1 0.765221/s
vus....................................: 1 min=1 max=1
vus_max................................: 1 min=1 max=1
NETWORK
data_received..........................: 5.9 kB 4.5 kB/s
data_sent..............................: 576 B 441 B/s
running (00m01.3s), 0/1 VUs, 1 complete and 0 interrupted iterations
default ✓ [======================================] 1 VUs 00m01.3s/10m0s 1/1 iters, 1 per VU
Estas pruebas como podemos ver dan estadísticas enfocadas al rendimiento bruto de nuestra aplicación, tendremos muchísimos datos para poder tener una estimación realista de como se comportará nuestra API en un entorno real.
Si queremos que 5 usuarios arranquen la request:
[rem@arch k6-test]$ k6 run script.js --vus 5 --duration 30s
/\ Grafana /‾‾/
/\ / \ |\ __ / /
/ \/ \ | |/ / / ‾‾\
/ \ | ( | (‾) |
/ __________ \ |_|\_\ \_____/
execution: local
script: script.js
output: -
scenarios: (100.00%) 1 scenario, 5 max VUs, 1m0s max duration (incl. graceful stop):
* default: 5 looping VUs for 30s (gracefulStop: 30s)
█ TOTAL RESULTS
HTTP
http_req_duration......................: avg=32.26ms min=25.53ms med=28.37ms max=252.96ms p(90)=30.02ms p(95)=35.18ms
http_req_failed........................: 100.00% 4605 out of 4605
http_reqs..............................: 4605 153.412632/s
EXECUTION
iteration_duration.....................: avg=32.55ms min=25.61ms med=28.51ms max=253.09ms p(90)=30.18ms p(95)=35.65ms
iterations.............................: 4605 153.412632/s
vus....................................: 5 min=5 max=5
vus_max................................: 5 min=5 max=5
NETWORK
data_received..........................: 6.1 MB 202 kB/s
data_sent..............................: 402 kB 13 kB/s
running (0m30.0s), 0/5 VUs, 4605 complete and 0 interrupted iterations
default ✓ [======================================] 5 VUs 30s
Vemos que la media sigue sin cambiar, eso es porque esta API REST que estamos probando es bastante robusta, hemos probado 5 usuarios concurrentes haciendo requests durante 30 segundos y se completaron 4605 requests sin error.
Al no pasarle iteraciones, han intentado todas las request que han podido durante ese tiempo.
Poniendo 50 iteraciones, será que se harán 50 requests entre 10 usuarios:
[rem@arch k6-test]$ k6 run script.js --vus 10 -i 50
/\ Grafana /‾‾/
/\ / \ |\ __ / /
/ \/ \ | |/ / / ‾‾\
/ \ | ( | (‾) |
/ __________ \ |_|\_\ \_____/
execution: local
script: script.js
output: -
scenarios: (100.00%) 1 scenario, 10 max VUs, 10m30s max duration (incl. graceful stop):
* default: 50 iterations shared among 10 VUs (maxDuration: 10m0s, gracefulStop: 30s)
█ TOTAL RESULTS
HTTP
http_req_duration......................: avg=31.97ms min=27.22ms med=29.51ms max=41.86ms p(90)=41.64ms p(95)=41.76ms
http_req_failed........................: 100.00% 50 out of 50
http_reqs..............................: 50 113.112869/s
EXECUTION
iteration_duration.....................: avg=87.67ms min=27.41ms med=29.59ms max=320ms p(90)=319.58ms p(95)=319.68ms
iterations.............................: 50 113.112869/s
NETWORK
data_received..........................: 111 kB 252 kB/s
data_sent..............................: 9.2 kB 21 kB/s
running (00m00.4s), 00/10 VUs, 50 complete and 0 interrupted iterations
default ✓ [======================================] 10 VUs 00m00.4s/10m0s 50/50 shared iters
Si necesitas tests más precisos te recomiendo ejecutar k6 run --help para obtener toda la información de los muchos parámetros que podemos utilizar para testing.
No basta con que tu API funcione para un usuario: hay que saber cómo se comporta bajo carga. K6 es una herramienta sencilla y efectiva para hacer esas pruebas y obtener datos reales sobre el rendimiento.
Si aún no haces tests de carga, este es un gran momento para empezar. Y si ya los haces, K6 te facilitará mucho el trabajo.
]]>StringBuilder y por qué es tan importante
A veces usando Java, sobre todo cuando apenas nos enseñan el lenguaje, solemos hacer así no?
String frase = "Los primeros 100 números son: ";
for(int i = 1; i <= 100; i++){
frase += i + ",";
}
System.out.println(frase);
Sí, imprimirá los primeros 100 números dentro del String, normalmente vemos el resultado y con eso conformes, no? ¿Qué pasa si te digo que en concatenaciones más "serias" esto puede patear la memoria de la JVM? Pues sí, concatenar Strings en bucles grandes puede llevar a problemas de memoria.
Java es un lenguaje orientado a objetos, y los objetos (como String) viven en el heap, es decir, la parte dinámica de la memoria. Ahora, aunque += parece algo simple, lo que realmente está haciendo Java por debajo en cada vuelta del bucle es algo como esto:
String frase = "Los primeros 100 números son: ";
for(int i = 1; i <= 100; i++){
frase = new StringBuilder(frase).append(i).append(",").toString();
}
System.out.println(frase);
O sea, que en cada iteración:
Se crea un StringBuilder nuevo con el contenido de frase.
Se le añade el número y la coma.
Y se transforma de nuevo en un String.
Eso, una y otra vez, va generando montones de objetos nuevos que se almacenan en el heap. No lo notas si el bucle es pequeño, pero cuando escalas a bucles con miles o millones de iteraciones (o anidados), la cosa se pone fea: empieza a intervenir el Garbage Collector más seguido y el rendimiento de tu app cae.
¿Cómo lo solucionamos? Usamos StringBuilder de forma más inteligente:
StringBuilder frase = new StringBuilder("Los primeros 100 números son: ");
for(int i = 1; i <= 100; i++){
frase.append(i).append(",");
}
System.out.println(frase.toString());
Así que ya sabes: si estás concatenando cadenas dentro de un bucle, no te quedes con el += solo porque funciona. Usar StringBuilder no solo mejora tu código, también evita problemas de rendimiento cuando el programa empieza a crecer.
Este tipo de detalles marcan la diferencia cuando trabajas con más datos o en proyectos más grandes. Y lo mejor es que empiezas a pensar como la JVM: no solo en que algo funcione, sino en cómo lo está haciendo por dentro.
]]>Mi nombre es Cristian, soy desarrollador backend junior, con casi 2 años de experiencia en el sector me especializo en Java (y si aún recordase Kotlin...), sobre todo en la programación cloud con Spring Boot y Spring Cloud.
Aparte de lo que hago en el trabajo, me gusta mucho programar por mi cuenta, estáis bienvenidos a mirar los repositorios que tengo en mi perfil o los proyectos expuestos en mi portfolio (sí, los de backend también podemos llegar a crear webs).
Saliendo del tema informática, también me encantan el anime y los videojuegos. Mi anime favorito es One Piece, y mi videojuego al que más horas he viciado es al Lol (más de las que debería, pero bueno). Por lo general en anime, suelo ver Shonen, Seinen y romance (Shoujo), y de videojuegos quitando el mencionado me gustan juegos con buena historia o jugabilidad para un jugador, otro de mis favoritos es Subnautica (deberíais probarlo si no lo habéis hecho).
Bueno, dejo de yappear ya más sobre mí pero creo que si yo encontrase esta web me gustaría saber más de la persona que dedica su tiempo en escribir todas estas vainas y las sube a internet.
]]>¿Qué qué es el Manual de Juego ?
Lo puedes definir un blog, una guía, un manual, una simple web... Esto va a ser un pozo donde voy a tirar todos mis conocimientos que voy adquiriendo como desarrollador de software.
Eres bienvenido a utilizar todo lo que encuentres aquí y también a sugerir o aportar lo que quieras, siempre que sea algo relacionado con informática claro...
Cualquier duda, aclaración, sugerencia, queja, o lo que sea, no tengo problemas en que se me contacte a través de mis redes.
Espero disfruten la web, la voy a hacer con todo mi cariño y conocimiento posibles.
]]>