Tiempo para realizar lo mencionado aquí ? dos horas y con breaks.
Costo? Como anoté en las tres primeras partes esto fue un encargo para cliente. Desde el momento enb que entré a terminal en máquina limpia, hasta que cloné en la parte 5 fueron poco menos de tres días y no dedicados a esto..
La eficiencia técnica se traduce directamente en agilidad económica: mientras que el costo operativo de este stack en Vultr es de apenas 20 USD al mes, el proceso completo de implementación, desde el inicio de la configuración hasta la generación y clonación de la imagen final para el cliente, representó un gasto ínfimo de tan solo 2.33 USD. Esta cifra no solo cubre el tiempo de cómputo, sino también la transferencia de datos entre servidores durante el despliegue de la imagen maestra.
Es la prueba de que un servidor de alta densidad, basado en Debian 13 y optimizado quirúrgicamente, permite realizar despliegues masivos y entregas de infraestructura crítica por una fracción del costo de los proveedores tradicionales. No es solo gastar menos, es la capacidad de replicar entornos profesionales de producción en cuestión de minutos y por el precio de un café, manteniendo la soberanía total sobre el sistema y los datos del cliente.
En artículos anteriores levantamos con Debian un stack spring boot en un LAMP de 4gb y 80 disco duro. Quedé para terminar de poner un ejemplo con thymeleaf de un carrito de compras modificado de algo que está en internet sabiendo que hay limitaciones, pero como prueba de concepto.
Al mismo tiempo creo que es buena idea por una paridad por el manual de LEMP, levantar aquí Quarkus en modo dev, como prueba de concepto.
Al mismo tiempo hay tres ideas que me gustaría comentar antes para que se entienda mejor.
- Dentro de grupos tradicionales, de mi trabajo fuera de sistemas, se usa el término de COMPARTIR, IMPONER Y ORGANIZAR. Lo que estoy haciendo aqui y que hacen los de código libre como el del carrito de compras, es compartir. Si, tiene sus riesgos. Una persona decente evita IMPONER a menos que no le quede otro remedio. Pero en muchos trabajos te IMPONEN algo que no funciona y que se lleva a la empresa entre las patas y te acusan a ti. A mi me pasó solo una vez por el 2000 cuando trataron de usar PDO y access para mas de 50 usuarios simultáneos a pesar que les dije que access colapsa con 5 usuarios desde AÑOS antes. Mi trabajo es en muchos aspectos ORGANIZAR y tratar de arreglar desastres e incorporar nuevas solicitudes a un esquema simplificado.
- Con el paso del tiempo los sistemas se degradan y no solo por la obsolesencia programada o cambios de versiones. No sabes que basura le ponen al servidor después. O tu proveedor te empieza a hacer balooning. (dar menos memoria o cpu que la que les pagas) O cambios de proveedor porque el cliente quiere reducción de costos aunque sea 20% mas lento y 1% mas barato. Pero es importante que tengas presente que debes documentar que hiciste, que instalaste y que está. En código decir que versión de lenguaje o librería se usa.
- No es raro que alguien se equivoque si tiene dos servidores y trabaje en el servidor equivocado. Eso puede causar conflictos y a veces reinstalar todo el server. Por eso es que en muchos lugares no te quieren decir que tienen porque lo que tienen es miedo y no tienen ni idea de como lo hicieron funcionar después de un dedazo. «servidores en pincitas» digamos.
- Hay cosas que siempre fueron mala idea y nunca funcionaron aunque te digan lo contrario. En 2022 Tuve que alterar un sistema php 5.6 Laravel 5.2 hecho en 2017 que siempre ponía una frase en Alemán. La tecnología eraobsoleta ya entonces (2017). o cuando en 2006 me dieron un sistema en visual basic raro, y luego descubrí que habían sido dos programadores originales. Me dieron el código de uno y la base de datos de otro. Y aunque usé mucho del primero, cuando TRES años después aceptaron que me dieron de dos personas diferentes, me hubiera resultado mucho mejor haberlo hecho de cero con la base de datos existente porque uno usaba colecciones a lo bestia y el segundo diseñó para sql 2000 cuando el server real era sql 7. Si SQL7, no sql 2005 o sql 2008 (sql2005 por cierto hubiera sido peor pero eso es otra historia de terror por los problemas que introdujo 2005 en adelante). Por favor… Verifica que versiones tienes de base de datos, sistema operativo , lenguajes de operación como primer paso. A lo mejor no te dejan verificarlo y trabajas doble pero mientras te pagan. Y pon por escrito plataforma destino y lo que te dijeron que tenían.
Asi que por completitud, vamos a instalar en debian 13 de 4 gb ram con LAMP el quarkus dev y veremos en otro tema lo del carrito de compras, notando problemas que tiene, aciertos que tiene y agradeciendo la aportación original, adaptandola a tiempos modernos y sin darle hardening. Es vital recordarle al lector que un código bajado de internet es un punto de partida, no un producto final para producción.
1 Quarkus:
De entrada es buena práctica de seguridad cambiar el puerto a algo diferente, Y en este caso es necesario. Por lo mismo como es «Modo Dev», recuerda que por defecto usa el puerto 8080, que ya tenemos ocupado por el «TestServer» de Spring. Por eso verás que uso 8081 en el comando de arranque:
Esto lo harás mas adelante.
# Arrancando Quarkus en el puerto 8081 para no chocar con Spring
./mvnw quarkus:dev -Dquarkus.http.port=8081
1.1. El Ajuste en Apache (El Puente)
Para que el mundo vea ese Quarkus en el 8081 a través de tu dominio, necesitamos añadir el puente en tu archivo de configuración SSL. Esto mantiene la coherencia con lo que hicimos antes:
Apache
# Añadir dentro de /etc/apache2/sites-available/tu-dominio.com-le-ssl.conf
# Proxy para Quarkus Dev Mode
ProxyPass /quarkus http://127.0.0.1:8081
ProxyPassReverse /quarkus http://127.0.0.1:8081
El fragmento te debe quedar así
# Proxy para el Backend de Spring Boot
ProxyPreserveHost On
ProxyPass /api/ http://127.0.0.1:8080/api
ProxyPassReverse /api/ http://127.0.0.1:8080/api# Proxy para Quarkus Dev Mode
ProxyPass /quarkus http://127.0.0.1:8081
ProxyPassReverse /quarkus http://127.0.0.1:8081
1.2. ¿Por qué «Modo Dev» en un servidor?
Es importante explicar que, aunque en producción usaríamos un ejecutable nativo, el modo Dev en el servidor nos permite:
- Live Coding: Cambias el código y los cambios se ven al refrescar el navegador (vía Apache).
- Dev UI: Quarkus levanta una interfaz increíble en /q/dev que facilita mucho la vida del programador.
- Pero… meterme en llas diferencia de modos de nativo y graal es mucho mas tardado. Así que dev sirve perfectamente para demostrar que Quarkus está instalado.
1.3. El Código «Hola Mundo» Ultraligero será el default
1.3.1 Preparar el terreno (Directorios y Permisos)
Como estamos bajo la filosofía de ORGANIZAR, vamos a crear una carpeta específica dentro de /var/www/ para que conviva con tus otros proyectos.
OJO : Quarkus no se «instala» en el sistema como un servicio tradicional (como un apt install).
Quarkus es un framework basado en Maven o Gradle. Lo que «instalas» es la estructura de tu proyecto y el ejecutable vive dentro de la carpeta que tú decidas. En nuestro caso, la «instalación» es el proyecto mismo que generamos.
# Crear la carpeta del proyecto
mkdir -p /var/www/quarkus-app
# Dar propiedad al usuario actual para poder trabajar sin sudo constante
chown -R $USER:$USER /var/www/quarkus-app
cd /var/www/quarkus-app
1.3.2. Reinstalando Maven y Gradle.
Estas dos herramientas siempre sirven. Teóricamente tienes Maven por Spring, pero casi siempre instalo los dos para detectar y solucionar problemas de permisos, versiones, y gradle es mi preferido aunque sea antiguo porque sufre menos corrupción y menos afectado por problemas de permisos. Uno es un camión de carga (maven) y el otro es un sedán con buen motor y que consume menos ram (gradle). Es mi punto de vista.
Tratar de usar java springboot o quarkus sin maven o sin gradle es como tratar de tomar agua sin vaso y sin manos.
# Actualizamos repositorios
apt update# Instalar Maven (El estándar para la mayoría de proyectos Spring/Quarkus)
apt install maven -y# Verificar Maven
mvn -version
Para Gradle, si prefieres tenerlo disponible (muchos devs de la «Tribu Spring» lo aman por ser más rápido que Maven):Bash
apt install gradle -y
# Verificar Gradle
gradle -v
1.3.3. Generar el proyecto Quarkus de cero
Fijate que uso un directorio con mis iniciales. Usa lo que tu quieras.
En lugar de descargar un ZIP, usaremos el comando de Maven (que ya deberías tener por el paso de Spring o la reinstalación del paso previo) para generar la estructura básica. Esto garantiza que se cree el directorio com/aoa/ que mencionamos:
mvn io.quarkus.platform:quarkus-maven-plugin:3.6.4:create \
-DprojectGroupId=com.aoa \
-DprojectArtifactId=monitoreo-quarkus \
-DclassName=»com.aoa.GreetingResource» \
-Dpath=»/quarkus»
cd monitoreo-quarkus
La primera vez que corres el comando de generación, Maven descargará medio internet. No te asustes. Es el «costo de entrada» para tener todas las dependencias organizadas. Si eres como yo, quizá te den ganas de llorar al ver TODO lo que se instala para un hola mundo. Se positivo, velo como «area de oportunidad» o «menos competencia»
Verás un letrero con letras verdes diciendo BUILD SUCESS. Si no lo ves algo hiciste mal y no debes proseguir.
Antes de que el usuario intente arrancar Quarkus en el punto 1.3.3, necesita saber que el archivo de configuración debe estar listo, de lo contrario chocará con Spring. Puedes añadir esto:
1.3.4 El ADN del proyecto (Puertos)
Entra a la carpeta y dile a Quarkus quién es y por dónde debe hablar:
Asegúrate de que tenga estas líneas para que Apache pueda encontrarlo… Añade estas líneas para asegurar la paz con Apache y Spring:
- mkdir -p src/main/resources
- nano src/main/resources/application.properties
Properties
quarkus.http.port=8081
quarkus.http.host=127.0.0.1
Recuerda que siempre debes Verificar y Recargar Apache
Antes de reiniciar, siempre es bueno verificar que no dejamos algún error de dedo (como un espacio antes de <VirtualHost> o una comilla curva de WordPress).
- # 1. Test de configuración (Busca el «Syntax OK»)
- apache2ctl configtest
- # 2. Si todo está bien, recargamos
- systemctl restart apache2
1.3.5 El problema de las versiones.
Recuerdas que dijimos que tenemos SDK 21 ? Pues Maven, Gradle, tus compañeros tu jefe o lo que sea pueden estar seguros que el servidor no tiene lo que quieres. Y eso debes primer asegurarte que es lo que tienes. Aqui tenemos SDK 21. Pero Maven puede que tenga una versión diferente.
Revisa con Maven que tienes :
- mvn -version
Te debe decir que tienes 21.0.9 Si no busca en internet y revisa por si las dudas en que servidor estás.
Si estás en el servidor correcto y debes corregirlo empezamos antes que nada, por editar el pom.xml de maven, su configuración. o vas a obtener un feo letrero rojo que diga «release version 21 not supported»
La solución rápida (El ajuste en el pom.xml)
Debemos decirle explícitamente a Maven que use la versión 21. Entra al archivo de configuración de tu proyecto:
- cd /var/www/quarkus-app/monitoreo-quarkus
- nano pom.xml
Busca la etiqueta <properties> (está al principio) y asegúrate de que estas dos líneas digan 21:<maven.compiler.release>21</maven.compiler.release>
<maven.compiler.source>21</maven.compiler.source>
<maven.compiler.target>21</maven.compiler.target>¿Por qué pasa esto?
Como puse antes: «Verifica que versiones tienes… como primer paso». Aquí tienes el ejemplo vivo. Tienes el JDK 21 instalado (la máquina), pero Maven está tratando de usar un nivel de lenguaje que no reconoce o que cree que no está soportado por el compilador actual.Bonus:
- Una vez me pasó hace años que estaban tratando de echar a andar quarkus en un servidor equivocado. Lo instalaron en uno y se queajban que no existia la carpeta de archivos.
Segundo paso : «Verifica que versiones tienes… y en que servidor estás como segundo paso»
1.3.6 El momento de la verdad (Arrancar Quarkus)
la diferencia entre texto inútil y código, son los permisos.
Porque ?
A veces alguien mete mano. En windows lo hace el sistema operativo mismo. Pero si no eres el que usa el server en exclusiva, se precavido y si no también.
- cd /var/www/quarkus-app/monitoreo-quarkus
- chmod +x mvnw
A veces el BUILD SUCCESS de la generación del proyecto nos miente dándonos una falsa sensación de seguridad. El wrapper (mvnw) es un script de shell, y en Linux, un script sin permiso de ejecución es solo un archivo de texto inútil. No olvides el chmod +x mvnw o te quedarás mirando la pantalla sin entender por qué el comando no hace nada cuando ayer si funcionaba.
Ahora que Apache ya tiene el puente construido hacia el puerto 8081, solo falta que alguien esté escuchando del otro lado. Corre el comando que ya tenías:
- cd /var/www/quarkus-app/monitoreo-quarkus
- ./mvnw quarkus:dev -Dquarkus.http.port=8081
Esto es vital. Cuando corres Quarkus en una terminal de un servidor remoto (vía SSH), a veces el modo dev intenta abrir una ventana o se queda esperando una entrada de teclado. Además, necesitamos que acepte conexiones externas (a través de Apache).
¿Por qué hacerlo así?
Al crear el directorio com.aoa mediante el plugin de Maven, ya tienes un archivo llamado GreetingResource.java listo para ser modificado. No tienes que crear rutas manualmente.
1.3.7 Verificación Final de Quarkus
Si todo ha salido bien, al final de la lluvia de logs y de descargar la media mitad de internet que te faltaba verás un mensaje que dice: Listening on: http://127.0.0.1:8081
Ahora, la prueba de fuego no es entrar por el puerto 3000 o 8081 directamente (que deberían estar cerrados en el firewall), sino a través de nuestro puente blindado:
Abre en tu navegador: https://tu-dominio.com/quarkus
Deberías ver una página que dice «Hello from Quarkus REST» (o lo que hayas puesto en tu GreetingResource.java).
¿Por qué es esto un éxito?
Atravesaste el Proxy de Apache: Tu servidor web principal está redirigiendo el tráfico correctamente.
SSL funcionando: Entraste por HTTPS sin errores de certificado.
Aislamiento de puertos: Tienes Spring en el 8080 y Quarkus en el 8081 conviviendo en paz en el mismo Debian 13.
La pantalla debe ser como esto:
así que por la módica cantidad de 20 USD o menos tienes instalado springboot php lamp quarkus maven y gradle, e incluso con 10 USD puedes en 2 gb ram para pruebas.
Una llamada al monitoreo ahora nos lleva a esto, que significa en palabras comunes que para pruebas es suficiente con 2 gb de ram te digan lo que te digan las LLM u otras personas de sistemas. Si usas Un stack decente como Debian 13.
Estado del Servidor (Debian 13)
Memoria RAM: 1475 MB usados de 3916 MB (37.67%)
Disco Duro: 15.32 GB usados de 74.56 GB (20.54%)
Carga de CPU (1, 5, 15 min): 0, 0.052734375, 0.0595703125
Que te parece horrible y maravilloso y te hace dudar del futuro de internet ? Si. No es posible que necesites 1475 MB de ram para un hola mundo. Además de una conexión estable y descargar varios gigabytes.
Y por eso muchos programadores que van poniendo basura tras basura en una base sucia, acaban cambiando de profesión. Las buenas prácticas te permiten proseguir, pero muchas empresas gastan demasiado por malas prácticas, y malas elecciones de framework o demás.
No van a durar mucho en México empresas medianas que usen la nube para esto. Si ves que hay cuatro o cinco personas que no hacen nada y les pagan, la empresa quiza puede. Pero esto es igual o mas costoso en la nube que un programador bueno y a veces implementado peor. Preocúpate cuando haya problemas para pagar nómina o nube.
No me extrañaría que se cambie a algo más en 2029, en lugar de springboot que es 2014. Sea Quarkus Javelin o algo mas que salga. Springboot será legacy.
El carrito de compras lo pondré en parte 4.