Editions ENI Livres | Vidéos | e-Formations
Application standalone
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 JEE (Java 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 tout...
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 20.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 20.04. Java 11 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-11-jdk Il faut ensuite télécharger la version la plus récente d’Apache Tomcat 9.x. À l’heure de la rédaction de ce livre, il s’agit de la 9.0.46 que nous décompressons dans un dossier /opt.
$ cd /opt && \
curl -O https://miroir.univ-lorraine.fr/apache/tomcat/tomcat-9/
v9.0.41/bin/apache-tomcat-9.0.41.tar.gz &&\
tar -xf apache-tomcat-9.0.41.tar.gz &&\
ln -s /opt/tomcat-9.0.41 /opt/tomcat &&\
chown tomcat:tomat /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-11-openjdk-amd64"
Environment="JAVA_OPTS=-Djava.security.egd=file:///dev/urandom -
Djava.awt.headless=true"
Environment="CATALINA_BASE=/opt/tomcat"
Environment="CATALINA_HOME=/opt/tomcat"
Environment="CATALINA_PID=/opt/tomcat/temp/tomcat.pid" ...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...
