Práctica 3.1: Instalación de Tomcat

Atención

Estos apuntes siguen aquí para temas de consulta pero a día de hoy tiene ciertas partes que pueden haberse quedado obsoletas (Heroku por ejemplo ahora es de pago), los iré actualizando en la medida que el tiempo me lo permita en esta nueva página.

Introducción

Si consultamos el apartado de versiones de Tomcat en su página oficial, nos daremos cuenta de que no vamos a usar la última versión, la 10, para esta práctica, sino la anterior, la 9. La pregunta es casi inevitable:

¿Por qué?

En el enlace anterior vemos como desde su versión 9, Tomcat da soporta a Java 8 y superiores. Sin embargo, a partir de la versión 10.1.x, da soporte a Java 11 y superiores.

¿Qué significa esto?

En Java 9 se introdujeron novedades como un nuevo sistema de módulos (Jigsaw), entre otras.

En Java 11 se dio un paso más al haber renombrado completamente las rutas de paquetes javax. a jakarta.. Oracle, a pesar de haber hecho público el desarrollo de Java, no hizo lo mismo con su nombre.

Así las cosas, resulta que Java 8 puede que a día de hoy aún sea la más usada en proyectos reales. Dicho esto, podría realizarse un proceso de migración de un proyecto de Java 8 a Java 11 y utilizarlo en Tomcat 10.

No obstante, para Java 8 su soporte para uso comercial (pagando) acabó en Marzo de 2022, pero para uso no comercial sigue hasta 2030.

En conclusión, no es raro encontrarse en el mundo real un proyecto a desplegar realizado en Java 8. Podría realizarse una migración y los conceptos de despliegue que veremos seguirían aplicando. Así las cosas, por facilidad en la realización de las prácticas utilizaremos Tomcat 9 y el plugin oficial de Maven para Tomcat 7 para el despliegue (luego veremos el motivo).

Instalación de Tomcat

Esta práctica es muy sencilla y va a consistir en realizar la instalación del servidor de aplicaciones Tomcat 9, en una máquina virtual corriendo Debian 11 Bullseye.

Se puede hacer tanto con el administrador de paquetes apt como de forma manual. La forma más recomendable por su sencillez es la primera.

Para ello, y como sugerencia, podéis apoyaros en este tutorial online, aunque sóis libres de consultar tantas fuentes como deseéis.

Obviamente, debéis utilizar vuestro propios usuarios y contraseña.

Despliegue manual mediante la GUI de administración

Realizaremos el despliegue manual de una aplicación ya previamente empaquetada en formato WAR. Para ello:

Nos logueamos con el usuario previamente creado.
Buscamos la sección que nos permite desplegar un WAR manualmente, seleccionamos nuestro archivo y lo desplegamos.

Tras estos pasos, se nos listará la aplicación ya desplegada como un directorio más y podremos acceder a ella.

Task

Documenta el despliegue manual de la aplicación que os podéis descargar para tal efecto en Aules (archivo .war).

Despliegue con Maven

Instalación de Maven

Para instalar Maven en nuestro Debian tenemos, de nuevo, dos opciones:

Instalación mediante gestor de paquetes APT
Instalación manual

La primera, recomendada, es mucho más sencilla y automatizada (establece todos los paths y variables de entorno), aunque con la segunda se podría conseguir un paquete más actualizado.

Ambos métodos vienen explicados aquí

Si decidimos seguir el primer método, el más sencillo, vemos que es tan simple como actualizar los repositorios:

sudo apt update

E instalar Maven

sudo apt install maven

Para comprobar que todo ha ido correctamente, podemos ver la versión instalada de Maven:

mvn --v

Configuración de Maven

Para poder realizar despliegues en nuestro Tomcat previamente instalado, necesitamos realizar la configuración adecuada para Maven. Ya sabemos que esto en Linux significa editar los archivos de configuración adecuados. Vamos a ello.

En primer lugar necesitamos asegurarnos de que en el apartado anterior de la práctica hemos añadido todos los usuarios necesarios, así como sus respectivos roles. Debemos añadir el rol de manager-script para permitir que Maven se autentique contra Tomcat y pueda realizar el despliegue.

Los roles utilizados por Tomcat vienen detallados en su documentación, que merece ser consultada:

En dicha documentación se nos indica que, por temas de seguridad, es recomendable no otorgar los roles de manager-script o manager-jmx al mismo usuario que tenga el rol de manager-gui.

Info

Tendremos dos usuarios, uno para la GUI y otro exclusivamente para hacer los deploys de Maven.

Así las cosas, modificamos el archivo /etc/tomcat9/tomcat-users.xml acorde a nuestras necesidades (los nombres de usuario y contraseña deberán ser los que elijáis para vosotros):
Editar el archivo /etc/maven/settings.xml para indicarle a Maven, un identificador para el servidor sobre el que vamos a desplegar (no es más que un nombre, ponedle el nombre que consideréis), así como las credenciales. Todo esto se hará dentro del bloque servers del XML:
Ahora debemos modificar el POM del proyecto para que haga referencia a que el despliegue se realice con el plugin de Maven para Tomcat.

