Blog ENI : Toute la veille numérique !
Accès illimité 24h/24 à tous nos livres & vidéos ! 
Découvrez la Bibliothèque Numérique ENI. Cliquez ici
💥 1 livre papier acheté 
= la version en ligne automatiquement offerte. Cliquez ici

Déploiement d’applications sur Tomcat

Introduction

La conception et la réalisation d’une application sont une chose, son déploiement et sa mise en production en sont une autre. L’objectif de ce chapitre est de présenter une manière de faire sous la forme d’un exemple simple les principales étapes du déploiement d’une application sur un serveur d’application Tomcat.

L’installation de l’environnement

1. L’installation de Java

Tomcat est une application Java. Il est donc nécessaire d’installer un environnement Java pour pouvoir démarrer Tomcat. La section La plateforme Java SE du chapitre Introduction à Jakarta EE vous apporte tous les éléments nécessaires à l’installation de cet environnement.

2. L’installation de Tomcat

L’installation de Tomcat peut se faire de deux manières :

  • Sous la forme de la décompression d’une archive.

  • Sous la forme d’un installeur permettant l’installation d’un service (spécifique à un environnement Windows).

Quel que soit le mode d’installation, la même arborescence de répertoire est créée. La différence est l’installation automatique d’un service Windows complémentaire avec l’usage de l’installeur.

a. La vérification préalable

Avant de réaliser l’installation de Tomcat, il convient de vérifier la disponibilité des ports utilisés par Tomcat. Par défaut, les ports utilisés sont les suivants :

Le port 8005 permettant l’extinction du serveur à distance en envoyant une commande paramétrable à l’aide d’un outil comme telnet ou putty.

Le port 8080 permettant de traiter les requêtes HTTP entrantes.

Le port 8009 permettant de traiter les requêtes provenant d’un serveur frontal web (comme Apache par exemple) en utilisant le protocole AJP (Apache JServ Protocol). Pour plus d’informations sur ce protocole, veuillez vous référer à la documentation officielle accessible à l’adresse suivante : http://tomcat.apache.org/connectors-doc/ajp/ajpv13a.html

Pour tester la disponibilité de ces ports, il est possible d’ouvrir une Invite de commandes en mode Administrateur et d’exécuter la commande netstat -anb dans un environnement Windows. Cette commande permet de lister les ports utilisés sur la machine ainsi que les processus les utilisant.

images/08EP01N.png

Il est possible d’utiliser l’outil netstat dans un environnement Linux. Pour cela, il est nécessaire de l’installer au préalable en exécutant la commande...

L’architecture

1. L’organisation physique

Le répertoire d’installation de Tomcat possède l’organisation suivante :

images/08EP42N.png

Il y a initialement sept sous-répertoires :

  • bin : le répertoire bin contient les scripts et les jars nécessaires au démarrage de Tomcat. Le répertoire bin ne contient que des scripts (d’extension .bat pour Windows et .sh pour Linux). Le jar bootstrap.jar est essentiel car c’est le point d’entrée pour le démarrage de Tomcat. Les scripts startup.sh/bat et shutdown.sh/bat permettent respectivement de démarrer et d’arrêter Tomcat.

  • conf : le répertoire conf contient les fichiers de configuration de Tomcat. Les fichiers suivants seront abordés dans les sections suivantes :

  • server.xml : c’est le fichier central de la configuration. Il permet notamment de définir les ports HTTP à utiliser, les hôtes virtuels disponibles et éventuellement les applications déployées. Pour plus d’informations, veuillez vous référer à la section L’administration générale.

  • tomcat-users.xml : ce fichier peut faire partie de la stratégie de sécurité des accès aux applications déployées. Pour plus d’informations, veuillez vous référer à la section La mise en place de la sécurité.

  • logging.properties : ce fichier permet de configurer la gestion des logs. Pour plus d’informations, veuillez vous...

L’administration générale

1. L’application à déployer

a. Le projet

L’application à déployer correspond au projet Eclipse Projet_A_DEPLOYER. Les sources de ce projet sont disponibles en téléchargement.

Il faut ajouter les dépendances suivantes dans le fichier build.gradle afin de pouvoir tester la mise en place des logs dans le programme :

compileOnly group: 'jakarta.servlet', name: 'jakarta.servlet-api', 
version: '5.0.0' 
compileOnly group: 'org.apache.tomcat', name: 'tomcat-juli', 
version: '10.0.7' 

Les dépendances sont définies avec le mot-clé compileOnly car elles sont disponibles dans le répertoire /bin de Tomcat. Il n’est donc pas nécessaire de les embarquer dans l’application à déployer.

Ce projet a la structure suivante :

images/08EP20N.png

Il est composé de quatre pages HTML et de deux servlets. Ces fichiers ont pour objectif de mettre en évidence les points de paramétrage essentiels dans le déploiement d’une application :

  • le déploiement classique,

  • la mise en place de la sécurité,

  • la mise en place d’un mécanisme de logs.

b. La livraison

Le déploiement d’une application commence par sa livraison. La livraison s’effectue sous la forme d’un fichier d’extension .war (Web Archive). Cette tâche pour un projet basique se fait assez simplement au travers d’Eclipse. Les étapes à suivre sont les suivantes :

 Faites un clic droit sur le projet et cliquez sur le menu Export - WAR File.

