Servidores de Aplicaciones

1. El servidor que ejecuta tu código

El servidor web sabe servir ficheros, pero no sabe ejecutar PHP, Java o JavaScript. De eso se encarga el servidor de aplicaciones (o el entorno de ejecución del lenguaje): mantiene tu aplicación cargada, atiende las peticiones que le pasa el servidor web, gestiona conexiones con la base de datos y escribe sus propios registros. Desplegar una aplicación consiste, en el fondo, en poner el código correcto en este servidor, con la configuración correcta, y reiniciarlo sin que los usuarios lo noten.

2. Tomcat y las aplicaciones Java

Tomcat es el contenedor de servlets más usado. Una aplicación web Java se empaqueta en un fichero WAR (Web ARchive), un ZIP con una estructura fija: las páginas y recursos en la raíz, y dentro de WEB-INF las clases compiladas, las librerías y el descriptor web.xml. Al copiar tienda.war en la carpeta webapps, Tomcat lo despliega automáticamente y la aplicación queda en http://servidor:8080/tienda.

La aplicación Manager permite desplegar, parar y recargar aplicaciones desde el navegador o con Maven, pero es una puerta de entrada muy atacada: si la activas, protégela con un usuario fuerte y limítala a tu IP. En producción, Tomcat no se expone directamente: se coloca detrás de Nginx o Apache, que se encarga de HTTPS.

1# Empaquetar y desplegar una aplicación Java
2mvn clean package                          # genera target/tienda.war
3sudo cp target/tienda.war /opt/tomcat/webapps/
4sudo tail -f /opt/tomcat/logs/catalina.out # comprueba que arranca sin errores
5
6# Spring Boot: un .jar con el servidor dentro
7java -jar target/tienda.jar --server.port=8080 --spring.profiles.active=prod

3. Mantener la aplicación en marcha

Una aplicación de Node.js o un .jar de Spring Boot son procesos normales: si los arrancas en una terminal y la cierras, se paran, y si fallan a las tres de la mañana nadie los vuelve a levantar. En Linux, la forma estándar de convertirlos en un servicio es systemd: lo arranca al iniciar el sistema, lo reinicia si se cae y guarda su salida en el diario del sistema.

1[Unit]
2Description=API de la tienda
3After=network.target
4
5[Service]
6User=tienda                              ; nunca como root
7WorkingDirectory=/srv/tienda
8EnvironmentFile=/srv/tienda/.env         ; configuración y secretos, fuera del código
9ExecStart=/usr/bin/node server.js
10Restart=on-failure
11RestartSec=5
12
13[Install]
14WantedBy=multi-user.target

1sudo systemctl daemon-reload
2sudo systemctl enable --now tienda      # arrancar ahora y en cada inicio
3systemctl status tienda
4journalctl -u tienda -f                 # ver sus registros en directo

El proxy inverso

La aplicación escucha en un puerto interno (3000, 8080) al que no se puede acceder desde fuera, y Nginx le pasa las peticiones. Así Nginx se ocupa de HTTPS, de la compresión y de los estáticos, y la aplicación puede reiniciarse o cambiarse sin tocar la configuración pública. Las cabeceras X-Forwarded-* le cuentan a la aplicación la IP real del cliente y si la petición original venía por HTTPS.

1location / {
2    proxy_pass http://127.0.0.1:3000;
3    proxy_set_header Host $host;
4    proxy_set_header X-Real-IP $remote_addr;
5    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
6    proxy_set_header X-Forwarded-Proto $scheme;
7}

4. Configuración y despliegues sin sustos

Una misma versión del código debe poder ejecutarse en desarrollo, en pruebas y en producción cambiando solo la configuración: la cadena de conexión, las claves de las APIs, el nivel de registro. Esa configuración vive en variables de entorno (o en un fichero .env fuera del repositorio), nunca en el código. Es uno de los principios de las aplicaciones twelve-factor, una guía muy influyente sobre cómo construir aplicaciones fáciles de desplegar.

• Construye una vez, despliega muchas: el mismo artefacto (WAR, imagen Docker) pasa por pruebas y llega a producción; no se recompila por el camino.
• Comprobación de salud: una ruta como /salud que diga si la aplicación y su base de datos responden, para que el balanceador y la monitorización lo sepan.
• Migraciones de base de datos automatizadas y compatibles con la versión anterior durante el cambio.
• Poder volver atrás: conservar la versión anterior para restaurarla en un minuto si algo falla.

5. Reto

La monitorización empieza por algo tan sencillo como clasificar el resultado de las comprobaciones de salud de cada servicio y resumir el estado general del sistema.

1. Lee cada comprobación: nombre, código HTTP y tiempo de respuesta.
2. Clasifica cada servicio y lleva la cuenta de los problemas.
3. Decide el estado general, de peor a mejor.