L’application fil rouge

Au fil des chapitres, nous allons utiliser une application fil rouge appelée eni-todo et développée exclusivement pour les besoins de cet ouvrage. Elle intégrera progressivement toutes les architectures et technologies présentées, tant logicielles que matérielles, qui permettront de la rendre aussi disponible et incassable que possible.

Cette application très simple permet de créer une liste de tâches (task) et de les conserver au sein d’une base de données ou en session. Elle permet également l’ajout de pièces jointes (uploads) aux tâches.

Figure 1 : Application eni-todo en action

Cette application est une application web développée avec le langage de programmation Java, selon les normes Jakarta EE (Jakarta Enterprise Edition).

Nous avons volontairement créé cette application pour ce livre afin de servir de fil rouge pour la mise en œuvre d’une architecture en haute disponibilité. Les choix technologiques proches de ceux couramment utilisés en entreprise, évolueront au fur et à mesure des chapitres.

Cette application utilise le framework de développement Spring. Le code de l’application est disponible sur le dépôt de source GitHub des auteurs : https://github.com/halnx-todo/eni-tomcat-todo

1. L’architecture de l’application web

Suivant les bonnes pratiques des années passées, notre application n-tiers est servie par un serveur d’application, Apache Tomcat, et les données sont stockées :

dans une base de données SQL MariaDB pour les données des tâches (TodoItem) ;
sur le système de fichiers pour les fichiers téléchargés (les pièces jointes) associés aux tâches.

Figure 2 : Application all-in-one

Le serveur d’application Apache Tomcat effectue le lien entre les requêtes HTTP (HyperText Transfer Protocol) du navigateur web du client et le code Java de l’application.

De nos jours, il existe de nombreuses façons de déployer cette application, notamment parce que les pratiques ont beaucoup évolué depuis la RFC-1945 de 1996 ou la spécification CGI de 1999. Nous évoquerons plusieurs méthodes de déploiement...

Construction du serveur tout-en-un

Notre application a besoin d’un serveur d’application pour fonctionner et il faut donc installer tous les composants nécessaires. Un rôle et un playbook Ansible ont été créés pour automatiser tout cela. Néanmoins, nous allons lister l’ensemble des étapes.

1. Installation de l’application

L’installation est effectuée, comme dans l’ensemble de cet ouvrage, sur un serveur Linux Ubuntu 24.04.

a. Apache Tomcat

Il faut installer le serveur d’application Tomcat, qui nécessite tout d’abord l’installation du runtime Java. Nous utilisons la version openjdk-11 fournie par notre release Linux Ubuntu 24.04. Java 21 est la version LTS (Long Term Support) actuelle à la date de la rédaction de ce livre.

Pour Apache Tomcat, le JRE (Java Runtime Environment) serait suffisant, mais comme nous allons construire notre application sur ce même serveur « tout-en-un », le JDK (Java Development Kit) est donc nécessaire.

$ sudo apt-get install openjdk-21-jdk

Il faut ensuite télécharger la version la plus récente d’Apache Tomcat 10.x. À l’heure de la rédaction de ce livre, il s’agit de la 10.1.19 que nous décompressons en tant que root dans un dossier /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*

Il faut ensuite réaliser ces actions :

mettre en place la configuration systemd du service en créant le fichier /etc/systemd/system/tomcat.service ;
recharger la configuration de systemd ;
démarrer Apache Tomcat en tant que service ;
ouvrir le firewall sur le port 8080.

Voici le contenu du service 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 ...

Quelques problèmes de ce modèle tout-en-un

1. Partage des ressources

Le serveur tout-en-un, par définition, héberge à la fois le firewall, l’application web et la base de données. Il doit donc prendre en charge chacune de ces fonctions en parallèle. Si le serveur est peu chargé, il répond facilement au besoin, mais s’il y a beaucoup de requêtes à traiter en même temps, comme des recherches en base de données, l’une ou l’autre des applications peut rapidement prendre toutes les ressources.

S’il n’est pas beaucoup utilisé, ce serveur peut héberger d’autres applications (mutualisation), avec cependant le risque que l’une prenne la main sur les autres.

En outre, le port 80 n’étant utilisable que par une seule application à la fois, il faut donc prévoir des mécanismes (virtualhost, proxy, contexte) pour permettre de rediriger les flux HTTP vers la bonne application web.

Enfin, le serveur a besoin d’opérations de maintenance (sauvegarde, mise à jour du système d’exploitation ou d’applicatif) qui entraînent des arrêts de service. Il y a en moyenne une mise à jour par mois par applicatif, cela impacte naturellement la disponibilité ou la sécurité des applications installées sur le serveur, comme notre...

Application standalone