Aplicación standalone
La aplicación principal
A lo largo de los capítulos, utilizaremos una aplicación central llamada eni-todo, desarrollada exclusivamente para los fines de este libro. Incorporará gradualmente todas las arquitecturas y tecnologías presentadas, tanto de software como de hardware, para hacerla lo más disponible y robusta posible
Esta sencilla aplicación le permite crear una lista de tareas (tasks) y almacenarlas en una base de datos o en una sesión. También permite añadir elementos adjuntos (uploads) a las tareas.

Figura 1: Aplicación eni-todo en acción
Esta aplicación es una aplicación web desarrollada utilizando el lenguaje de programación Java, de acuerdo con los estándares Jakarta EE (Jakarta Enterprise Edition).
Hemos creado deliberadamente esta aplicación para que este libro sirva de pauta para implantar una arquitectura de alta disponibilidad. Las opciones tecnológicas, próximas a las utilizadas habitualmente en las empresas, irán evolucionando a medida que avancen los capítulos.
Esta aplicación utiliza el framework Spring. El código de la aplicación está disponible en el repositorio de fuentes GitHub de los autores: https://github.com/halnx-todo/eni-tomcat-todo
1. Arquitectura de aplicaciones web
Siguiendo las mejores prácticas de antaño, nuestra aplicación de n-tiers se suministra mediante un servidor de aplicaciones, Apache Tomcat, y los datos se almacenan:
-
en una base de datos MariaDB SQL para los datos de las tareas (TodoItem),
-
en el sistema de archivos para los archivos descargados (elementos adjuntos) asociados a las tareas.

Figura 2: Aplicación all-in-one
El servidor de aplicaciones Apache Tomcat proporciona el enlace entre las peticiones HTTP (HyperText Transfer Protocol) del navegador web del cliente y el código Java de la aplicación.
Hoy en día, existen muchas formas diferentes de desplegar esta aplicación, entre otras cosas porque las prácticas han evolucionado considerablemente desde el RFC-1945 de 1996 o la especificación CGI de 1999. Discutiremos varios métodos de despliegue a lo largo de este libro.
En primer lugar, la aplicación se construye para producir un archivo WAR (Web Application Archive) que se integra en un servidor de aplicaciones que cumpla el...
Construir el servidor todo en uno
Nuestra aplicación necesita un servidor de aplicaciones para ejecutarse, por lo que necesitamos instalar todos los componentes necesarios. Hemos creado un rol y un playbook Ansible para automatizar todo esto. Sin embargo, vamos a enumerar todos los pasos.
1. Instalación de la aplicación
La instalación se realiza, como en el resto de este libro, en un servidor Linux Ubuntu 24.04.
a. Apache Tomcat
Necesitamos instalar el servidor de aplicaciones Tomcat, que primero requiere que se instale el runtime de Java. Estamos utilizando la versión openjdk-11 proporcionada por nuestra release de Linux Ubuntu 24.04. Java 21 es la versión LTS (Long Term Support) actual en el momento de escribir estas líneas.
Para Apache Tomcat, el JRE (Java Runtime Environment) sería suficiente, pero como vamos a construir nuestra aplicación en este mismo servidor ’todo-en-uno’, el JDK (Java Development Kit) es necesario.
$ sudo apt-get install openjdk-11-jdk
A continuación, deberá descargar la versión más reciente de Apache Tomcat 10.x. En el momento de escribir este libro es 10.1.19, que vamos a descomprimir como root en una carpeta /opt.
$ sudo useradd -U -d /opt/tomcat -m -s /bin/false tomcat
$ cd /tmp && \
curl -O https://dlcdn.apache.org/tomcat/tomcat-10/v10.1.19/bin/
apache-tomcat-10.1.19.tar.gz &&\
tar -xf apache-tomcat-10.1.19.tar.gz &&\
sudo mv apache-tomcat-10.1.19 /opt/tomcat-10.1.19 && sudo rm -rf
/opt/tomcat && sudo ln -s /opt/tomcat-10.1.19 /opt/tomcat &&\
sudo chown -R tomcat:tomcat /opt/tomcat*
A continuación, se deben llevar a cabo estas acciones:
-
establecer la configuración systemd del servicio creando el archivo /etc/systemd/system/tomcat.service,
-
recargar la configuración de systemd,
-
iniciar Apache Tomcat como servicio,
-
abrir el cortafuegos en el puerto 8080.
Aquí está el contenido del systemd tomcat.service:
[Service]
Type=forking
User=tomcat
Group=tomcat
Environment="JAVA_HOME=/usr/lib/jvm/java-21-openjdk-amd64"
#start-for-eni-todo-multi-conf
Environment="SPRING_PROFILES_ACTIVE=tomcat-mariadb-harcoded"
#/end-for-eni-todo-multi-conf
Environment="JAVA_OPTS=-Djava.security.egd=file:///dev/urandom -
Djava.awt.headless=true" ...
Algunos problemas de este modelo todo en uno
1. Compartir recursos
Por definición, el servidor "todo en uno" alberga el firewall, la aplicación web y la base de datos. Por tanto, debe gestionar cada una de estas funciones en paralelo. Si el servidor está poco cargado, responderá fácilmente a las necesidades, pero si hay muchas peticiones que procesar al mismo tiempo, como las búsquedas en la base de datos, una u otra de las aplicaciones puede ocupar rápidamente todos los recursos.
Si no se utiliza mucho, este servidor puede alojar otras aplicaciones (mutualización), con el riesgo, sin embargo, de que una tome el relevo de las otras.
Además, el puerto 80 sólo puede ser utilizado por una aplicación a la vez, por lo que se necesitan mecanismos (virtualhost, proxy, contexto) para redirigir los flujos HTTP a la aplicación web correcta.
Por último, el servidor necesita operaciones de mantenimiento (copias de seguridad, actualizaciones del sistema operativo o de las aplicaciones) que conllevan tiempos de inactividad. Por término medio, cada aplicación se actualiza una vez al mes, lo que naturalmente repercute en la disponibilidad y la seguridad de las aplicaciones instaladas en el servidor, como nuestra aplicación eni-todo.
Si hay varias aplicaciones, las actualizaciones de versión se deben realizar al mismo ritmo.