images/08EP21N.png

 Cliquez sur le bouton Finish. L’export est terminé.

c. La gestion du nom de domaine

Pour que les exemples suivants fonctionnent correctement, vous n’allez pas avoir besoin d’acheter un nom de domaine. Dans un environnement de développement, il est possible de faire une association entre l’adresse IP de la boucle locale (127.0.0.1/localhost) et le nom de domaine www.fairedusport.com.

Dans un environnement Windows, il suffit d’ajouter la ligne suivante dans le fichier hosts présent dans le répertoire C:\Windows\System32\drivers\etc.

127.0.0.1 www.fairedusport.com 

Dans un environnement Linux, il suffit d’ajouter la même ligne dans le fichier /etc/hosts.

2. Vue d’ensemble...

La mise en place de la sécurité

La sécurité est un point essentiel dans le déploiement d’une application. En effet, une fois déployée, l’application peut être accessible par des utilisateurs non autorisés tout simplement parce qu’ils ont accès au réseau sur lequel l’application est mise à disposition (Internet, réseau d’entreprise, réseau privé…). Par ailleurs, la communication entre un utilisateur et l’application peut être interceptée par un tiers pour espionner le contenu. Il est donc nécessaire de limiter les accès et d’empêcher l’interception du contenu. L’objectif de cette section est de présenter les principaux outils à disposition pour mettre en place une sécurité satisfaisante.

1. La restriction d’accès

La restriction d’accès est un mécanisme travaillant sur l’adresse IP de l’émetteur de la requête et sur l’adresse IP de la carte réseau du serveur hébergeant Tomcat par laquelle est réceptionnée la requête. Cette technique permet d’autoriser ou d’interdire le traitement d’une requête en fonction des adresses IP utilisées pour acheminer la requête.

a. La restriction sur l’adresse IP de l’émetteur

Il est possible d’interdire certaines machines d’accéder à une ou plusieurs applications hébergées sur Tomcat en fonction de leur adresse IP. Pour cela, il faut utiliser la valve org.apache.catalina.valves.RemoteAddrValve. Cette valve peut être positionnée sur le moteur, sur un hôte ou sur une application précise en fonction de la portée que l’on souhaite donner à celle-ci.

La balise <valve> possède dans ce cas de figure dispose de quatre attributs principaux :

Attribut

Caractéristiques

allow

Cet attribut permet de définir une expression régulière (selon la classe java.util.regex) décrivant les adresses IP clientes acceptées.

deny

Cet attribut permet de définir une expression régulière (selon la classe java.util.regex) décrivant les adresses IP clientes refusées.

denyStatus

Cet attribut permet de définir...

La gestion des logs

1. Les logs d’accès

Lorsqu’une application est mise en production, il peut être intéressant de suivre les accès des utilisateurs. Tomcat utilise des valves pour réaliser ce traitement. Il existe deux valves principales permettant d’enregistrer les accès dans un fichier ou dans une base de données. Ces valves se nomment :

  • org.apache.catalina.valves.AccessLogValve : cette valve permet d’enregistrer les accès dans un fichier. Pour plus d’informations, veuillez lire la suite de la section.

  • org.apache.catalina.valves.JDBCAccessLogValve : cette valve permet d’enregistrer les accès dans une table d’une base de données. Pour plus d’informations, veuillez lire la documentation officielle à l’adresse suivante : https://tomcat.apache.org/tomcat-10.0-doc/api/org/apache/catalina/valves/JDBCAccessLogValve.html.

Ces valves se configurent dans le fichier server.xml. Elles peuvent être positionnées au niveau du moteur, de l’hôte ou de l’application en fonction de la portée qu’elles doivent avoir.

Par défaut, Tomcat configure une valve de type AccessLogValve au niveau de l’hôte comme ceci :

<Valve    className="org.apache.catalina.valves.AccessLogValve" 
        directory="logs" 
        prefix="localhost_access_log"  
        suffix=".txt" 
        pattern="%h %l %u %t &quot;%r&quot; %s %b" /> 

Cette valve dispose de plusieurs attributs. Voici la signification des principaux attributs :

  • className : cet attribut permet d’indiquer la classe Java correspondant à la valve utilisée. Les autres attributs présents sont spécifiques à la valve AccessLogValve.

  • directory : cet attribut permet de déterminer le répertoire dans lequel sera écrit le fichier (chemin relatif à CATALINA_BASE ou chemin absolu).

  • prefix : cet attribut permet de déterminer le préfixe du nom du fichier.

  • suffix : cet attribut permet de déterminer le suffixe du nom du fichier.

  • rotatable : cet attribut permet de déterminer si une partie horaire est incluse dans le nom du fichier entre le préfixe et le suffixe....

Conclusion

Ce chapitre permet de clore cet ouvrage en présentant les grandes lignes du déploiement d’une application Jakarta EE sur le serveur Tomcat. Il n’a pas été abordé des sujets intéressants comme la mise en place d’un frontal web, la mise en place d’une ferme de serveurs (cluster), la gestion de la répartition des charges (load-balancing)... J’espère que ces quelques pages vous ont donné envie d’aller plus loin sur ce sujet à cheval entre le monde du développement et le monde de l’administration.