Info

No existen plugins oficiales para Tomcat más allá de la versión 7 del servidor. No obstante, el plugin para Tomcat 7 sigue funcionando correctamente con Tomcat 9.

Otra opción sería utilizar el plugin Cargo

Donde lo que añadimos es el bloque
```
<build>
        <finalName>war-deploy</finalName> #(1)
        <plugins> 
        <plugin>
        <groupId>org.apache.tomcat.maven</groupId>
        <artifactId>tomcat7-maven-plugin</artifactId>
        <version>2.2</version>
        <configuration>
            <url>http://localhost:8080/manager/text</url> #(2)
            <server>Tomcat.P.3.1</server> #(3)
            <path>/myapp</path> #(4)
        </configuration>
        </plugin>
        </plugins>
</build>
```
1. Nombre final del ejecutable .jar que se va a generar
2. URL del servidor Tomcat donde se hará el despliegue. Como en nuestro caso Maven y Tomcat están en el mismo servidor, la URL corresponde a localhost. Esta URL debe ir seguida por /manager/text, tal y como leemos en la documentación del plugin.
3. Nombre del server donde se va a desplegar la aplicación. El nombre debe ser consistente con lo que hayamos puesto en el settings.xml del paso anterior.
4. Nombre que la aplicación utilizará en el path de la URL

Despliegue

Teniendo ya todo listo para realizar despliegues, ahora crearemos una aplicación Java de prueba para ver si podemos desplegarla sobre la arquitectura que hemos montado. Para ello utilizamos el comando:

    mvn archetype:generate -DgroupId=raul -DartifactId=war-deploy -DarchetypeArtifactId=maven-archetype-webapp -DinteractiveMode=false

Podéis sustituir los valores de groupID y artifactId (este será el nombre de la aplicación) por lo que queráis.

Tras generar esta aplicación, los comandos finales que se utilizan en Maven para desplegar, volver a desplegar o desplegar una aplicación, son:

mvn tomcat7:deploy
mvn tomcat7:redeploy
mvn tomcat7:undeploy

Así pues, tras el despliegue con Maven nos indicará que todo ha ido correctamente con un mensaje de BUILD SUCCESS, tal que así:

Y, accediendo a través de la GUI, debemos ver que la aplicación está desplegado y que podemos acceder a ella perfectamente:

Tarea

Realizar el despliegue con la aplicación de prueba.

Repetir el despliegue pero esta vez con otra aplicación que no es la de prueba. Más adelante ya hablaremos de git pero de momento, usaremos los comandos que veremos a continuación.

Nos clonamos el repositorio:

git clone https://github.com/cameronmcnz/rock-paper-scissors.git

Nos situamos dentro de él:

cd rock-paper-scissors

Y cambiamos de rama:

git checkout patch-1

Tras esto debemos proceder exactamente igual que en el caso anterior, con la ventaja de que ya tenemos configurados los usuarios de Tomcat y los parámetros de Maven.

Así pues, sólo habría que añadir el bloque <plugin>...</plugin> adecuado para poder hacer nuestro despliegue.

Task

Documenta, incluyendo capturas de pantallas, el proceso que has seguido para realizar el despliegue de esta nueva aplicación, así como el resultado final.

Cuestiones

Habéis visto que los archivos de configuración que hemos tocado contienen contraseñas en texto plano, por lo que cualquiera con acceso a ellos obtendría las credenciales de nuestras herramientas.

En principio esto representa un gran riesgo de seguridad, ¿sabrías razonar o averigüar por qué esto está diseñado de esta forma?

Referencias

Tutorial Tomcat I

Tutorial Tomcat II

Tutorial Tomcat para Ubuntu

Instalación Maven

JSF 3.0 en Tomcat 10 con Java 11

Migración de Java 8 a Java 11

Install and configure jdk11 + Tomcat + Maven under Linux system

Step-by-step Maven Tomcat WAR file deploy example

How to deploy the java application to Tomcat 9 webserver using Maven

How to Install Apache Maven on Debian 11 Bullseye

How to Deploy a WAR File to Tomcat

Migrate Maven Projects to Java 11

How to configure Tomcat 9.0 in Maven

Github: cameronmcnz/rock-paper-scissors

Why are plain text passwords in the config files?

How to avoid storing passwords in the clear for tomcat's server.xml Resource definition of a DataSource?

Evaluación

Criterio	Puntuación
Despliegue manual de un `.war` en Tomcat correcto y bien documentado	1 punto
Despliegue del `.war` de prueba utilizando maven correcto y bien documentado	0.25 puntos
Despliegue de una aplicación con maven desde un repositorio de Github correcto y bien documentado	4.75 puntos
Cuestiones	2 puntos
Se ha prestado especial atención al formato del documento, utilizando la plantilla actualizada y haciendo un correcto uso del lenguaje técnico	2 puntos